一、前言
“一千个人眼里有一千个哈姆雷特” 本文仅是作者这段时间对微前端的思考与感悟，文笔拙劣，多多海涵。微前端的实现方式有很多种，但是微前端并不完美。只有适合自己、适合团队的才是最佳实践。希望本文能帮助您在微前端学习之路上节约一点时间。也欢迎大家提出意见、踊跃的反馈、希望能与大家共进步，加油～
“一千个人眼里有一千个哈姆雷特” 本文仅是作者这段时间对微前端的思考与感悟，文笔拙劣，多多海涵。微前端的实现方式有很多种，但是微前端并不完美。只有适合自己、适合团队的才是最佳实践。希望本文能帮助您在微前端学习之路上节约一点时间。也欢迎大家提出意见、踊跃的反馈、希望能与大家共进步，加油～
由于本文较长（PS：本人懒得分篇），目录一至目录七偏理论知识，目录七之后为实践操作与思考，大家可以适当的跳跃来看
微前端是什么？
- 微前端不是特指某一项技术，而是一种思想。是由2016年 ThoughtWorks Technology Radar 中提出的，借鉴后端微服务的架构模式，将 Web 应用由单一的单体应用转变为多个小型前端应用，聚合为一的应用。
- 所以微前端不是指具体的库，不是指具体的框架，不是指具体的工具，而是一种理想与架构模式。
- 微前端的核心三大原则就是：独立运行、独立部署、独立开发 所以满足这些的最佳人选就是 “iframe”!!!
微前端能解决我们什么问题？
举例: 一个持续多年的应用，经历几年的业务的更新迭代，当项目发展到一定程度的时候就会遇到以下问题
- 业务模块之间不断的堆叠，交错引用，业务耦合如何治理？
- 老技术、老代码不敢动，新技术、新架构又想用？
- 万年技术债？既要跟随业务敏捷迭代，又要保证代码库向好发展，旧的框架类库如何平稳升级？
- 一个项目多个团队开发，你冲突我，我冲突你，如何解决并行开发的冲突？
- 代码库持续膨胀，难以维护的项目代码，是屎上雕花？还是从头再来？
有没有一种可以分解复杂度，提升协作效率，支持灵活扩展的架构模式？ 微前端应运而生—— “更友好的iframe” 将一个巨无霸应用拆解为一个个独立的微应用应用，而用户又是无感知的！
微前端核心原则：
- 技术栈无关: 主应用不限制子应用接入的技术栈，每个应用的技术栈选型可以配合业务情景选择。
- 独立开发、独立部署：既可以组合运行，也可以单独运行。
- 环境隔离：应用之间 JavaScript、CSS 隔离避免互相影响
- 消息通信：统一的通信方式，降低使用通信的成本
- 依赖复用：解决依赖、公共逻辑需要重复维护的问题
这意味着我们可以循序渐进的进行巨石应用的拆解，去技术升级、去架构尝试、去业务拆解等等。以低成本、低风险的进行，为项目带来更多可能性
我们的项目适不适合改造成微前端项目模式？
看我们的项目满足不满足微前端化，先看能不能满足以下几点即可。
- 是否有明确的业务边界，业务是否高度集中。
- 业务是否高度耦合、项目是否足够庞大到需要拆分。
- 团队中存在多个技术栈并且无法统一，需要接入同一套主系统。
- 技术老旧，扩展困难，维护吃力不讨好。
- 开发协同、部署维护等工作，效率低下，一着不慎，满盘皆输。
注意：没有迫切的需求接入微前端，只会带来额外的负担，我们要知道我们使用微前端是为了什么？
二、微前端技术选型
微前端实现方案对比
| 技术方案 | 描述 | 技术栈 | 优点 | 缺点 | 单独构建 / 部署 | 构建速度 | SPA 体验 | 项目侵入性 | 学习成本 | 通信难度 |
|---|---|---|---|---|---|---|---|---|---|---|
| iframe | 每个微应用独立开发部署，通过 iframe的方式将这些应用嵌入到父应用系统中 | 无限制 | 1. 技术栈无关，子应用独立构建部署 2. 实现简单，子应用之间自带沙箱，天然隔离，互不影响 | 体验差、路由无法记忆、页面适配困难、无法监控、依赖无法复用，兼容性等都具有局限性，资源开销巨大，通信困难 | 支持 | 正常 | 不支持 | 高 | 低 | 高 |
| Nginx 路由转发 | 通过Nginx配置实现不同路径映射到不同应用 | 无限制 | 简单、快速、易配置 | 在切换应用时触发发页面刷新，通信不易 | 支持 | 正常 | 不支持 | 正常 | 低 | 高 |
| Npm 集成 | 将微应用抽离成包的方式，发布Npm中，由父应用依赖的方式使用，构建时候集成进项目中 | 无限制 | 1. 编译阶段的应用，在项目运行阶段无需加载，体验流畅 2.开发与接入成本低，容易理解 | 1. 影响主应用编译速度和打包后的体积 2. 不支持动态下发，npm包更新后，需要重新更新包，主应用需要重新发布部署 | 不支持 | 慢 | 支持 | 高 | 高 | 正常 |
| 通用中心路由基座式 | 微应用可以使用不同技术栈；微应用之间完全独立，互不依赖。统一由基座工程进行管理，按照DOM节点的注册、挂载、卸载来完成。 | 无限制 | 子应用独立构建，用户体验好，可控性强，适应快速迭代 | 学习与实现的成本比较高，需要额外处理依赖复用 | 支持 | 正常 | 支持 | 高 | 高 | 正常 |
| 特定中心路由基座式 | 微应用业务线之间使用相同技术栈；基座工程和微应用可以单独开发单独部署；微应用有能力复用基座工程的公共基建。 | 统一技术栈 | 子应用独立构建，用户体验好，可控性强，适应快速迭代 | 学习与实现的成本比较高，需要额外处理依赖复用 | 支持 | 正常 | 支持 | 高 | 高 | 正常 |
| webpack5 模块联邦 | webpack5 模块联邦 去中心模式、脱离基座模式。每个应用是单独部署在各自的服务器，每个应用都可以引用其他应用，也能被其他应用所引用 | 统一技术栈 | 基于webpack5，无需引入新框架，学习成本低，像引入第三方库一样方便，各个应用的资源都可以相互共享应用间松耦合，各应用平行的关系 | 需要升级Webpack5技术栈必须保持一致改造旧项目难度大 | 支持 | 正常 | 支持 | 低 | 低 | 正常 |
对于选择困难同学来说，可以参考以下纬度进行方案技术的选型
| 参考纬度 | 是否能支持未来的迭代 |
|---|---|
| 稳定性 | 该方案是否经历了社区的考验，有较多的成熟案例，同时保持较高的 活跃性 |
| 可拓展性 | 支持定制化开发，提供较高的可拓展能力，同时成本可以在接受范围内 |
| 可控性 | 发生问题后，能够在第一时间内进行问题排查，以最快的响应速度来处理问题，修复的方案是否会依赖于外部环境 |
市面框架对比：
- magic-microservices 一款基于 Web Components 的轻量级的微前端工厂函数。
- icestark 阿里出品，是一个面向大型系统的微前端解决方案
- single-spa 是一个将多个单页面应用聚合为一个整体应用的JavaScript 微前端框架
- qiankun 蚂蚁金服出品，基于 single-spa 在 single-spa 的基础上封装
- EMP YY出品，基于Webpack5 Module Federation 除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力
- MicroApp 京东出品，一款基于WebComponent的思想，轻量、高效、功能强大的微前端框架
综合以上方案对比之后，我们确定采用了 qiankun 特定中心路由基座式的开发方案，原因如下：
- 保证技术栈统一 Vue、微应用之间完全独立，互不影响。
- 友好的“微前端方案“，与技术栈无关接入简单、像iframe一样简单
- 改造成本低，对现有工程侵入度、业务线迁移成本也较低。
- 和原有开发模式基本没有不同，开发人员学习成本较低。
- qiankun 的微前端有 3 年使用场景以及 Issue 问题解决积累，社区也比较活跃，在踩坑的路上更容易自救～
三、你需要明确的
微前端并不是万能的”解药“，没有正确治理，所有的 codebase 的归宿都是”屎山”
-
qiankun不是一个完整的微前端解决方案！
-
qiankun不是一个完整的微前端解决方案！！
-
qiankun不是一个完整的微前端解决方案！！！
微前端并不是万能的”解药“，没有正确治理，所有的 codebase 的归宿都是”屎山”
qiankun不是一个完整的微前端解决方案！
qiankun不是一个完整的微前端解决方案！！
qiankun不是一个完整的微前端解决方案！！！
1.微前端的运行时容器
- qiankun 所帮你解决的这一块实际上是微前端的运行时容器，这是整个微前端工程化里面其中一个环节
- 从这个角度来讲 qiankun 不算是一个完整的微前端解决方案，而是微前端运行时容器的一个完整解决方案，当你用了 qiankun 之后，你几乎能解决所有的微前端运行时容器的问题，但是更多的一些涉及工程和平台的问题，则需要我们去思考与处理。
- 我们的版本管控、配置下发、监控发布，安全检测、等等这些怎么做，都不是 qiankun 作为一个库所能解答的，这些问题得根据具体情况，来选择适合自己的解决方案 2. 迁移成本
- 对于老旧项目的接入，很难做到零成本迁移，在开发的时候要预留足够的踩坑，魔改代码的时间。如果是已经维持几年堆叠的屎山需要做好因为不规范编码，所产生的各种奇怪的兼容性问题，这个时候你甚至会怀疑，“微前端是否真的有必要?" 3. 技术栈的选择
- 微前端的核心不是多技术共存，而是分解复杂度，提升协作效率，支持灵活扩展，能把“一堆复杂的事情”变成“简单的一件事情”，但是也不是无脑使用的，广东话来说“多个香炉多只鬼”，每多一个技术栈都会增加：维护成本，兼容成本，资源开销成本，这些都会无形的拖累生产力。
- 基座应用与微应用之间，强烈推荐使用相同的技术栈，相同的技术栈可以实现公共依赖库、UI库等抽离，减少资源开销，提升加载速度，最重要的是：“减少冲突的最好方式就是统一”，通过约束技术栈可以尽可能的减少项目之间的冲突，减少工作量与维护成本。
4. 微前端初尝试
- 对于微前端的接入最好的时候就是，刚开始不久或重要性不是特别强的项目，一方面项目具备兼容微前端的工程能力，另一方面项目使用微前端方案的成本最低，不需要改太多代码
- 对于老旧项目的接入建议还是从边缘简单的模版入手，逐步分解。
7. 标准化才能提升生产力
- 混乱的项目会拖累生产效率，同时混乱的微前端也会加剧内耗，所以只有标准化才能提升生产力。
- 解决微前端的接入问题是最简单的，但是微前端接入后的：工程化，应用监控，应用规范，应用管理才是微前端中困难的地方，如果你只是想简单的嵌入一个应用，我推荐你的使用 ”iframe“
9. qiankun 不支持 Vite ！！！