微前端：邁向現(xiàn)代化前端架構的社會技術之旅

作者 | Luca Mezzalira

譯者 | 平川

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

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

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

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

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

重新思考微前端

這篇文章側重于架構原則，而不是任何特定的框架或供應商解決方案。

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

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

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

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

微前端的適用場景

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

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

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

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

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

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

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

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

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

從大爆炸到增量修改

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

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

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

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

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

規(guī)劃遷移

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

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

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

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

采用模塊化設計

當開始一個綠地項目時，微前端應該與業(yè)務領域對齊，而不是技術層。不要按框架或功能類型組織代碼，而是設計獨立的產品能力，這些能力對應真實的用戶需求——目錄、結算、個人資料、分析。

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

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

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

處理橫切關注點

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

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

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

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

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

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

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

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

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

明智地擁抱重復

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小 結

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

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

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

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

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