原文地址前端开发好难。扩展前端开发以便多个团队可以同时处理大型复杂产品更加困难。在本文中，我们描述了将前端整体分解为许多更小、更易于管理的部分的最新趋势，以及这种架构如何提高团队处理前端代码的效率和效力。除了讨论各种收益和成本之外，我们还将讨论一些可用的实施选项，并将深入研究一个演示该技术的完整示例应用程序。微服务近年来大受欢迎，许多组织使用这种架构风格来避免大型单一后端的限制。虽然关于这种构建服务器端软件的风格已经写了很多，但许多公司仍然在与单一的前端代码库作斗争。也许您想构建一个渐进式或响应式Web应用程序，但找不到一个容易的地方开始将这些功能集成到您现有的代码中。也许你想开始使用一种新的JavaScript语言特性（或无数种编译成JavaScript的语言之一），但你无法将必要的构建工具融入你现有的构建过程中。或者你可能只是想扩展你的开发，以便多个团队可以同时处理一个产品，但现有单体的耦合和复杂性意味着每个人都在互相踩踏。这些都是真正的问题，都会对您有效地为客户提供高质量体验的能力产生负面影响。最近，我们看到越来越多的人关注复杂的现代Web开发所需的整体架构和组织。特别是，我们已经看到了将前端整体分解为更小、更简单的块的模式，这些块可以独立开发、测试和部署，同时仍然作为一个单一的内聚产品出现在客户面前。我们将这种技术称为微前端，我们将其定义为：一种架构风格，其中可独立交付的前端应用程序被组合成一个更大的整体。我们从微前端看到的一些主要好处是：更小、更内聚和可维护的代码库与解耦，更具可扩展性的组织和自治团队能够以比以前更多的增量方式升级，更新或更新的显着优势并非巧合甚至重写部分前端也是微服务可以提供的相同优势。当然，在软件架构方面没有免费的午餐——一切都是有代价的。一些微前端实现可能导致依赖项重复，增加用户必须下载的字节数。此外，团队自主权的急剧增加可能导致团队工作方式分散。尽管如此，我们相信这些风险是可控的，而且微前端的好处往往大于成本。好处我们没有根据特定的技术方法或实现细节来定义微前端，而是强调出现的属性及其带来的好处。增量升级对于许多组织来说，这是他们微前端之旅的开始。旧的大型前端单体受到过去的技术堆栈或在交付压力下编写的代码的阻碍，并且已经达到了完全重写的诱人程度。为了避免完全重写的危险，我们宁愿一个一个地杀死遗留应用程序，同时继续为我们的客户提供新功能，而不会被单体拖累。这通常会导致微前端架构。一旦一个团队在对旧世界进行少量修改的情况下获得了将功能一直用于生产的经验，其他团队也会希望加入新世界。现有代码仍然需要维护，在某些情况下，继续向其添加新功能可能是有意义的，但现在这是一种选择。最终结果是我们获得了更多的自由，可以根据具体情况对产品的各个部分做出决策，并对我们的架构、依赖项和用户体验进行增量升级。如果我们的主要框架发生重大变化，每个微前端都可以在有意义的时候升级，而不是被迫停止世界并立即升级所有东西。如果我们想尝试新技术或新的交互模式，我们可以采用比以前更加孤立的方式进行。简单、解耦的代码库根据定义，每个单独的微前端的源代码将比单个单体前端的源代码小得多。这些较小的代码库往往更简单，更易于开发人员使用。特别是，我们避免了不应相互了解的组件之间无意和不适当耦合的复杂性。通过在应用程序的限界上下文周围绘制更粗的线，我们使这种意外耦合更难发生。当然，一个单一的、高层次的架构决策（即“让我们做微前端”）并不能替代好的老式的干净代码。我们并不是要让自己免于思考我们的代码并努力提高其质量。相反，我们试图让错误的决定变得艰难，而好的决定变得容易，从而让自己陷入成功。例如，跨限界上下文共享域模型变得更加困难，因此开发人员不太可能这样做。同样，微前端促使您明确而深思熟虑地理解数据和事件如何在应用程序的不同部分之间流动，无论如何我们都应该这样做！独立部署和微服务一样，微前端的独立部署能力是关键。这缩小了任何给定部署的范围，从而降低了相关风险。无论您的前端代码以何种方式或在何处托管，每个微前端都应该有自己的持续交付管道，用于构建、测试和部署它一直到生产。我们应该能够在不考虑其他代码库或管道的当前状态的情况下部署每个微前端。无论旧的整体是否处于固定的、手动的、季度发布周期，或者隔壁的团队是否将半成品或损坏的功能推送到他们的主分支，都无关紧要。如果给定的微前端已准备好投入生产，它应该能够这样做，并且该决定应该由构建和维护它的团队做出。自治团队作为将我们的代码库和发布周期分离的更高层次的好处，我们距离拥有完全独立的团队还有很长的路要走，他们可以拥有从构思到生产的部分产品，甚至更进一步。团队拥有为客户提供价值所需的一切，使他们能够快速有效地采取行动。为此，我们的团队需要围绕业务功能的垂直部分进行组织，而不是围绕技术能力。一种简单的方法是根据最终用户将看到的内容来划分产品，因此每个微前端都封装了应用程序的单个页面，并由一个团队端到端拥有。与围绕技术或“水平”问题（如样式、表单或验证）组建团队相比，这为团队工作带来了更高水平的凝聚力。简而言之，微前端就是将大而可怕的东西切割成更小、更易于管理的部分，然后阐明它们之间的依赖关系。我们的技术选择、我们的代码库、我们的团队和我们的发布过程都应该能够在没有过度协调的情况下相互独立地运作和发展。更多Jerry原创文章在这里：《王子熙》：
