译者序

在很多人眼里，微前端其实是老酒换新瓶的一个说法。

十多年前，单页应用还没有大行其道，页面划分即业务划分。那时，微架构还不为大部分人所知。后来，当开发人员需要在同一个页面中整合不同的功能逻辑时，可选的路径大致有两条：要么使用 iframe 进行业务隔离，要么设计一套完备的模块化开发流程。

如果不考虑体验问题，单就满足“隔离”这一硬性要求来说，第一条路径，也就是使用 iframe，算是一种近乎完美的解决方案。但是，由于性能、无法共享内存数据、用户界面同步性等问题，iframe 在绝大多数场景中满足不了业务开发人员的诉求（但本书作者依旧给出了对应的使用案例）。

第二条路径就是通过分而治之的模块化开发，根据自身诉求来定义沙盒环境。在诸如 Angular、React 和 Vue 等框架出现之前，这也并不是一件让人挠头的事情，因为无论业务如何分治，在同一个宿主环境中使用统一的工具库（比如 jQuery）的开发模式，都要比处理技术基础框架之间的冲突容易得多。

随着前端技术的不断演进，开发人员开始把精力更多地放在如何选取一个好用的业务框架和如何提高开发效率上，同时，还要保证优秀的用户体验。因此，在绝大多数场景中，开发人员会选择后面这条路径，但这也意味着协作成本和沟通成本的增加。

较大规模的公司都有基础技术团队来解决技术选型和架构迁移方面的问题。大家的设想都很美好：如果同一个系统的技术栈能够统一，并且由唯一的技术决策者来进行规划，那么开发、部署和运维将是多么完美的事情。

但现实情况往往事与愿违，原因很简单：技术要为业务服务。

在中大型系统的开发过程中，因为业务迭代和整合，我们往往要面临空间和时间两个维度的问题。

从空间维度来说，我们可能需要解决不同技术框架的整合问题。这种整合有可能是技术驱动的，需要提升开发效率，从而合并功能相似的系统，并分别取其精华、去其糟粕；也可能是非技术原因，比如你所在的公司收购了另一家公司，需要整合资源并统一工作流程。

从时间维度来说，当旧系统已经严重影响到业务和技术的迭代效率时，特别是旧系统是一个庞大的单体应用，那么如何在不影响现有功能和用户体验的同时完成架构升级就成了一个巨大的挑战。

好在我们有微前端！

本书的作者主要从以下几个方面着手，讲述了如何通过微前端来解决上述技术痛点。

● 如何决策。根据具体情况决定是否使用微前端和以何种方式集成微前端，包括微前端的横向拆分模式和纵向拆分模式以及各自的利弊，如何在客户端、边缘侧以及服务器端进行微前端的拆分。

● 技术选型。在项目生命周期的各个节点——开发阶段、编译阶段、流水线发布及部署阶段——如何实践微前端，如何同微服务结合实现全栈微架构。

● 协作和开发体验。如何在分布式的团队中实践微前端，如何让开发体验团队更好地服务业务开发团队。

● 应对具体场景。在面对庞大、旧的单体应用时，如何阶段性地引入微前端，如何利用微前端将不同的业务框架整合到同一个项目中。

需要强调的是，本书作者并没有通过附加大量的代码来讲解微前端的概念，而是尝试在读者的心智中植入一个微前端决策框架。但这并不表示本书中全都是形而上学的理论。在后面的章节中，作者通过案例讲解了微前端的具体实施过程。在附录中，作者还为读者呈现了他与行业中有相关开发经验的技术先锋的对话，分享了他们有关微前端的真知灼见。

还需要提醒读者的是，本书作者“旁征博引”了大量的微前端框架和基础库，如果读者想更好地了解微前端并且明白作者的意图，不妨尝试在 GitHub 和搜索引擎上获取相关的仓库信息，了解具体项目的背景及其所涉及的问题领域。

本书的翻译过程并非一帆风顺，我们的翻译和作者的写作是同步进行的，但是，原书在最终付梓之前做了大量的更改，导致我们不得不重新修订译文。不过，我们也通过对比这些更改更深地理解了作者的意图。由于本书涉及了大量的概念，因此我们在翻译期间从团队中引入了很多译者进行交叉校对，他们（排名不分先后）是：闫文开、罗怡、刘悦、时芹芹、张起、刘胡粤、徐林枫、李雪燕、李宇航（校对）、杨珺（校对）、王永青（校对）、樊中恺（统稿 / 校对）。

此外，还要感谢图灵公司的谢婷婷和朱鸿两位编辑。谢婷婷老师全面把控项目进度，在本书作者还在创作阶段就引入了译者同步翻译，创造了一种新的合作模式。本书中的专业概念和专业术语较多，朱鸿老师不辞辛苦，对照原文，字斟句酌地进行编辑加工，处理了译文中前后不一致和有歧义的问题。我对她们认真负责的精神和专业的态度非常敬佩。在此，我想对图灵公司的编辑表示由衷的感谢。

 

樊中恺 @ 百度 KFive

2022 年 5 月