微前端：迈向现代化前端架构的社会技术之旅

作者 | Luca Mezzalira

译者 | 平川

多年来，分布式系统定义了我们对后端架构的思考方式。我们学会了将单体应用拆分成可以独立部署的服务，拥抱自治、快速反馈和持续变化的理念。但在前端领域，许多组织仍然深陷于后端已成功摆脱的困境：庞大的代码库会拖慢团队效率，耦合部署会带来风险隐患，而界面间的复杂关系会使任何变更都沦为恐惧管理的演练。

微前端的兴起不仅是对这种痛苦的反应；在更深层次上，它是社会技术演变的一部分。曾经推动后端模块化的力量现在正在重塑前端。随着组织对交付速度、自主权和持续现代化提出了更高的要求，我们的前端架构必须与团队的发展同步演进。

分布式前端时代已经到来，但它并不是由新兴的框架或花哨的工具所定义的。其核心在于我们如何围绕共同的目标整合人员、流程与架构：在确保可控的前提下加速价值交付。

在这篇文章中，你将了解微前端适用的场景，如何安全地演进现有系统，以及如何处理像路由、状态和用户体验这样的跨领域问题，而又不会中断交付。我们的目标是向大家展示，微前端不仅是一种趋势，而且是一种自然的社会实践演变。

利用微前端的独立性，多个团队合作开发同一个用户界面

重新思考微前端

这篇文章侧重于架构原则，而不是任何特定的框架或供应商解决方案。

通常，微前端是作为一种技术模式引入——将庞大的前端拆分成更小的、可独立部署的组成部分。但这种定义忽略了核心要义。微前端并非一种全新的技术栈，而是一种组织工作的新范式。它代表着社会技术层面的变革，恰如康威定律所揭示的：系统设计反应交互结构。

当团队不得不通过单一的发布序列进行协调时，决策速度会变慢。当每个变化都需要在多个领域同步时，创造力就会消退。其所造成的结果不仅仅是技术债务，还有组织惰性。微前端扭转了这种态势。它们允许团队自主掌控部分产品的端到端流程——领域、设计、交付——而不需要等待集中审批。

区分微前端和组件也很重要。组件是一种软件抽象机制，旨在标准化和重用单个应用程序或共享生态系统中的行为或界面。它们提高了一致性和可维护性。微前端则致力于最大化独立性和流变（flow）。它们的存在是为了减少认知负荷，使团队能够自主做出决策，并通过消除跨团队依赖来加速交付。因此，微前端的操作粒度比组件要粗得多。组件封装行为，微前端封装职责，例如由单个团队拥有和运营的系统的完整垂直切片。

这种自治并不是免费的。分布式系统总是伴随复杂性的增加。但当审慎地应用时，微前端便能解锁一种在客户端长期缺失的演进架构：能够按照业务发展的速度以迭代的方式安全地调整方向。

微前端的适用场景

不是每个系统都需要分解。由单个团队构建的小型产品采用模块化单体架构也能很好地实现。需要采用微前端架构的信号更多是组织层面的，而很少是技术层面的。

如果你的发布节奏随着团队的增长而放慢，如果一个领域的变更经常破坏其他领域，如果新工程师入职的时候感觉像是在多年积攒下来的相互交织的代码中进行考古挖掘——这些都是系统结构已无法满足其发展需求的症状。

微前端通过恢复本地自治来解决这个问题。每个团队可以独立交付并演进其技术栈，在响应客户需求时不需要等待组织的其他部分。投资回报很快就能看到，因为与完全重写不同，迁移到微前端是增量的。每一小步都能单独提供价值，这有助于降低风险并建立信心。

在我曾经合作过的一家媒体公司，从共享前端转变为特定于领域的微前端，将每次发布的协调工作减少了一半以上。部署频率在几个月内增加了十倍。这种势头为继续安全地进行前端迁移树立了信心。

但微前端不是万能的。对于小团队或复杂性不高的产品而言，所产生的额外开销可能会超过好处。我们的目标不是为了采用这个模式，而是要解决具体的问题：交付瓶颈、扩展限制和无法安全地现代化。

演进现有系统

采用微前端最困难的部分不是从头开始，而是演进已有的东西。大多数组织处于棕地环境中——有庞大、成熟的系统，无法简单地替换。这项工作的挑战在于，引入模块化而不破坏如今仍在运行的一切。

第一个原则是迭代思维。成功的迁移不需要为了构建新世界而关闭旧世界。相反，它以旧系统为脚手架，同时逐步引入新组件。每次迭代都带来可衡量的微小改进——这既是验证假设的机会，也是构建新能力、降低不确定性的契机。

迭代方法让你可以更快地看到投资回报率并降低风险。在进行现代化改造的过程中，业务仍然可以继续运作。这还有助于保持团队的积极性，因为每个版本都带来了看得见的进展，而不是等待数月后的“大揭秘”。

从大爆炸到增量修改

长期以来，后端现代化改造一直是使用 Strangler Fig 模式来逐步替换单体系统。同样的原则也非常适合前端。不是在同一页面中混合新旧代码，而是由边缘路由决定哪个版本的应用程序应该处理给定的请求。

通过在 CDN 或边缘层设置路由逻辑，你可以将特定路径——比如说 /checkout 或 /dashboard——转移到新构建的微前端，同时保持网站的其余部分不受影响。如果出现问题，可以即时回滚：只需修改一个路由规则，而无需重新部署或回退代码。

具有边缘计算的微前端迭代迁移

这种模式还解锁了强大的发布策略。你可以使用金丝雀部署、功能标志或按国家上线来测试新功能，并在全面发布之前收集真实的反馈。这种迭代节奏可以在技术与业务利益相关者之间建立起信任。每次部署都成为交付和学习的机会。

关键是要抵制在同一页面内混合新旧 UI 的诱惑。混合渲染系统会增加复杂性，并破坏体现微前端原有价值的隔离性。清晰的页面级或路由级边界可以确保迁移过程安全、可逆。

规划迁移

每次迁移都要在影响和安全之间进行平衡。你选择的第一个模块为随后的一切设定了基调。它应该足够有意义以便于证明迁移的价值，但又应该足够独立以便于最小化风险。

在实践中，这通常意味着从新功能或已经计划进行重大重构的模块开始。这样，迁移工作就自然地对齐了业务目标——你不是为了现代化而现代化，你正在打造新的能力。

第一个微前端应该是端到端的：从设计和开发到部署和观测。这个垂直切片将在一个可控的规模上揭示你稍后将面临的所有挑战——路由、共享依赖、认证、监控。从中学到的教训将指导后续的每一个迁移步骤。

把它想象成一次试验。如果有效，就可以把它当成一个可重用的模板；如果无效，你的损失也很小，但获得了宝贵的洞察。不要将迁移视为一个项目，而是作为一个持续的演进过程。每一次成功都积累了动力，每一个错误都完善了你的启发式方法。

采用模块化设计

当开始一个绿地项目时，微前端应该与业务领域对齐，而不是技术层。不要按框架或功能类型组织代码，而是设计独立的产品能力，这些能力对应真实的用户需求——目录、结算、个人资料、分析。

这种领域驱动的对齐便于微前端的扩展。每个模块都成为代码和通信的边界。团队从头到尾都在自己的空间里，选择自己的技术、部署管道和发布节奏。随着时间的推移，这不仅减少了系统之间的耦合，还减少了人与人之间的耦合。

这种自主性需要以信任契约为基础。共享指南——比如路由如何工作，设计令牌（Design Token）如何管理，或者可观察性如何实现——可以在不重新引入集中控制的前提下建立一致性。目标是形成一个团队联邦，而不是框架的无政府状态。

进化式架构并非要预测未来，而是要为未来做好准备。设计变革意味着优化可逆性。每个决策——工具选择、边界设定、依赖关系——都应该便于重新审视。能够长期存在的系统是那些能够适应变化的系统，而非那些从一开始就完美无缺的系统。

处理横切关注点

与任何分布式系统一样，最复杂的部分在于系统间的衔接点：路由、认证、共享状态和用户体验。这些无形的纽带让产品呈现出浑然一体的体验。

路由是迁移的核心。将其集中部署在边缘节点，既能避免在应用程序代码中混入路由逻辑，又可以简化回滚流程。采用绝对 URL 实现系统间的导航，可以确保跳转清晰、可预测。即使出现故障，用户也绝不会陷入未定义状态——系统会自动将其重定向至稳定版本。

在实践中，这种方法将边缘节点转变为迁移期间流量控制的唯一事实来源，而不是在每个前端内部嵌入条件逻辑，边缘函数可以在毫秒内决定请求应该发送到传统的单体应用还是特定的微前端。这也使得渐进式上线策略成为可能，例如金丝雀发布或蓝绿部署，而且不需要修改前端代码。

最有价值的其中一个优势是即时回滚，而不是让临时的路由侵入污染遗留代码库或新构建的微前端。如果出现问题，你只需在边缘节点切换路由规则，所有流量就会流回稳定版本，不需要重新部署，不需要在应用程序内进行手动干预，也不需要维护混合新旧 UI 代码的混合渲染层。系统之间的分离清晰、可逆，这对于长期运行的迁移至关重要。

集中式路由还减少了团队的认知负担，提高了平台的稳定性。开发人员不再需要在多个存储库中维护一次性路由逻辑或是在系统之间同步 URL 模式。它还简化了可观察性，因为所有传入请求都通过一个可以输出一致指标和日志的单一控制点。

身份验证的处理通常比团队的预期更简单。只要所有微前端与遗留应用共享相同的子域，它们就可以访问相同的 cookie 和会话数据。

在两个地方都实现更新后的令牌逻辑可以保持会话活跃，而且不需要复杂的跨应用程序通信。

微前端的状态管理应始终在应用程序本地，保持独立性并避免跨团队的耦合。当多个微前端需要通信时，首选是使用松耦合事件在必要时广播意图和数据，而不是强制共享运行时依赖。这既强化了架构边界，又能在需要时实现合作。

有些配置（如身份验证令牌、区域设置或功能标志）可以利用稳定的机制（如 cookie 或本地存储）在系统之间共享，或者向每个微前端注入轻量级上下文。关键是保持这个共享层尽可能小并可预测。

明智地拥抱重复

在分布式系统中，重复不是偶然，而是刻意为之。我们的目标并非消除所有重复，而是做出明智的决定，何处重复能帮助团队加速推进，何处又会引入不必要的开销。

好的启发式方法位于复杂性和变化率的交叉点。例如，一个设计系统在其早期阶段发展迅速，但随着时间的推移趋于稳定。系统成熟后，其发布周期就会减慢——毕竟没有人会每天修改设计系统。同样，跨多个微前端的共享日志库具有低波动性和清晰的行为模式，因此集中化是有意义的。另一方面，考虑下流媒体平台上复杂的视频播放器。其启发式方法可能会根据浏览器或设备来优化缓冲、延迟或启动时间。复杂性高，变化率高，因此重复只会增加维护的痛苦，而没有实际的好处。

反之，如果你面对的是一个简单的组件——比如说一个基本的字段表单或小型实用程序，它不经常变化，并且实现起来也只需要花费很少的精力，那么放心复用就行。抽象化可以在模式得到验证且一致性需求明确后再实施。

每个共享抽象都涉及治理、版本控制和所有权责任问题。将所有权留在负责微前端的团队内部可以简化流程并保持自主权。最好的抽象是自然出现的，而不是提前强加的。有意识的重复帮你提高了速度和灵活性；深思熟虑的整合为你提供了长期一致性。两者平衡即可实现分布式架构的优雅演进。

现代化改造的最快路径

关于微前端最持久的其中一个误解是：必须依赖微服务才能实现。事实并非如此。前端与后端的发展速度各不相同，而前端几乎总是更快。

微前端专注于团队如何构建和交付界面，而不是如何提供数据。只要 API 合约保持不变，前端就可以独立于后端进行现代化。你可以保留你的单体 API，并在它们之上引入模块化前端。前端的无状态特性使它们成为增量现代化的理想选择。

后端迁移往往耗时漫长，因为数据有引力。模式更改、复制策略和遗留依赖都可能会将时间线拉长数月甚至数年。相比之下，前端迁移几周内就能提供看得见的价值。你可以现在就开始改进性能、可维护性和用户体验，而无需等待后端也完成了现代化改造。

在我提供咨询的一家零售公司，将前端迁移到微前端大约用了 14 个月。后端现代化的时间是这个过程的两倍，但在后端仍然是单体架构的情况下，组织通过更快的发布和更好的用户体验很快就看到了价值。

前端可以引领潮流，作为分布式实践的试验场和更广泛组织变革的催化剂。

以人类的速度进行现代化

现代化不是一次性事件，而是一段旅程。当感觉遗留系统难以迁移时，重新开始的诱惑就会很大。但“大爆炸”方法很少成功。它会冻结业务进展，耗尽士气，最终停步于从未投入生产的部分重写。

微前端提供了一条不同的道路，一条与组织真正的演变方式一致的道路。它们让你以人类的速度前进：足够快可以体现进展，足够慢可以确保安全。它们鼓励实验、持续学习和本地所有权。

每一次迁移都是在理想架构和实际交付之间进行平衡。成功的团队愿意接受这样一个事实，就是不完美是这个过程的一部分。他们知道，好的架构不在于纯粹性，而在于流变。

如果有一个指导原则要记住，那就是：渐进胜过激进。迭代、学习和适应。今天构建的系统明天会变，这是特点，而不是缺陷。

对于探索这条道路的团队而言，分布式前端时代的核心并非框架或打包工具，而是设计的系统与组织架构能够持续、安全且有目标地演进。

小 结

微前端不仅是一种技术模式，更体现了现代组织构建软件的方式。它标志着从集中控制到分布式所有权的转变，从重大版本发布到持续交付的演进，从架构僵化到渐进式变革的进化。

通过迭代迁移——小处着手，快速学习，以业务目标为中心——你可以在不停止创新的情况下实现前端的现代化。后端是单体还是分布式并不重要。重要的是你安全演进并持续交付价值的能力。

在理想状态下，架构反映了人们的协作方式。当团队被赋予权力时，系统就会随之成型。微前端只是这一真理在架构层面的具体体现。

https://www.infoq.com/articles/adopt-micro-frontends/

声明：本文为 InfoQ 翻译，未经许可禁止转载。