微前端解决方案对比和决策
什么是微前端？
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略
Micro Frontends - extending the microservice idea to frontend development (micro-frontends.org)
- 微前端 这个名词，第一次被提出还是在2016年底，将微服务这个被广泛应用于服务端的技术范式扩展到前端领域。
- 趋势：前端越丰富复杂，项目越庞大难以维护
- 核心思想：独立的团队负责特定的业务和开发独立的功能模块
架构对比
接下来我们来看一下现在前端最常见的几种架构：
需要注意的是，这些技术并不是相互排斥的，实际应用中可能会使用它们的组合来实现应用程序的需求。例如，同构应用可以与JAMStack和微前端一起使用，以提高应用程序的性能、可维护性和可扩展性。
永远不要追求最好的架构，而要追求最不糟糕的架构。完美的架构并不存在，架构没有对错之分，只有根据环境进行利弊权衡后的最佳结果。
如果是工作时间超过五年的前端，可能还知道一种古老原始的架构：纯静态页面，配合CDN使用效果更佳，当然CDN（内容分发网络）可以配合任意一种架构使用，源服务+CDN+客户端+上面的架构有很多种组合的可能，在我之前的互联网行业工作里经常用到，能玩出很多花样来，这里不做深入介绍。
微前端决策
这里我整理了一份决策清单，是否引入微前端决策之前核对以下内容可能对你和公司的小伙伴有帮助，必要的时候和你的上级主管讨论清楚每一项内容细节，做到心中有数，编码不慌。
在如何选择合适的微前端框架的时候，我这里也做了一个较全面的技术调研
qiankun 方案
阿里开源，基于 single-spa，Star 14k+
缺点
1. 改造成本较大，从 webpack、代码、路由等等都要做一系列的适配
2. 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活
3. css 沙箱无法绝对的隔离，js 沙箱在某些场景下执行性能下降严重
4. 无法支持 vite 等 ESM 脚本运行
优点
1. 监听路由自动的加载、卸载当前路由对应的子应用
2. 完备的沙箱方案，js沙箱做了三套渐进增强方案，css沙箱做了两套适用不同场景的方案
3. 路由保持，浏览器刷新、前进、后退，都可以作用到子应用
4. 应用间通信简单，全局注入；使用人数最多
micro-app 方案
京东开源，基于 webcomponent + qiankun sandbox，Star 3.9k+
缺点
1. 上手难度和接入成本相对于qiankun低，但还是需要深入理解框架原理，并有良好的踩坑心态
2. css 沙箱依然无法绝对的隔离，js 沙箱做全局变量查找缓存，性能有所优化
3. 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离
4. 对于不支持 webcompnent 的浏览器没有做降级处理
优点
1. 所有功能都封装到一个类WebComponent组件，实现一行代码即可渲染一个微前端应用
2. micro-app没有任何依赖，体积小巧和更高的扩展性
3. micro-app做了诸多兼容，在任何技术框架中都可以正常运行
4. 预加载、数据通信、静态资源补全等功能齐全
EMP 方案
欢聚时代开源，基于 webpack5 module federation，Star 2.1k+
缺点
1. 无法解决多框架兼容等微前端方案的痛点
2. 基于 Webpack5 Module Federation，需要统一 Webpack5 技术
3. 子应用保活、多应用激活无法实现
4. 文档资料较少，社区不够活跃
优点
1. 结合webpack5、Module Federation的丰富项目实战、建立三层共享模型
2. 结合webpack 5 中心化缓存、提升整体构建速度
3. 在开发和构建之间共享 webpack chain 插件接口
4. 可选 “多页应用” 或 “库” 模式的预配置 webpack 构建.
Garfish 方案
字节跳动开源，部署、框架、调试全套解决方案，Star 1.8k+
什么时候用？
1. 项目的团队成员来自多个团队，项目内多条迭代出现需求挤兑，影响测试、发布效率
2. 跨空间、跨时间维度导致团队内技术体系无法统一
3. 多个前端应用需要达到「内聚的单个产品」特征
4. 「内聚的单个产品」中部分内容希望达到独立开发、独立发布、独立测试、独立灰度等能力
优点
1. 功能强大，技术先进，全套解决
2. 支撑像头条那样的产品应用场景，侧重移动端，但很少有公司拥有如此复杂的应用场景
3. 包含构建微前端系统时所需要的基本能力，任意前端框架均可使用。接入简单，可轻松将多个前端应用组合成内聚的单个产品
Wujie 方案
腾讯开源，基于 WebComponent 容器 + iframe 沙箱，Star 2.1k+
缺点
1. 2022年11月才发布1.0.0正式版
2. TS类型提示支持还不够完整
3. 保活模式会占用一点点浏览器内存（后面会讲）
4. 子应用的资源和接口的请求都在主域名发起，所以会有跨域问题，子应用必须做cors 设置
优点
1. 成本低（主应用使用成本低、子应用适配成本低）
2. 速度快（子应用首屏打开速度快、子应用运行速度快）
3. 原生隔离（css 通过 Web Components 、js 运行在 iframe 中做到严格的原生隔离）
4. 功能强大（保活、嵌套、多激活、多共享、去中心化、生命周期、插件、vite）
下面是笔者根据自己的主观判断给出的一个评分表
没有实际案例？ 点击查看 微前端实际应用案例剖析（wujie）
