1.路由分发式。通过HTTP服务器的反向代理功能，将请求路由到对应的应用上
路由分发式微前端，即通过路由将不同的业务分发到不同的独立前端应用上，每当用户从A应用转换到B应用的时候，往往需要刷新一下页面、重新加载资源文件
2.前端容器化。将iframe作为容器来容纳其他前端应用
3.微应用。通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用
微应用化是指，在开发时应用都是以单一、微小应用的形式存在的，而在运行时则通过构建系统合并这些应用，组合成一个新的应用
微应用化与前端微服务化架构类似，他们在开发时都是独立应用，在构建时又可以按照需求单独加载
如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看，微应用化就是微前端的一种实践。只是使用微应用化意味着我们只能使用唯一的一种前端框架
除了限制开发人员使用同一个框架，它还有一些缺点：
所有应用的依赖需要统一，一旦依赖版本不一致，可能会带来其他问题
高度依赖于持续集成，每个子应用在提交的时候，都会重新构建出整个应用，一旦一个子应用出错，系统就会出错
微应用化的形式是，在构建时以单体应用的形式构建；在运行时，以应用模块的形式存在。从原理上说，我们做的只是从多个项目中复制出代码，然后合并到一个项目中
microapps
app-routing.module.ts
reports.module.ts
...
dashboard
dashboard.module.ts
...
reports
reports.module.ts
...
settings
settings.module.ts
...
除了主的app模块，还包含了dashboard、settings、reports三个模块。在微应用化里，上述应用便是最后构建过程中的应用。在构建之前这些模块是以独立App的形式存在的，可以独立的开发运行。而主的App模块下的功能，则可以变成主工程。这时，一共会有四个代码仓库
主代码库，只包含一个空白的框架式代码，它是一个单独的应用，可以独立构建，构建完成则成为包含另外三个应用的完整工程
dashboard应用，在构建时复制对应模块、目录的代码到主工程
4.前端微服务化。在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用
每个前端应用都是完全独立（技术栈、开发、部署、构建独立）
采用这种方式意味着，一个页面上同时存在两个及以上的前端应用在运行
在加载应用时的事件绑定及应用入口
在卸载应用时的事件解绑
目前都采用基座化的方式来加载其他应用，基座化方式可以支持加载不同的前端框架，以及在基座工程上绑定业务逻辑
整体的工作流程：
主工程在运行的时候，会去服务器获取最新的应用配置
主工程在获取配置后，将逐一创建应用，并为应用绑定生命周期
当主工程监测到路由变化的时候，将寻找是否有对应的路由匹配到应用
当匹配到对应的应用时，则加载相应的应用
基座包含以下功能：
管理其他子应用
负责应用间的通信
设计路由的响应机制
支持嵌入常规及iframe模式
Single-SPA自称是一个JavaScript的原框架，他可以用于构建可共存的微前端应用，每个前端应用都可以用自己的框架编写。它能实现如下内容：
在同一页面上使用多个框架而不用刷新页面
使用新的框架编写前端代码，而无需重写现有的应用程序
延时加载前端应用和代码，用于改善初始加载时间
缺点：
系统构建复杂，应用需要集成在一起进行构建
不支持不同应用的部署分离
代码结构复杂
有额外的大量学习成本
5.微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的chunk代码，使用时只需要远程加载即可
每个业务团队编写自己的业务代码，并将编译好的代码部署（上传或者放置）到指定的服务器。在运行时，我们只需要加载相应的业务模块即可
如果存在第三方开发组件，就不得不考虑寻找如iframe这样的隔离方案。微件化并不适合复杂的前端应用。
对于传统的多页面应用来说，微件化是相当容易实施的方案。在传统的多页面应用结构中，只需要编写相应的HTML、CSS、JavaScript，就可以在加载微件时创建相应的组建和元素，再替换到相应的DOM结点上，这种方式类似于WebComponents
6.应用组件化。借助于Web Components技术，来构建框架的前端应用
对于不能从头使用Web Components，有两种方式可以结合Web Components来构建微前端应用
使用Web Components构建独立于框架的组件，并在对应的框架中引入这些组件
在Web Components中引入现有的框架，类似于iframe的形式
方式 开发成本 维护成本 可行性 同一框架要求 实现难度 潜在风险
路由分发 低 低 高 否 *
iframe 低 低 高 否 *
微服务化 高 低 中 否 **** 针对每个框架做定制及Hook
微件化 高 中 低 是 **** 正对构建系统，如webpack进行hack
微应用化 中 中 高 是 *** 统一不同应用的构建规范
WebComponents 高 低 高 否 ** 新技术，浏览器的兼容问题
js 隔离
一个子应用从加载到运行，再到卸载，有可能会对全局产生一些污染。这些污染包括但不限于：添加、删除、修改全局变量（比如：window.$ = jQuery）、绑定全局事件（比如：window.addEventListener、修改原生方法或对象（比如：Promise）、修改原生方法或对象的原型链（比如：XMLHttpRequest.prototype.open）。而所有这些子应用造成的影响都可能引起潜在的全局冲突。为此，我们需要在加载和卸载一个应用的同时，尽可能消除这种影响
硬隔离
简单来说，就是在每个子应用加载之前，都进行一次 reload，这样可以保证每个子应用在渲染时都是一个全新的环境，哪怕是上一个子应用把 window 上的属性改了个遍，也丝毫没有影响
css 隔离
子应用与子应用之间的 css 隔离非常简单，我们只需要在子应用加载时，标记该子应用所有的 link 和 style 文件。在子应用卸载后，同步卸载所有的 link 和 style 即可
子项目原本需要加载的公共部分（如vue、vuex、vue-router、ivew/element、私有npm包等），全部由主项目调度，配合webpack的externals功能通过外链的方式按需加载，一旦有一个子项目加载过，下一个子项目就不需要再加载，这样一来每个子项目的dist文件里就只有子项目自己的业务代码（最终子项目包的体积缩小了80%，只有几十k），项目实际加载速度快了很多
umijs/qiankun
