[译] 微前端

• 原文地址：Micro Frontends

• 原文做者：Cam Jackson

• 译文出自：掘金翻译计划

• 本文永久连接：github.com/xitu/gold-m…

• 译者：Jenniferyingni

• 校对者：Stevens1995, Baddyo

作好前端开发不是件容易的事情，而比这更难的是扩展前端开发规模以便于多个团队能够同时开发一个大型且复杂的产品。本文将描述一种趋势，能够将大型的前端项目分解成许多个小而易于管理的部分，也将讨论这种体系结构如何提升前端代码团队工做的有效性和效率。除了讨论各类好处和代价以外，咱们还将介绍一些可用的实现方案和深刻探讨一个应用该技术的完整示例应用程序。

近年来，微服务 已经大受欢迎，许多组织使用这种架构风格来避免大型单体（monolithic）后端的局限性。关于如何在服务器端软件中也采用相似风格，虽然如今已经有许多相关的文章，可是许多公司仍然仍是在单体前端代码库中挣扎。

也许您想构建一个渐进式或响应式 Web 应用程序，但没法找到一个方法将这些特性整合到现有代码中。也许您想要使用 JavaScript 的新特性（或者是其余的能够编译成 JavaScript 的语言），但没法在项目已有的构建流程中加入新增的构建工具。又或者您可能只是想扩展您的开发规模，以便多个团队能够同时处理一个项目，但现有单体架构中的耦合和复杂性意味着每一个人负责的代码都会有不可避免的重合。这些都是真实存在的问题，这些问题都会对您有效地为客户提供高质量服务的能力产生负面影响。

最近，咱们愈来愈关注复杂的现代 Web 开发所需的总体架构和组织结构。值得一提的是，咱们看到了一种将前端总体分解为小而简单的块的模式。这些块能够独立开发、测试和部署，同时仍然聚合为一个产品出如今客户面前。 咱们将这种技术称为微前端，咱们将其定义为：

一种将多个可独立交付的小型前端应用聚合为一个总体的架构风格

在 2016 年 11 月发表的 ThoughtWorks 技术雷达期刊中，咱们将微前端归为了评估等级。后来又将其提高到了试验等级，最终列为了采纳等级，这意味着，咱们将微前端视为一种通过验证的方法，应该在合适的情境中采用它。

图 1：微前端在技术雷达中屡次被说起。

采用微前端的几个主要优势是：

• 体积小、易拼合且易于维护的代码库

• 更具扩展性的互相解耦且独立的团队

• 和之前相比能采用增量的方式，更易于对前端的某些部分进行升级、更新甚至重写

以上列出的优势与微服务的优势相同，这并不是巧合。

固然了，“天底下没有免费的午饭”，这句话在软件架构中一样适用，有些微前端实现可能致使依赖项的重复，增长了用户所需下载依赖的体积。除此以外，团队独立性的急剧增长会形成团队风格的差别。尽管如此，咱们认为这些是可控的风险，而且使用微前端所带来的好处要远远多于付出的代价。

优势

咱们会着重关注微前端的新属性以及它们带来的好处，而不是使用具体的技术或者实现细节来定义微前端。

增量升级

对于许多团队来讲，这是他们开始微前端之旅的初始缘由。那种陈旧而庞大的前端单体模式，被过期的技术栈或赶工完成的代码质量死死拖住后腿，其程度之严重，已经到了让人看了就禁不住想推翻重写的地步。为了不彻底重写的风险 ，咱们更加倾向于将旧的应用程序逐步地翻新，与此同时不受影响地继续为咱们的客户提供新功能。

这每每就须要用到微前端架构。一旦有团队能作到持续地增长新功能而且对原有的总体几乎不作修改，其它的团队也会争相效仿。已有的代码依旧须要维护，有些状况下继续为其增长新功能也是有必要的，可是如今微前端提供了可选项。

微前端能使咱们更加自由地对产品的各个部分作出独立的决策，使咱们的架构、依赖以及用户体验都可以增量升级。若是主框架中有一个非兼容性的重要更新，每一个微前端能够选择在合适的时候更新，而不是被迫停止当前的开发并当即更新。若是咱们想要尝试新的技术，或者是新的交互模式，对总体的影响也会更小。

简单、解耦的代码库

每一个单独的微前端项目的源代码库会远远小于一个单体前端项目的源代码库。这些小的代码库将会更易于开发。更值得一提的是，咱们避免了不相关联的组件之间无心形成的不适当的耦合。经过加强应用程序的边界来减小这种意外耦合的状况的出现。

固然了，一个独立的、高级的架构方式（例如微前端），不是用来取代规范整洁的优秀老代码的。咱们不是想要逃避代码优化和代码质量提高。相反，咱们加大作出错误决策的难度，增长正确决策的可能性，从而使咱们进入成功的陷阱。例如，咱们将跨边界共享域模型变得很困难，因此开发者不太可能这样作。一样，微前端会促使您明确并慎重地了解数据和事件如何在应用程序的不一样部分之间传递，这本是咱们早就应该开始作的事情！

独立部署

与微服务同样，微前端的独立可部署性是关键。它减小了部署的范围，从而下降了相关风险。不管您的前端代码在何处托管，每一个微前端都应该有本身的连续交付通道，该通道能够构建、测试并将其一直部署到生产环境中。咱们应当可以在不考虑其余代码库或者是通道的状况下来部署每一个微服务。作到即便原来的单体项目是固定的按照季度手动发布版本，或者其余团队提交了未完成的或者是有问题的代码到他们的主分支上，也不会对当前项目产生影响。若是一个微前端项目已准备好投入生产，它应该具有这种能力，而决定权就在构建而且维护它的团队手中。

图 2 : 每一个微前端都独立的部署到生产环境上

自主的团队

将咱们的代码库和发布周期分离的更高阶的好处，是使咱们拥有了彻底独立的团队，能够参与到本身产品的构思、生产及后续的过程。每一个团队都拥有为客户提供价值所需的所有资源，这就使得他们能够快速且有效地行动。为了达到这个目的，咱们的团队须要根据业务功能纵向地划分，而不是根据技术种类。一种简单的方法是根据最终用户将看到的内容来分割产品，所以每一个微前端都封装了应用程序的单个页面，并由一个团队全权负责。与根据技术种类或“横向”关注点（如样式、表单或验证）来组成团队相比，这会使得团队工做更有凝聚力。

图 3：每一个应用都由一个团队负责

总结

简而言之，微前端都是将巨大的东西分红更小、更易于管理的小部分，而后明确它们之间的依赖关系。咱们的技术选择、代码库、团队以及发布流程都应该可以彼此独立地运行和开发，不须要过多的协调。

咱们将分期发表这篇文章。后续的文章将介绍用于实现这些功能的替代集成方法、如何处理诸如样式和应用间通讯这类实现问题，咱们也将讨论一些缺点，还有介绍详细的示例实现。

想知道咱们什么时候发布后续部分，请订阅 RSS 源、Cam 的 twitter、或者 Martin 的 twitter。

重要修改

2019 年 6 月 10 日：发布第一期文章，探讨了微前端的优势

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。