好的前端开发很难。 扩展前端开发，让多个团队可以同时开发一个大型复杂的产品就更难了。在本文中，我们将描述将前端单体分解成许多更小、更易于管理的部分的最新趋势，以及这种架构如何提高处理前端代码的团队的效率和效率。 除了讨论各种好处和成本外，我们还将介绍一些可用的实现选项，我们将深入研究演示该技术的完整示例应用程序。

近年来，微服务大受欢迎，许多组织使用这种架构风格来避免大型单体后端的局限性。虽然关于这种构建服务器端软件的风格已经写了很多，但许多公司仍在与单体前端代码库作斗争。

也许您想构建一个渐进式或响应式 Web 应用程序，但找不到一个简单的地方来开始将这些功能集成到现有代码中。也许您想开始使用新的 JavaScript 语言功能（或可以编译为 JavaScript 的无数语言之一），但您无法将必要的构建工具放入现有的构建过程中。或者，也许您只是想扩展您的开发，以便多个团队可以同时处理单个产品，但现有单体的耦合性和复杂性意味着每个人都在互相踩踏。这些都是真正的问题，都会对您有效地为客户提供高质量体验的能力产生负面影响。

最近，我们看到越来越多的人关注复杂的现代 Web 开发所需的整体架构和组织结构。特别是，我们看到出现了将前端单体分解为更小、更简单的块的模式，这些块可以独立开发、测试和部署，同时仍然作为一个单一的有凝聚力的产品出现在客户面前。我们称这种技术为微前端，我们将其定义为：

一种架构风格，其中可独立交付的前端应用程序组合成一个更大的整体。

我们从微前端看到的一些主要好处是：

• 更小、更有凝聚力和可维护的代码库
• 具有解耦、自治团队的更具可扩展性的组织
• 能够以比以前更多的增量方式升级、更新甚至重写前端的某些部分
• 这些突出优势与微服务可以提供的优势相同，这并非巧合。

当然，在软件架构方面没有免费的午餐——一切都是有代价的。一些微前端实现可能导致依赖项重复，增加用户必须下载的字节数。此外，团队自主性的急剧增加可能导致团队工作方式支离破碎。尽管如此，我们相信这些风险是可以管理的，而且微前端的好处往往大于成本。

收益

我们不是根据特定的技术方法或实现细节来定义微前端，而是强调出现的属性及其带来的好处。

增量升级

对于许多组织来说，这是他们微前端之旅的开始。旧的、大型的前端单体被过去的技术堆栈或在交付压力下编写的代码所阻碍，并且已经到了完全重写很诱人的地步。为了避免完全重写的危险，我们更愿意逐个扼杀旧的应用程序，同时继续向我们的客户提供新功能，而不会被单体应用拖累。

这通常会导致微前端架构。一旦一个团队获得了在对旧世界几乎没有修改的情况下将功能一路投入生产的经验，其他团队也将希望加入新世界。现有的代码仍然需要维护，在某些情况下，继续向其添加新功能可能是有意义的，但现在可以选择。

最终结果是，我们获得了更多的自由，可以对产品的各个部分进行逐案决策，并对我们的架构、依赖项和用户体验进行增量升级。如果我们的主框架发生重大突破性变化，每个微前端都可以在有意义的时候升级，而不是被迫停止世界并立即升级所有内容。如果我们想尝试新技术或新的交互模式，我们可以以比以前更加孤立的方式进行。

简单、解耦的代码库

根据定义，每个单独的微前端的源代码将比单个单体前端的源代码小得多。这些较小的代码库对于开发人员来说往往更简单、更容易使用。特别是，我们避免了不应该相互了解的组件之间无意和不适当的耦合所带来的复杂性。通过在应用程序的有界上下文周围绘制更粗的线，我们使这种意外耦合更难出现。

当然，单一的、高层次的架构决策（即“让我们做微前端”）并不能替代良好的老式干净代码。我们并没有试图让自己免于考虑我们的代码并努力提高其质量。相反，我们试图让错误的决定变得困难，而好的决定变得容易，从而使自己陷入成功的陷阱。例如，跨有界上下文共享域模型变得更加困难，因此开发人员不太可能这样做。类似地，微前端促使您明确和深思熟虑地了解数据和事件如何在应用程序的不同部分之间流动，无论如何我们都应该这样做！

独立部署

与微服务一样，微前端的独立部署能力是关键。这会缩小任何给定部署的范围，从而降低相关风险。 无论您的前端代码以何种方式或在哪里托管，每个微前端都应该有自己的持续交付管道，用于构建、测试和部署它一直到生产。我们应该能够在不考虑其他代码库或管道的当前状态的情况下部署每个微前端。

旧的单体应用是否处于固定的、手动的、每季度的发布周期，或者隔壁的团队是否将一个半完成或损坏的功能推送到他们的主分支中都无关紧要。

如果给定的微前端准备投入生产，它应该能够这样做，并且该决定应该由构建和维护它的团队决定。

自治团队

作为将我们的代码库和我们的发布周期解耦的更高层次的好处，我们在拥有完全独立的团队方面还有很长的路要走，他们可以拥有一个产品的一部分，从构思到生产再到更远。 团队可以完全拥有为客户提供价值所需的一切，这使他们能够快速有效地行动。 为此，我们的团队需要围绕业务功能的垂直切片组建，而不是围绕技术能力。 一种简单的方法是根据最终用户将看到的内容划分产品，因此每个微前端封装应用程序的单个页面，并由单个团队端到端拥有。 与围绕技术或“横向”问题（如样式、表单或验证）组建团队相比，这为团队工作带来了更高的凝聚力。

总结

简而言之，微前端就是将大而可怕的东西切成更小、更易于管理的部分，然后明确它们之间的依赖关系。 我们的技术选择、我们的代码库、我们的团队和我们的发布流程都应该能够彼此独立地运行和发展，而无需过度协调。