譯者序

在很多人眼里，微前端其實是老酒換新瓶的一個說法。

十多年前，單頁應用還沒有大行其道，頁面劃分即業務劃分。那時，微架構還不為大部分人所知。后來，當開發人員需要在同一個頁面中整合不同的功能邏輯時，可選的路徑大致有兩條：要么使用 iframe 進行業務隔離，要么設計一套完備的模塊化開發流程。

如果不考慮體驗問題，單就滿足“隔離”這一硬性要求來說，第一條路徑，也就是使用 iframe，算是一種近乎完美的解決方案。但是，由于性能、無法共享內存數據、用戶界面同步性等問題，iframe 在絕大多數場景中滿足不了業務開發人員的訴求（但本書作者依舊給出了對應的使用案例）。

第二條路徑就是通過分而治之的模塊化開發，根據自身訴求來定義沙盒環境。在諸如 Angular、React 和 Vue 等框架出現之前，這也并不是一件讓人撓頭的事情，因為無論業務如何分治，在同一個宿主環境中使用統一的工具庫（比如 jQuery）的開發模式，都要比處理技術基礎框架之間的沖突容易得多。

隨著前端技術的不斷演進，開發人員開始把精力更多地放在如何選取一個好用的業務框架和如何提高開發效率上，同時，還要保證優秀的用戶體驗。因此，在絕大多數場景中，開發人員會選擇后面這條路徑，但這也意味著協作成本和溝通成本的增加。

較大規模的公司都有基礎技術團隊來解決技術選型和架構遷移方面的問題。大家的設想都很美好：如果同一個系統的技術棧能夠統一，并且由唯一的技術決策者來進行規劃，那么開發、部署和運維將是多么完美的事情。

但現實情況往往事與愿違，原因很簡單：技術要為業務服務。

在中大型系統的開發過程中，因為業務迭代和整合，我們往往要面臨空間和時間兩個維度的問題。

從空間維度來說，我們可能需要解決不同技術框架的整合問題。這種整合有可能是技術驅動的，需要提升開發效率，從而合并功能相似的系統，并分別取其精華、去其糟粕；也可能是非技術原因，比如你所在的公司收購了另一家公司，需要整合資源并統一工作流程。

從時間維度來說，當舊系統已經嚴重影響到業務和技術的迭代效率時，特別是舊系統是一個龐大的單體應用，那么如何在不影響現有功能和用戶體驗的同時完成架構升級就成了一個巨大的挑戰。

好在我們有微前端！

本書的作者主要從以下幾個方面著手，講述了如何通過微前端來解決上述技術痛點。

● 如何決策。根據具體情況決定是否使用微前端和以何種方式集成微前端，包括微前端的橫向拆分模式和縱向拆分模式以及各自的利弊，如何在客戶端、邊緣側以及服務器端進行微前端的拆分。

● 技術選型。在項目生命周期的各個節點——開發階段、編譯階段、流水線發布及部署階段——如何實踐微前端，如何同微服務結合實現全棧微架構。

● 協作和開發體驗。如何在分布式的團隊中實踐微前端，如何讓開發體驗團隊更好地服務業務開發團隊。

● 應對具體場景。在面對龐大、舊的單體應用時，如何階段性地引入微前端，如何利用微前端將不同的業務框架整合到同一個項目中。

需要強調的是，本書作者并沒有通過附加大量的代碼來講解微前端的概念，而是嘗試在讀者的心智中植入一個微前端決策框架。但這并不表示本書中全都是形而上學的理論。在后面的章節中，作者通過案例講解了微前端的具體實施過程。在附錄中，作者還為讀者呈現了他與行業中有相關開發經驗的技術先鋒的對話，分享了他們有關微前端的真知灼見。

還需要提醒讀者的是，本書作者“旁征博引”了大量的微前端框架和基礎庫，如果讀者想更好地了解微前端并且明白作者的意圖，不妨嘗試在 GitHub 和搜索引擎上獲取相關的倉庫信息，了解具體項目的背景及其所涉及的問題領域。

本書的翻譯過程并非一帆風順，我們的翻譯和作者的寫作是同步進行的，但是，原書在最終付梓之前做了大量的更改，導致我們不得不重新修訂譯文。不過，我們也通過對比這些更改更深地理解了作者的意圖。由于本書涉及了大量的概念，因此我們在翻譯期間從團隊中引入了很多譯者進行交叉校對，他們（排名不分先后）是：閆文開、羅怡、劉悅、時芹芹、張起、劉胡粵、徐林楓、李雪燕、李宇航（校對）、楊珺（校對）、王永青（校對）、樊中愷（統稿 / 校對）。

此外，還要感謝圖靈公司的謝婷婷和朱鴻兩位編輯。謝婷婷老師全面把控項目進度，在本書作者還在創作階段就引入了譯者同步翻譯，創造了一種新的合作模式。本書中的專業概念和專業術語較多，朱鴻老師不辭辛苦，對照原文，字斟句酌地進行編輯加工，處理了譯文中前后不一致和有歧義的問題。我對她們認真負責的精神和專業的態度非常敬佩。在此，我想對圖靈公司的編輯表示由衷的感謝。

 

樊中愷 @ 百度 KFive

2022 年 5 月