原文地址

好的前端开发很难。扩大前端开发，让多个团队能够同时开发一个大型简单的产品就更难了。在本文中，咱们将形容将前端单体分解成许多更小、更易于治理的局部的最新趋势，以及这种架构如何进步解决前端代码的团队的效率和效率。除了探讨各种益处和老本外，咱们还将介绍一些可用的实现选项，咱们将深入研究演示该技术的残缺示例应用程序。

近年来，微服务大受欢迎，许多组织应用这种架构格调来防止大型单体后端的局限性。尽管对于这种构建服务器端软件的格调曾经写了很多，但许多公司仍在与单体前端代码库作奋斗。

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

最近，咱们看到越来越多的人关注简单的古代 Web 开发所需的整体架构和组织构造。特地是，咱们看到呈现了将前端单体合成为更小、更简略的块的模式，这些块能够独立开发、测试和部署，同时依然作为一个繁多的有凝聚力的产品呈现在客户背后。咱们称这种技术为微前端，咱们将其定义为：

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

咱们从微前端看到的一些次要益处是：

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

当然，在软件架构方面没有收费的午餐——一切都是有代价的。一些微前端实现可能导致依赖项反复，减少用户必须下载的字节数。此外，团队自主性的急剧减少可能导致团队工作形式四分五裂。尽管如此，咱们置信这些危险是能够治理的，而且微前端的益处往往大于老本。

收益

咱们不是依据特定的技术办法或实现细节来定义微前端，而是强调呈现的属性及其带来的益处。

增量降级

对于许多组织来说，这是他们微前端之旅的开始。旧的、大型的前端单体被过来的技术堆栈或在交付压力下编写的代码所妨碍，并且曾经到了齐全重写很迷人的境地。为了防止齐全重写的危险，咱们更违心一一扼杀旧的应用程序，同时持续向咱们的客户提供新性能，而不会被单体利用连累。

这通常会导致微前端架构。一旦一个团队取得了在对旧世界简直没有批改的状况下将性能一路投入生产的教训，其余团队也将心愿退出新世界。现有的代码依然须要保护，在某些状况下，持续向其增加新性能可能是有意义的，但当初能够抉择。

最终后果是，咱们取得了更多的自在，能够对产品的各个局部进行逐案决策，并对咱们的架构、依赖项和用户体验进行增量降级。如果咱们的主框架产生重大突破性变动，每个微前端都能够在有意义的时候降级，而不是被迫进行世界并立刻降级所有内容。如果咱们想尝试新技术或新的交互模式，咱们能够以比以前更加孤立的形式进行。

简略、解耦的代码库

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

当然，繁多的、高层次的架构决策（即“让咱们做微前端”）并不能代替良好的老式洁净代码。咱们并没有试图让本人免于思考咱们的代码并努力提高其品质。相同，咱们试图让谬误的决定变得艰难，而好的决定变得容易，从而使本人陷入胜利的陷阱。例如，跨有界上下文共享域模型变得更加艰难，因而开发人员不太可能这样做。相似地，微前端促使您明确和三思而行地理解数据和事件如何在应用程序的不同局部之间流动，无论如何咱们都应该这样做！

独立部署

与微服务一样，微前端的独立部署能力是要害。这会放大任何给定部署的范畴，从而升高相干危险。无论您的前端代码以何种形式或在哪里托管，每个微前端都应该有本人的继续交付管道，用于构建、测试和部署它始终到生产。咱们应该可能在不思考其余代码库或管道的以后状态的状况下部署每个微前端。

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

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

自治团队

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

总结

简而言之，微前端就是将大而可怕的货色切成更小、更易于治理的局部，而后明确它们之间的依赖关系。咱们的技术抉择、咱们的代码库、咱们的团队和咱们的公布流程都应该可能彼此独立地运行和倒退，而无需适度协调。

更多 Jerry 的原创文章，尽在：” 汪子熙 ”: