想做好前端很难，做出可扩展的前端，从而让多个团队可以同时投身于一项复杂的大型产品项目就更难了。本文将介绍前端领域最近的一项变革：单体前端架构正在过渡到许多较小、较易管理的前端架构。我们还会展示这种新的体系结构怎样提升前端团队的效率和表现。除了讨论这种新趋势的好处与代价外，我们还将介绍一些可行的实现方案，并深入分析一个完整的微前端应用案例。

微服务近年来大受欢迎，许多组织转向了微服务以克服大型单体后端架构的局限。但虽然微服务在服务端很流行，很多企业在前端代码库上仍然在沿用问题多多的单体架构。

也许你想构建一个渐进式或响应式的 Web 应用，但却找不到一种将这些功能集成进现有代码中的简单途径;也许你想尝试 JavaScript 语言的新功能(或者是其他可以编译为 JS 的某种语言)，但你却无法将关键的构建工具融入已有的构建流程;或者你只是想扩展开发流程，让多个团队可以同时开发一种产品，但现有单体架构中的耦合度与复杂性让团队间的合作变得磕磕绊绊。这些都是很现实的问题，都会影响你们向客户交付高质量体验的能力。

微前端的定义

最近业界越来越关注复杂的现代化 Web 开发需要怎样的整体架构和组织结构这个问题。于是我们开始看到单体前端正在分解为更小、更简单的模块，这些模块可以各自独立开发、测试和部署，而它们组合在一起仍然对客户表现为一件单一完整的产品。我们将这种技术称为 微前端，其定义为：

“微前端是一种架构风格，其中众多独立交付的前端应用组合成一个大型整体。”

我们认为微前端的主要好处有：

• 更小，更紧密且更易维护的代码库。
• 组织更具扩展能力，其团队更加独立自治。
• 能够以更加增量式的风格来升级、更新前端，甚至重写部分前端代码。

这些核心优势与微服务的优势基本一致，这也不是什么巧合。

当然，软件架构领域没有免费的午餐：一切都要付出代价。一些微前端实现可能导致重复依赖，使用户不得不下载更多内容。此外，大幅提升的团队自治水平可能会让各个团队的工作愈加分裂。只不过我们认为这些风险都能控制在合理水平上，微前端终究还是利大于弊的。

好处

我们不会从具体的技术方法或实施细节角度来定义微前端，而是重点关注它的属性和好处。

增量升级

对于许多组织来说，追求增量升级就是他们迈向微前端的***步。对他们来说，老式的大型单体前端要么是用老旧的技术栈打造的，要么就充斥着匆忙写成的代码，已经到了该重写整个前端的时候了。一次性重写整个系统风险很大，我们更倾向一点一点换掉老的应用，同时在不受单体架构拖累的前提下为客户不断提供新功能。