微前端开发示意图，图片来自Micro Frontends
微前端是什么？
从“微服务架构”说起
想要了解微前端，我们先要了解一下"微服务(Microservices)"，因为微前端的概念是借鉴后端"微服务(Microservices)"的设计衍生而来。
如果你了解微服务是什么，那么你很容易就能理解什么是微前端。
微服务架构的思路就是将巨大的单体应用进行分解成小的、可相互连接的微服务，每个微服务可以实现独立的开发、部署。微服务的优势是：
- 解耦整体架构，降低复杂性。微服务解决了大型单体应用复杂性问题。
- 小单元分治，更易维护。微服务架构中，每个微服务实现独立开发部署、互不干扰。
- 易于扩展。微服务架构使得每个服务都可独立扩展。
接着，我们来看看“微前端”是什么？
微前端的定义
最早，微前端的提出来自“Micro Frontends - Cam Jackson”这篇文章，里面对“微前端”的定义是：
微前端是一种架构设计风格，在微前端架构中多个独立、可交付的前端应用被组装成一个更大的应用。原文: "An architectural style where independently deliverable frontend applications are composed into a greater whole"
- from micro frontends
微前端架构的一些好处：
- 解耦，自治团队的可扩展组织
- 较小，更紧密和可维护的代码库
- 能够以比以前更多的增量方式升级，更新甚至重写前端的功能
通过对比，你就会发现“微前端”和“微服务”的设计风格是一样的。
微前端的适用场景
SPA/MPA是前端最常见的开发方式，能够满足大多数的场景。但是随着业务发展，会出现下列情况：
- 项目越来越大、越来越复杂。
- 需要更多人力参与到项目协作。
- 新项目越来越多。新业务的不断拓展需要增加新项目。
- 老项目需要合并、整合。伴随业务整合，旧项目也需要整合。
于是，微前端顺势而生。微前端方案的优势：
- 更好地多人协作开发。
- 便于整合多个应用。
微前端最佳实践
single-spa类框架的局限性
微前端架构示意图，来自: Micro frontends—a microservice approach to front-end web development
自从微前端的概念被提出来之后，市面上出现了不少“微前端框架”。最广为人知的是single-spa，国内举个典型是阿里飞冰。这里，将这类框架通称为“single-spa类框架”。
single-spa类框架一般会提供下列能力：
- 框架自由采用。可以在项目中多个框架(Angular、React或者Vue)可以和谐共处。这个更加适合于整合多个不同技术栈的老旧系统。
- 延迟加载子应用。不同的子应用只有在访问到的时候，才会加载。
- 实现子应用独立开发部署。多个小团队共同开发一个大型项目的时候，可以实现子应用的独立技术选型和开发部署。
single-spa类框架的实现原理：拦截路由，根据不同路由规则渲染对应的子应用。
single-spa类框架的局限性：
- 很多新项目并不需要同时采用多个框架。
- single-spa类框架本身有学习、维护成本。
微前端真正的使用场景很少
截至2019年12月06日，single-spa的GitHub项目数据，来自：CanopyTax/single-spa: Microfrontends made easy
从上图可以看到，single-spa才被617个项目用到。而国内阿里开源的项目alibaba/ice为0采用，蚂蚁金服开源的umijs/qiankun才被35个使用。
说明一点：single-spa类框架真正的使用场景，很少。
为何会这样呢？我的观点是：
- 新项目一般不会特地采用多框架进行开发。
- 老项目整合一般直接使用iframe方案。
总结一句：新项目采用single-spa显得“过度设计”，老项目采用single-spa改造成本很大。
所以，微前端框架真正的使用场景很少。
最好的微前端方案——单项目模块化SPA
单项目模块化SPA示意图
两年以上的前端团队，基本都会有不少老项目存在，各个项目间技术栈参差不齐。越老的前端团队，其项目间的差异越大，因为近十年是前端技术百花齐放的十年。出现无数的框架、打包工具、UI库等等，2017年之后才有所缓和，因为前端进入新的阶段——工程化阶段。
假设所有的项目都采用同一套技术选型（例如：React+Ant），会有以下优势：
- 多个项目在需要合并时，可以较轻松合并。
- 学习、维护成本低，因为技术栈统一。
我认为，最简单的微前端解决方案就是——单项目模块化SPA。
“单项目模块化SPA”的具体方案如下：
- 统一技术栈（工具层、组件库等）。
- 通过不同打包命令分模块打包项目，每个模块是MPA或者SPA。
- 模块化部署。
这时候，轻松实现了“微前端架构”，同时也避免引入single-spa这类框架增加项目的复杂度。
iframe仍是最好的方案
为什么iframe仍是最好的方案？因为操作简单、维护成本也低。
我认为，最简单的整合旧系统的档案——通过iframe嵌入旧服务，因为：
- 使用简单，一个标签就能引入。
- 天然的“安全沙箱”隔离父子页面。
同时，iframe也是有天然的劣势的：
- 性能问题。页面需要加载。
- 页面间通信问题较为麻烦。iframe是一个“页面沙箱”，通常使用
postMessage与外界进行通信。
总结
以上是我对微前端的若干思考。总结就一句话——“微前端的设计风格值得了解，一些微前端框架暂不建议使用。”
