微前端在解决什么问题？

关注「前端向后」微信公众号，你将收获一系列「用心原创」的高质量技术文章，主题包括但不限于前端、Node.js以及服务端技术

本文首发于 ayqy.net ，原文链接：http://www.ayqy.net/blog/why-...

写在前面

上一篇Micro Frontends已经从概念定义及实现思路上探究了微前端是什么，而要彻底理解微前端的话，还需要想清楚这些问题：

• 为什么需要微前端？
• 微前端能解决什么问题？组件化解决不了吗？
• 微前端究竟带来了什么？多技术栈并存？统一的技术栈不好吗？

一.背景：为什么需要微前端？

从最初的 HTML 内联脚本，到 9102 年的几十万行 JavaScript 代码，前端已经变得越来越重：

• 几个 G 的前端代码库
• 数百号前端开发人员
• 几 MB 的 Bundle Size

也越来越复杂：

• 层出不穷的框架、类库
• 各式各样的工程化体系
• 别具特色的跨端实践

因而需要一种分解复杂度、提升协作效率、支持灵活扩展的架构模式，于是，微前端登上了舞台

二.应用场景：微前端能解决什么问题？

微前端的理念类似于微服务，将庞大的整体拆成可控的小块，并明确它们之间的依赖关系。

通过拆分自治、支持多技术栈并存的方式，解决前端应用所面临的种种问题：

• 业务模块间日益加剧的耦合如何治理？
• 开发团队如何拆分、解耦，才能达到并行开发的目的？
• 新框架、新方案如何适应现有的工程环境（构建工具等）？
• 旧的框架类库如何平稳升级？

按业务功能将一整块前端应用分解成一系列更小、更内聚的微前端应用，同时通过明确的交互协议来管理这些应用间的依赖关系，实现不同业务模块的解耦。并将每个微前端应用交由独立团队负责，各自独立开发独立部署，充分利用并行性

另一方面，在多技术栈并存能力的加持下，不仅能够低成本引入新的技术实践，还允许低风险地替换产品局部功能，意味着依赖项升级、架构更替、UI 改版等重大决策都能以循序渐进的方式平稳落地：

1. 分解：将应用拆分成由一系列小型应用（子应用）组成的应用
2. 替换：替换子应用
3. 组合：确保替换过的能够和谐工作

通过微前端框架建立应用间的主从关系（1 个容器应用 + n 个子应用），接着进行局部替换，直至全部完成。然而，实践中通常需要在重构的同时保证新特性的持续迭代，所以实际流程可能是：

1. 抽象：增加一层主从关系，比如通过前端路由来控制
2. 扩展：新增子应用
3. 组合：原应用直接作为一整个子应用，带着新特性（新增的子应用）上线
4. 重构：（时间上能与扩展并进）分解、替换原应用

让重构等工作能够在相对较长的时间跨度下可控地渐进完成，而无需承担一刀切的资源需求与变更风险

组件化解决不了吗？

The problems they’re supposed to solve sound to me like they’re already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can’t agree on anything, even shared infra.

（摘自I don’t understand micro-frontends.）

诚然，_组件化也能实现拆分自治_，比如在 React 中可以通过React.lazy + Suspense的方式优雅地完成代码拆分

但这建立在组件模型统一（或者说技术栈一致）的前提下，而微前端的另一半优势在于能够打破单一技术栈的限制：

They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.

这是组件化、模块化等方案所无法满足的。同样的，git submodule、npm module 等拆分方案也都无法直接提供多技术栈并存的能力

三.意义：微前端究竟带来了什么？

工程价值

一半来自模块化带来的好处，诸如：

• 研发效率提升：多业务线并行开发，团队自治，独立迭代
• 交付成本降低：应用级功能复用
• 运维风险降低：变更范围缩小

另一半来自多技术栈并存能力的好处：

• 技术选择增多：不再与单一技术栈捆绑在一起，有助于新技术、新交互模式的实验性试错
• 可复用性增强：技术栈差异不再是功能复用的障碍，对于第三方模块尤为重要
• 重构风险降低：低风险局部替换，渐进地完成大规模重构

当然，_允许多技术栈并存，并不意味着鼓励引入尽可能多的技术栈_，因为更少的技术栈通常更有利于基础设施建设、资源复用与经验共享

商业价值

微前端视角下的 Web 应用是一系列独立功能的组合：

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.

（摘自What are Micro Frontends?）

因此，_微前端应用能够像云计算背景下的云服务一样能够即取即用_，实现应用模块级（第三方）功能的接入/融合，其商业价值在于：

• 细粒度、可组合的前端产品形态：前端产品/能力能够以更细粒度，更灵活的形态输出（像云服务一样按需自由组合）
• 微前端应用生态：规范化的微前端应用能够形成生态，进而产生类似于小程序的平台体系

参考资料

• Micro Frontends
• I don’t understand micro-frontends.