https://mengsixing.github.io/blog/devops-microfrontend.html#%E6%8B%86%E5%88%86%E6%96%B9%E6%A1%88%E8%B0%83%E7%A0%94
最近在做公司微前端，整理了一份微前端搭建清单，如果你正在考虑是否要做微前端，不妨做个参考。
1、需求分析
2、技术方案分析
3、拆分方案分析
4、部署流程分析
#需求分析
第一步，我们需要进行需求分析，以便真正清楚我们需要解决的问题是什么。
例如：
产品要新增一个业务模块
产品要修改项目样式
产品反馈项目启动太慢了
产品反馈页面跳转刷新很不友好
前两个需求是典型的业务需求，它的核心在于解决公司的业务问题，对于这一类需求，通常技术难度都不大，开发者只需要按照原型图，编写出对应的页面就可以了。
后两个需求是典型的技术需求，它的核心在于解决技术问题。通常来说，技术需求和用户体验有关，但不会影响项目功能，所以一般产品很少会提技术需求，都是由开发同学主导。
目前很多公司都不太重视技术需求，主要是因为和公司业务无关，不能带来真实可见的收益。其实不然，一些技术需求往往能产生巨大的成本收益，所以我们在做技术需求时，首先需要得到公司的支持。
#为什么选择微前端
解决一个技术需求，有很多种方法，为什么选微前端？
我们看过微前端的发展史就会明白，它并不是凭空出现的，而是项目在不断发展过程中形成的，解决项目臃肿的技术方案。
一个项目在刚成立时，体量很小，但随着项目不断做大，可能会出现以下问题：
工程膨胀
分支混乱
代码冲突
打包麻烦
维护困难
对于这些问题，很难找到一个完美的解决方案，于是就诞生了微前端。
有了微前端之后，我们能将一个大项目拆分成多个小项目，这样一来，每一个小项目就非常好优化了。在优化了所有的小项目后，我们再将这些小项目组合起来，就能形成一个完美的大项目了。
在实际项目中，如果遇到以下问题，可以考虑使用微前端：
项目太大，成为了典型的巨石应用，打包很慢。
项目开发者太多，多个同学开发同一套代码，经常出现代码冲突、或修改公共组件引发的 Bug。
项目太老，存在遗留模块，为了兼容它，限制了整个项目的发展。
项目技术栈不统一，使用了多种不同框架，每一种框架又有多个版本共存的情况。
项目由多个团队协同开发，一个功能需要等其他团队开发好之后，才能接着开发。
项目每次发布都是全量发布，即使是上线一个小模块，也可能导致整个项目挂掉。
项目由多个系统组成，完成一个功能需要不断地跳转多个系统页。
项目开发人员流动大，存在一些祖传代码难以维护，一般人都不好改。
项目需要一些试验田方案，即需要在某些模块做一些新技术尝试、框架升级等。
...
除此之外，还有很多实际情况没有列举完毕，不过没关系，只要我们明白了微前端的特点，就能判断任何情况。
#微前端特点
微前端的核心是解决巨石应用，它都有这些特点：
简单、松耦合的代码库
微前端架构倾向于编写和维护更小、更简单、更容易开发的项目。
技术栈无关，各项目可以使用不同的技术栈。
增量升级
支持渐进式重构，先让新旧代码和谐共存，再逐步转化旧代码，直到整个重构完成。
独立部署
每一个子应用都具备独立开发，持续部署，独立运行的能力。
团队自治
各子项目之间不存在依赖关系，保持隔离。
单一职责，每个子项目只做和自己相关的业务工作。
除此之外，微前端提供了一套新的生态系统。它通过拆分小项目，产生了大量的微应用。试想一下，如果大家都将微应用上传到云，那么就会构建一个非常强大的微应用云生态。我们在以后做需求时，也许就是选择各种适合的微应用，然后拼接起来，就完事了。
对此保持期待。
#微前端的缺点
当然，微前端也不是万能的，它也存在以下问题：
1、拆分的粒度越小，便意味着架构变得复杂、维护成本变高。
2、技术栈一旦多样化，便意味着技术栈混乱。
3、管理版本复杂、依赖复杂。
4、开发体验不太友好，开发时可能需要同时启动多个项目。
这些问题大多是因为项目拆分成多个项目之后，引发的沟通协作问题。
#技术方案调研
第二步，我们需要确定具体的微前端实现方式。
实现微前端有很多种方式：
路由分发式
通过 http 服务器的反向代理功能，来将请求路由到对应的应用上。
这种方式只是在路由层面看起来是一个项目，但实际上只是通过 a 标签连接了多个项目。
前端容器化
使用 iframe 作为容器。
seo 不友好。
需要考虑同源策略 cookie 管理。
需要自建一套应用管理、应用通信机制。
弹窗不友好。
浏览器后退按钮不友好。
前端微服务化
在不同的框架之上设计通讯、加载机制，以在一个页面内加载对应的应用。
常用的框架：qiankun，single-spa 都是这样做的。
最常用的方案，适合于快速上手。
微件化
打包出可以直接嵌入在页面上运行的代码，可能是一段 js，使用时直接引入即可。
需要实现一套微件管理机制，成本太高。
微应用化
通过软件工程的方式，在部署构建环境中通过 webpack 打包，组合多个独立应用成一个单体应用。
需要将多个项目打包成一个，所以技术栈需要保持统一。
应用组件化
将子项目都打包成 webComponent，在主项目中组合。
需要考虑 webComponent 兼容性。
下图是各种方案的优缺点：
这么多方案，各有利弊，我们应该如何选择呢？
如果只是想简单快速的做分离，不考虑 seo，可以用 iframe。
如果想做分离的同时，保持良好的单页体验，可以考虑 single-spa、qiankun 框架。
如果公司有很强的技术能力，再考虑自研或其他方案。
有了技术方案之后，微前端这条路就可以走通了，除此之外，还需考虑过渡方案。
#过渡方案
过渡方案指的是如何让微前端平滑上线。试想一下，如果在微前端改造时，项目来了新需求，这时应该怎么办？
对于这个问题，建议在做微前端改造时，最好快速上线：
首先将整个原项目当成一个大的子项目，进行微前端改造。
主项目快速搭建好路由、子应用管理，然后立即上线。
路由管理在处理子项目时，如果是原页面，先通过 a 标签跳转，如果是新页面，则使用前端 router 控制跳转。
后续逐渐拆分子项目，如果有新的子项目拆分完毕，只需要将 a 标签跳转改为前端 router 控制即可。
做完前两步之后，我们的架构就已经变成了微前端架构。
#拆分方案调研
第三步，我们需要想想，我们要怎么拆分我们的项目呢？
常见的拆分方案如下：
按照业务拆分
如：一个电商后台，包括商品管理、商家管理、物流管理等。
独立出每个业务项目，可以让整个项目结构清晰。
按照权限拆分
如：一个运营后台，管理员和普通运营看到的页面是不一样的。
独立出不同的权限项目，可以突出每个项目的使用范围。
按照变更的频率拆分
如：一个项目中，包含很少改动的祖传项目和经常改动的业务项目。
独立出变更频繁的项目，可以避免频繁更新可能导致整体项目挂掉的风险。
独立出很少改动的项目，可以让我们在核心业务上大展拳脚。
按照组织结构拆分
如：一个功能复杂的项目后台，由多个团队共同开发而成。
独立出不同团队的项目，可以避免开发冲突，部署冲突等问题。
跟随后端微服务拆分
如：后端已经做了不同模块的微服务划分，前端可以直接按照后端来就行了。
这种方式有利于前后端保持统一。
到了这里，我们已经完成了微前端的拆分，但并不是拆完了就结束了，我们还考虑一些拆分后的问题。
例如：
主项目和子项目的样式是否需要复用？
项目权限，是分开还是在统一管理？
应用之间如何进行通信？
这些问题往往和业务相关，我们在改造时自行判断即可。
#部署流程检查
最后一步，我们需要考虑部署流程。
当微前端开发完成之后，我们的项目由 1 个变成了 1 + n(子项目) 个，部署方式势必会发生变化。
传统的部署方式如下：
微前端项目部署方式如下：
可以看到，项目最终的结构已经完全不同了，开发，测试，部署的流程也都需要进行变化。
开发环境的部署
测试环境的部署
线上环境的部署
#开发环境的部署
开发环境其实不需要部署，通常是前端启动一个 localhost 页面，去调后端的接口进行开发。
需要注意的是：
子项目需支持独立启动，而不是在开发时启动所有项目，只需启动与业务相关的子项目即可。
子项目需支持独立部署，开发完成之后，只需要部署与业务相关的子项目即可。
#测试环境的部署
测试环境部署变化挺大的，而且涉及到了跨部门沟通，所以应该谨慎对待。
以前测试部署流程是：前端只需要提供一个打包文件，测试将文件解压后，放入指定的静态资源目录即可。
微前端之后的部署流程：前端需要提供主项目和相关子项目的打包文件，测试需要分别发布多个项目，才能进行测试。
这样改动之后，测试的工作量变大了，对于手动部署的测试来说，确实有很大的影响。为了减少测试的工作量，我们可以协助测试来搭建一套自动化部署工具。
很多大厂都有自己内部的云服务平台，就像阿里云的 k8s 控制台一样，测试可以在控制台上选择需要部署的前端、后端的分支，然后点击一键部署，就搞定了。
#上线环境部署
对于线上环境来说，运行的是 1 个主项目和 n 个子项目，每个项目都是独立部署且相互独立的，非常适合容器化部署，即：每一个项目都被部署到一个 docker 中，彼此通过主项目进行关联。
如图，所有的子项目都交由主项目管理。
如果公司内部做了持续部署，部署就会更加简单。
#思考与总结
本文从需求分析开始，一步一步理清了微前端需要注意的各种问题，以及一些解决方案，希望能对微前端感兴趣的你有所收获。
其实，微前端没有想象中的那么难，如果是用 qiankun、single-spa 等现成框架，学习成本都非常低，关键是要真正动手去做，只要开了头，后面的问题也就不是什么问题了。
