作者 | Luca Mezzalira

譯者 | 平川

多年來，分布式系統(tǒng)定義了我們對后端架構(gòu)的思考方式。我們學(xué)會了將單體應(yīng)用拆分成可以獨立部署的服務(wù)，擁抱自治、快速反饋和持續(xù)變化的理念。但在前端領(lǐng)域，許多組織仍然深陷于后端已成功擺脫的困境：龐大的代碼庫會拖慢團隊效率，耦合部署會帶來風(fēng)險隱患，而界面間的復(fù)雜關(guān)系會使任何變更都淪為恐懼管理的演練。

微前端的興起不僅是對這種痛苦的反應(yīng)；在更深層次上，它是社會技術(shù)演變的一部分。曾經(jīng)推動后端模塊化的力量現(xiàn)在正在重塑前端。隨著組織對交付速度、自主權(quán)和持續(xù)現(xiàn)代化提出了更高的要求，我們的前端架構(gòu)必須與團隊的發(fā)展同步演進。

分布式前端時代已經(jīng)到來，但它并不是由新興的框架或花哨的工具所定義的。其核心在于我們?nèi)绾螄@共同的目標(biāo)整合人員、流程與架構(gòu)：在確?？煽氐那疤嵯录铀賰r值交付。

在這篇文章中，你將了解微前端適用的場景，如何安全地演進現(xiàn)有系統(tǒng)，以及如何處理像路由、狀態(tài)和用戶體驗這樣的跨領(lǐng)域問題，而又不會中斷交付。我們的目標(biāo)是向大家展示，微前端不僅是一種趨勢，而且是一種自然的社會實踐演變。

利用微前端的獨立性，多個團隊合作開發(fā)同一個用戶界面

重新思考微前端

這篇文章側(cè)重于架構(gòu)原則，而不是任何特定的框架或供應(yīng)商解決方案。

通常，微前端是作為一種技術(shù)模式引入——將龐大的前端拆分成更小的、可獨立部署的組成部分。但這種定義忽略了核心要義。微前端并非一種全新的技術(shù)棧，而是一種組織工作的新范式。它代表著社會技術(shù)層面的變革，恰如康威定律所揭示的：系統(tǒng)設(shè)計反應(yīng)交互結(jié)構(gòu)。

當(dāng)團隊不得不通過單一的發(fā)布序列進行協(xié)調(diào)時，決策速度會變慢。當(dāng)每個變化都需要在多個領(lǐng)域同步時，創(chuàng)造力就會消退。其所造成的結(jié)果不僅僅是技術(shù)債務(wù)，還有組織惰性。微前端扭轉(zhuǎn)了這種態(tài)勢。它們允許團隊自主掌控部分產(chǎn)品的端到端流程——領(lǐng)域、設(shè)計、交付——而不需要等待集中審批。

區(qū)分微前端和組件也很重要。組件是一種軟件抽象機制，旨在標(biāo)準(zhǔn)化和重用單個應(yīng)用程序或共享生態(tài)系統(tǒng)中的行為或界面。它們提高了一致性和可維護性。微前端則致力于最大化獨立性和流變（flow）。它們的存在是為了減少認(rèn)知負荷，使團隊能夠自主做出決策，并通過消除跨團隊依賴來加速交付。因此，微前端的操作粒度比組件要粗得多。組件封裝行為，微前端封裝職責(zé)，例如由單個團隊擁有和運營的系統(tǒng)的完整垂直切片。

這種自治并不是免費的。分布式系統(tǒng)總是伴隨復(fù)雜性的增加。但當(dāng)審慎地應(yīng)用時，微前端便能解鎖一種在客戶端長期缺失的演進架構(gòu)：能夠按照業(yè)務(wù)發(fā)展的速度以迭代的方式安全地調(diào)整方向。

微前端的適用場景

不是每個系統(tǒng)都需要分解。由單個團隊構(gòu)建的小型產(chǎn)品采用模塊化單體架構(gòu)也能很好地實現(xiàn)。需要采用微前端架構(gòu)的信號更多是組織層面的，而很少是技術(shù)層面的。

如果你的發(fā)布節(jié)奏隨著團隊的增長而放慢，如果一個領(lǐng)域的變更經(jīng)常破壞其他領(lǐng)域，如果新工程師入職的時候感覺像是在多年積攢下來的相互交織的代碼中進行考古挖掘——這些都是系統(tǒng)結(jié)構(gòu)已無法滿足其發(fā)展需求的癥狀。

微前端通過恢復(fù)本地自治來解決這個問題。每個團隊可以獨立交付并演進其技術(shù)棧，在響應(yīng)客戶需求時不需要等待組織的其他部分。投資回報很快就能看到，因為與完全重寫不同，遷移到微前端是增量的。每一小步都能單獨提供價值，這有助于降低風(fēng)險并建立信心。

在我曾經(jīng)合作過的一家媒體公司，從共享前端轉(zhuǎn)變?yōu)樘囟ㄓ陬I(lǐng)域的微前端，將每次發(fā)布的協(xié)調(diào)工作減少了一半以上。部署頻率在幾個月內(nèi)增加了十倍。這種勢頭為繼續(xù)安全地進行前端遷移樹立了信心。

但微前端不是萬能的。對于小團隊或復(fù)雜性不高的產(chǎn)品而言，所產(chǎn)生的額外開銷可能會超過好處。我們的目標(biāo)不是為了采用這個模式，而是要解決具體的問題：交付瓶頸、擴展限制和無法安全地現(xiàn)代化。

演進現(xiàn)有系統(tǒng)

采用微前端最困難的部分不是從頭開始，而是演進已有的東西。大多數(shù)組織處于棕地環(huán)境中——有龐大、成熟的系統(tǒng)，無法簡單地替換。這項工作的挑戰(zhàn)在于，引入模塊化而不破壞如今仍在運行的一切。

第一個原則是迭代思維。成功的遷移不需要為了構(gòu)建新世界而關(guān)閉舊世界。相反，它以舊系統(tǒng)為腳手架，同時逐步引入新組件。每次迭代都帶來可衡量的微小改進——這既是驗證假設(shè)的機會，也是構(gòu)建新能力、降低不確定性的契機。

迭代方法讓你可以更快地看到投資回報率并降低風(fēng)險。在進行現(xiàn)代化改造的過程中，業(yè)務(wù)仍然可以繼續(xù)運作。這還有助于保持團隊的積極性，因為每個版本都帶來了看得見的進展，而不是等待數(shù)月后的“大揭秘”。

從大爆炸到增量修改

長期以來，后端現(xiàn)代化改造一直是使用 Strangler Fig 模式來逐步替換單體系統(tǒng)。同樣的原則也非常適合前端。不是在同一頁面中混合新舊代碼，而是由邊緣路由決定哪個版本的應(yīng)用程序應(yīng)該處理給定的請求。

通過在 CDN 或邊緣層設(shè)置路由邏輯，你可以將特定路徑——比如說 /checkout 或 /dashboard——轉(zhuǎn)移到新構(gòu)建的微前端，同時保持網(wǎng)站的其余部分不受影響。如果出現(xiàn)問題，可以即時回滾：只需修改一個路由規(guī)則，而無需重新部署或回退代碼。

具有邊緣計算的微前端迭代遷移

這種模式還解鎖了強大的發(fā)布策略。你可以使用金絲雀部署、功能標(biāo)志或按國家上線來測試新功能，并在全面發(fā)布之前收集真實的反饋。這種迭代節(jié)奏可以在技術(shù)與業(yè)務(wù)利益相關(guān)者之間建立起信任。每次部署都成為交付和學(xué)習(xí)的機會。

關(guān)鍵是要抵制在同一頁面內(nèi)混合新舊 UI 的誘惑?；旌箱秩鞠到y(tǒng)會增加復(fù)雜性，并破壞體現(xiàn)微前端原有價值的隔離性。清晰的頁面級或路由級邊界可以確保遷移過程安全、可逆。

規(guī)劃遷移

每次遷移都要在影響和安全之間進行平衡。你選擇的第一個模塊為隨后的一切設(shè)定了基調(diào)。它應(yīng)該足夠有意義以便于證明遷移的價值，但又應(yīng)該足夠獨立以便于最小化風(fēng)險。

在實踐中，這通常意味著從新功能或已經(jīng)計劃進行重大重構(gòu)的模塊開始。這樣，遷移工作就自然地對齊了業(yè)務(wù)目標(biāo)——你不是為了現(xiàn)代化而現(xiàn)代化，你正在打造新的能力。

第一個微前端應(yīng)該是端到端的：從設(shè)計和開發(fā)到部署和觀測。這個垂直切片將在一個可控的規(guī)模上揭示你稍后將面臨的所有挑戰(zhàn)——路由、共享依賴、認(rèn)證、監(jiān)控。從中學(xué)到的教訓(xùn)將指導(dǎo)后續(xù)的每一個遷移步驟。

把它想象成一次試驗。如果有效，就可以把它當(dāng)成一個可重用的模板；如果無效，你的損失也很小，但獲得了寶貴的洞察。不要將遷移視為一個項目，而是作為一個持續(xù)的演進過程。每一次成功都積累了動力，每一個錯誤都完善了你的啟發(fā)式方法。

采用模塊化設(shè)計

當(dāng)開始一個綠地項目時，微前端應(yīng)該與業(yè)務(wù)領(lǐng)域?qū)R，而不是技術(shù)層。不要按框架或功能類型組織代碼，而是設(shè)計獨立的產(chǎn)品能力，這些能力對應(yīng)真實的用戶需求——目錄、結(jié)算、個人資料、分析。

這種領(lǐng)域驅(qū)動的對齊便于微前端的擴展。每個模塊都成為代碼和通信的邊界。團隊從頭到尾都在自己的空間里，選擇自己的技術(shù)、部署管道和發(fā)布節(jié)奏。隨著時間的推移，這不僅減少了系統(tǒng)之間的耦合，還減少了人與人之間的耦合。

這種自主性需要以信任契約為基礎(chǔ)。共享指南——比如路由如何工作，設(shè)計令牌（Design Token）如何管理，或者可觀察性如何實現(xiàn)——可以在不重新引入集中控制的前提下建立一致性。目標(biāo)是形成一個團隊聯(lián)邦，而不是框架的無政府狀態(tài)。

進化式架構(gòu)并非要預(yù)測未來，而是要為未來做好準(zhǔn)備。設(shè)計變革意味著優(yōu)化可逆性。每個決策——工具選擇、邊界設(shè)定、依賴關(guān)系——都應(yīng)該便于重新審視。能夠長期存在的系統(tǒng)是那些能夠適應(yīng)變化的系統(tǒng)，而非那些從一開始就完美無缺的系統(tǒng)。

處理橫切關(guān)注點

與任何分布式系統(tǒng)一樣，最復(fù)雜的部分在于系統(tǒng)間的銜接點：路由、認(rèn)證、共享狀態(tài)和用戶體驗。這些無形的紐帶讓產(chǎn)品呈現(xiàn)出渾然一體的體驗。

路由是遷移的核心。將其集中部署在邊緣節(jié)點，既能避免在應(yīng)用程序代碼中混入路由邏輯，又可以簡化回滾流程。采用絕對 URL 實現(xiàn)系統(tǒng)間的導(dǎo)航，可以確保跳轉(zhuǎn)清晰、可預(yù)測。即使出現(xiàn)故障，用戶也絕不會陷入未定義狀態(tài)——系統(tǒng)會自動將其重定向至穩(wěn)定版本。

在實踐中，這種方法將邊緣節(jié)點轉(zhuǎn)變?yōu)檫w移期間流量控制的唯一事實來源，而不是在每個前端內(nèi)部嵌入條件邏輯，邊緣函數(shù)可以在毫秒內(nèi)決定請求應(yīng)該發(fā)送到傳統(tǒng)的單體應(yīng)用還是特定的微前端。這也使得漸進式上線策略成為可能，例如金絲雀發(fā)布或藍綠部署，而且不需要修改前端代碼。

最有價值的其中一個優(yōu)勢是即時回滾，而不是讓臨時的路由侵入污染遺留代碼庫或新構(gòu)建的微前端。如果出現(xiàn)問題，你只需在邊緣節(jié)點切換路由規(guī)則，所有流量就會流回穩(wěn)定版本，不需要重新部署，不需要在應(yīng)用程序內(nèi)進行手動干預(yù)，也不需要維護混合新舊 UI 代碼的混合渲染層。系統(tǒng)之間的分離清晰、可逆，這對于長期運行的遷移至關(guān)重要。

集中式路由還減少了團隊的認(rèn)知負擔(dān)，提高了平臺的穩(wěn)定性。開發(fā)人員不再需要在多個存儲庫中維護一次性路由邏輯或是在系統(tǒng)之間同步 URL 模式。它還簡化了可觀察性，因為所有傳入請求都通過一個可以輸出一致指標(biāo)和日志的單一控制點。

身份驗證的處理通常比團隊的預(yù)期更簡單。只要所有微前端與遺留應(yīng)用共享相同的子域，它們就可以訪問相同的 cookie 和會話數(shù)據(jù)。

在兩個地方都實現(xiàn)更新后的令牌邏輯可以保持會話活躍，而且不需要復(fù)雜的跨應(yīng)用程序通信。

微前端的狀態(tài)管理應(yīng)始終在應(yīng)用程序本地，保持獨立性并避免跨團隊的耦合。當(dāng)多個微前端需要通信時，首選是使用松耦合事件在必要時廣播意圖和數(shù)據(jù)，而不是強制共享運行時依賴。這既強化了架構(gòu)邊界，又能在需要時實現(xiàn)合作。

有些配置（如身份驗證令牌、區(qū)域設(shè)置或功能標(biāo)志）可以利用穩(wěn)定的機制（如 cookie 或本地存儲）在系統(tǒng)之間共享，或者向每個微前端注入輕量級上下文。關(guān)鍵是保持這個共享層盡可能小并可預(yù)測。

明智地擁抱重復(fù)

在分布式系統(tǒng)中，重復(fù)不是偶然，而是刻意為之。我們的目標(biāo)并非消除所有重復(fù)，而是做出明智的決定，何處重復(fù)能幫助團隊加速推進，何處又會引入不必要的開銷。

好的啟發(fā)式方法位于復(fù)雜性和變化率的交叉點。例如，一個設(shè)計系統(tǒng)在其早期階段發(fā)展迅速，但隨著時間的推移趨于穩(wěn)定。系統(tǒng)成熟后，其發(fā)布周期就會減慢——畢竟沒有人會每天修改設(shè)計系統(tǒng)。同樣，跨多個微前端的共享日志庫具有低波動性和清晰的行為模式，因此集中化是有意義的。另一方面，考慮下流媒體平臺上復(fù)雜的視頻播放器。其啟發(fā)式方法可能會根據(jù)瀏覽器或設(shè)備來優(yōu)化緩沖、延遲或啟動時間。復(fù)雜性高，變化率高，因此重復(fù)只會增加維護的痛苦，而沒有實際的好處。

反之，如果你面對的是一個簡單的組件——比如說一個基本的字段表單或小型實用程序，它不經(jīng)常變化，并且實現(xiàn)起來也只需要花費很少的精力，那么放心復(fù)用就行。抽象化可以在模式得到驗證且一致性需求明確后再實施。

每個共享抽象都涉及治理、版本控制和所有權(quán)責(zé)任問題。將所有權(quán)留在負責(zé)微前端的團隊內(nèi)部可以簡化流程并保持自主權(quán)。最好的抽象是自然出現(xiàn)的，而不是提前強加的。有意識的重復(fù)幫你提高了速度和靈活性；深思熟慮的整合為你提供了長期一致性。兩者平衡即可實現(xiàn)分布式架構(gòu)的優(yōu)雅演進。

現(xiàn)代化改造的最快路徑

關(guān)于微前端最持久的其中一個誤解是：必須依賴微服務(wù)才能實現(xiàn)。事實并非如此。前端與后端的發(fā)展速度各不相同，而前端幾乎總是更快。

微前端專注于團隊如何構(gòu)建和交付界面，而不是如何提供數(shù)據(jù)。只要 API 合約保持不變，前端就可以獨立于后端進行現(xiàn)代化。你可以保留你的單體 API，并在它們之上引入模塊化前端。前端的無狀態(tài)特性使它們成為增量現(xiàn)代化的理想選擇。

后端遷移往往耗時漫長，因為數(shù)據(jù)有引力。模式更改、復(fù)制策略和遺留依賴都可能會將時間線拉長數(shù)月甚至數(shù)年。相比之下，前端遷移幾周內(nèi)就能提供看得見的價值。你可以現(xiàn)在就開始改進性能、可維護性和用戶體驗，而無需等待后端也完成了現(xiàn)代化改造。

在我提供咨詢的一家零售公司，將前端遷移到微前端大約用了 14 個月。后端現(xiàn)代化的時間是這個過程的兩倍，但在后端仍然是單體架構(gòu)的情況下，組織通過更快的發(fā)布和更好的用戶體驗很快就看到了價值。

前端可以引領(lǐng)潮流，作為分布式實踐的試驗場和更廣泛組織變革的催化劑。

以人類的速度進行現(xiàn)代化

現(xiàn)代化不是一次性事件，而是一段旅程。當(dāng)感覺遺留系統(tǒng)難以遷移時，重新開始的誘惑就會很大。但“大爆炸”方法很少成功。它會凍結(jié)業(yè)務(wù)進展，耗盡士氣，最終停步于從未投入生產(chǎn)的部分重寫。

微前端提供了一條不同的道路，一條與組織真正的演變方式一致的道路。它們讓你以人類的速度前進：足夠快可以體現(xiàn)進展，足夠慢可以確保安全。它們鼓勵實驗、持續(xù)學(xué)習(xí)和本地所有權(quán)。

每一次遷移都是在理想架構(gòu)和實際交付之間進行平衡。成功的團隊愿意接受這樣一個事實，就是不完美是這個過程的一部分。他們知道，好的架構(gòu)不在于純粹性，而在于流變。

如果有一個指導(dǎo)原則要記住，那就是：漸進勝過激進。迭代、學(xué)習(xí)和適應(yīng)。今天構(gòu)建的系統(tǒng)明天會變，這是特點，而不是缺陷。

對于探索這條道路的團隊而言，分布式前端時代的核心并非框架或打包工具，而是設(shè)計的系統(tǒng)與組織架構(gòu)能夠持續(xù)、安全且有目標(biāo)地演進。

小 結(jié)

微前端不僅是一種技術(shù)模式，更體現(xiàn)了現(xiàn)代組織構(gòu)建軟件的方式。它標(biāo)志著從集中控制到分布式所有權(quán)的轉(zhuǎn)變，從重大版本發(fā)布到持續(xù)交付的演進，從架構(gòu)僵化到漸進式變革的進化。

通過迭代遷移——小處著手，快速學(xué)習(xí)，以業(yè)務(wù)目標(biāo)為中心——你可以在不停止創(chuàng)新的情況下實現(xiàn)前端的現(xiàn)代化。后端是單體還是分布式并不重要。重要的是你安全演進并持續(xù)交付價值的能力。

在理想狀態(tài)下，架構(gòu)反映了人們的協(xié)作方式。當(dāng)團隊被賦予權(quán)力時，系統(tǒng)就會隨之成型。微前端只是這一真理在架構(gòu)層面的具體體現(xiàn)。

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。