前端架构演进 - 从单体到微前端（理论篇）

我们首先需要认识到每一个系统的架构都不应该是一成不变的，为了应对业务的变化，我们不应该只有重写这一个选项。但往往架构的迁移业务方不会给开发人员预留充足的时间，在短时间内平滑地将旧的架构向新的架构演进就成为了一个需要解决的问题。

本文将从一个我最近经历的项目出发，讲解我们是如何在两周时间内将一个单体前端应用演化为一个微前端应用的。

为什么有这次演进

不是为了解决问题胡乱上莫名其妙的解决方案就是耍流氓。微前端和微服务一样都是为了解决问题而诞生的解决方案，先看看你的项目是不是也遇到了这些问题，再决定做不做吧。

首先我们项目是一个 To B 的交付项目，是某组织为其多个部门协调合作为愿景而设想的一个系统。各个部门的工作人员为了完成各自的业务需要访问该系统下的一个或多个子系统。

在这样的业务场景下在项目开始之初后端很自然地选择了微服务作为业务解耦和降低系统复杂度的解决方案，但前端因为考虑不周加上客户比较保守并没有采取微前端的解决方案，而是以分文件目录的方式尝试区分各个子系统。

在第一个子系统顺利完成交付后我们意识到了一些问题：

• 一期项目上线后转由公司内另外的组维护，我们在做后面的项目时难免会修改到一期或者公用的代码，两个团队势必会造成代码冲突
• 整个系统过于庞大，我们的体量没办法吃下整个合同，可预见未来会有第三方甚至第四方公司加入交付，现在的单体应用不但会造成大量的团队代码冲突，而且限定了整个项目的技术栈，不利于后期的跨团队合作
• 虽然我们的应用通过 AWS EKS 部署，没有宕机的烦恼，但是现在的架构无法实现独立部署，每一次子系统的部署需要对整个应用进行打包，同时如果一个应用挂了，将会影响整个系统，微前端可以在这件事上做得更好

演进发生的时机

架构需要发生改变往往是因为开发人员发现当前的架构没办法应对业务的发展和变化，需要改变架构来适应新的业务。

也有可能是当前业务已经复杂到一定程度，需要对架构做一些改变来对业务做一些解耦降低整个系统的复杂度，使系统更易维护。

而不管是什么原因，在真正开始改变架构时都需要在交付的过程中花费额外的时间精力。但前面我们也提到过，往往业务方不会给足够的时间来让开发人员完成架构的演进。

选择一个恰当的时机也就成为了一个重要的点。

就我们的情况而言，时机在一期项目上线后，二期项目准备阶段，于是我们在新项目的第 0 个迭代启动了前端架构演进。

而如果我们就是连两个周的时间都没有，那么就真的只能在交付的过程中加入一些 tech 卡，在别的分支上边交付边改进。

目标

首先既然是架构的演进，那么就不会有完成的那一天，但是应该有一个最小的目标，只要达成了这个最小的目标，已经能解决开发过程中的主要问题，这次演进就算是达到目的了，基于此我们在演进开始前规划了相应目标：

1. 不动基础设施，尽最大可能节省工作量，将所有应用打包后部署到同一个 nginx，将不同的应用放在不同的 folder 下，后续项目稳定后再推动客户拆分基础设施
2. 先做最坏的打算，假如我们两个星期内完不成拆分该怎么办
3. 保持 master 代码不动，计划后续如何在 master 代码分支上也能继续开发，同时新建分支完成代码拆分工作
4. 保持现有 pipeline 不动，用于支持现有 master 分支代码，新建一条全新的 pipeline 适配新的应用
5. 先只拆分整个应用的代码部分，时刻与 BA 和 后端小伙伴保持沟通，以业务形式和权限设计来指导前端如何拆分

技术选型

这个部分不一定每一次演进都会有，在我们的这个案例中，因为我们需要将一个单体应用拆分成微前端，为了减少拆分的工作量，增加项目的可维护性，我们需要挑选一个合适的微前端框架来解决这个问题。

说来也巧，在做出这个决定不久，公司发布了第23期技术雷达，我们关注到了 single-spa 做为一个微前端框架已经进入到了”实验“象限。同时进入我们视野的还有以 single-spa 为基础的 qiankun。

在使用 single-spa 完成一个小 demo 后我甚至都没有了解 qiankun 就已经决定使用 single-spa 了，原因有以下几点：

• 生态完备，官网的文档很详细，并且有社区和官方的一系列代码库例子，同时还有上传在油管和 B 站的各种科普视频
• 已经能解决我们想要解决的所有问题，并且从各个渠道搜索来看没有致命缺陷
• 寻求帮助响应极快，我在写 demo 时遇到了一个没法实现的需求，当晚我在官方 slack 提问，第二天一早就收到解决回复

任务拆解

遇到了合适的时机，明确了需要达成的目标，完成了选型后要做的就是开动了，但是不得不再次提醒的是，我们需要做的是平滑演进，所以最重要的步骤其实是区分各类任务的优先级，通常我们会将任务划分成以下几类：

• 必须要在短时间内完成的任务 - 这些任务如果不在这段时间内完成可能会 block 接下来的业务开发，可能会对未来的交付产生风险
• 可以晚点做的任务 - 这些任务不会 block 业务的开发，但是从业务和技术上来说都是应该完成的，而且越往后做这些任务所花费的资源将越多
• 可做可不做的任务 - 这些任务往往是为了提升开发体验，不会直接影响整个应用或业务
• 可以不用做的任务 - 这些任务可以做，但是由于各种原因不在此次计划中，可以推迟到未来时机成熟后完成

总结

在日常开发过程中，我们需要站在一个高位往前看，确认现在的架构是否能支撑未来的业务形式和变化，及时计划架构调整和演进。

最重要的是，大多数架构的演进都是在时间不允许的情况下开始的，这时候我们需要对整个演进有一个计划，对所有的任务排列优先级，先做最重要的那一部分，不重要的延迟决定，然后舍弃一些东西。

另一件重要的事情是千万不要在这个过程中自己给自己加戏，作为开发人员，大家都想把每一个技术改进做到最好，但是给自己加戏的后果往往就是啥都想做好但是最后啥也没做好。

成功交付的前提是平滑演进。