本文最初發布於博客 Better Programming。
從 2021 年年底到 2022 年最初的幾周里，我花了一些時間來研究微前端到目前為止的發展情況。
我分析了讓團隊陷入掙扎的不同挑戰，長期以來導致耦合的反模式，以及用於解決這些問題常用的模式。
我們發現，微前端使團隊能夠獨立工作，為中大型應用程序做出貢獻，迭代演進我們的應用程序，減少潛在問題的影響範圍。
然而，分析不能停留在我們到目前為止所取得的成就上。我們要向前看，向未來邁進。
我必須了解下，這個迷人的拼圖中缺少了哪一部分，並設想下，怎麼做才會使這個架構方法變得更好。
在這篇文章中，我將分享一些想法和趨勢，它們可能會在微前端社區引發一些有趣的討論。
本文所涉及的話題考慮了這種架構的客戶端、服務端和邊緣端實現。
最後，我會分享下 2022 年我將關注微前端生態系統的哪些方面。
微前端架構的主要挑戰之一是回答這樣一個問題：微前端有多 "微"？
許多組織都面臨這個問題。在現實中，答案不只一個，我們需要了解背景、組織結構及其規模，以及團隊之間的溝通渠道。
在與數個從事分布式架構工作的團隊的幾次接觸中，我發現，「分布式組件」的實現比微前端多得多。通過分布式組件，領域知識在容器和「微前端」之間，甚至是容器和多個「微前端」之間共享。
我們仍在努力尋找正確的邊界，有時，我們在實施微前端時卻不知道如何解釋微前端。我認為，理解微前端是邁向更高成熟度的必要步驟，掌握應用業務子域並不是一件容易的事，需要我們對正在構建的應用有深入的了解。
不過，我認為有一個可能的解決方案可以緩解這一挑戰。
前期藉助白板花更多的時間進行討論，在不影響用戶體驗的情況下，和組織的多個部分一起修改業務領域劃分。這是必須的。
當我們從這些會議中走出來的時候，應該有足夠的信心來啟動這個項目，並定期審查我們的決定，以確保最初的假設對於目標的實現仍然有效。
請記住，我們不可能在前期考慮到所有方面，現在的企業和組織很可能在 6 或 12 個月後發生變化，所以我們應該定期地重新審視我們劃定的微前端邊界。
另外，永遠不要忘記組織結構和軟件架構之間的聯繫，意識到這一點並在設計決策中考慮這一點非常重要。
當同一個視圖中有多個微前端時，它們有時候需要相互通信。在我為設計微前端而創建的心理模型中，我建議微前端之間使用發布 - 訂閱模式進行通信，嚴格執行微前端之間的邊界，避免或至少減少設計時耦合，讓團隊有更大的自主性。
在技術上，實現這種模式有幾種選擇，如自定義事件、事件發射器庫甚或反應流。
在過去的幾個月里，出現了一個重要需求，我一開始並沒怎麼強調，可能是因為我把它當成了理所當然，但現在看，這絕對是需要注意的事情。
就像後端的事件驅動架構一樣，一個清晰的事件模式有助於避免在集成階段犯錯。此外，模式還能幫助那些不直接從事代碼庫工作的技術人員，清楚地了解特定應用程序內部發生了什麼。
我在我關注的眾多 Slack 頻道中發現了這個事件總線庫，毫無疑問，它非常有助於在鬆耦合的元素（微前端，但不限於此）之間實現更結構化的通信：https://www.npmjs.com/package/@trutoo/event-bus。
用於微前端通信的 @trutoo/event-bus考慮到微前端是一個分布式架構，需要有一個更規範的 API 或事件管理。API 或事件也是團隊交互的方式，而不僅僅是微前端交互的方式。
我們必須明白，這些做法不僅可以幫助開發者在發送事件時避免錯誤，還可以促進團隊之間的討論，明確意圖。
我希望，將來，當我們有大量使用鬆耦合通信策略的大型應用時，會投入更多的精力來簡化開發體驗。
如果每次我們新開發微前端之間的交互時，都有一個事件註冊表可以查詢，那該有多好？
最後，如果你沒看過 PayPal 在微前端通信方面所做的工作，我強烈建議你觀看這段精彩的視頻。
在過去幾個月中，服務端渲染架構是創新比較多的領域，想想 Next.js 或者 React 18 背後的團隊對服務器組件的投入。
微前端也有一些有趣的解決方案，比如 Next.js 模塊聯盟、Piral、TailorX、ILC 等等。
對於 SSR 微前端應用，有不少我們應該開始進行更深入研究的話題。
以下是我認為到目前為止這個領域中存在的一些空白：
微前端發現：就像微服務的服務發現模式，但應用於前端。使用這種模式，我們可以動態組合微前端，而不需要對系統中的端點進行任何靜態引用。想象一下，一個微前端基礎設施會自動把自己註冊到一個發現服務中，而 UI 設計器會從發現服務中檢索微前端，而不是直接與微前端進行點對點的聯繫。
雲端參考架構：在如何使用流行的雲供應商構建 SSR 微前端架構方面缺乏指導。這是一個相對來說可以快速解決的問題，我願意儘可能地提供幫助。
在微前端中利用無服務器範式：我相信，無服務器可以提供很好的開發速度，將基礎設施的管理委託給雲供應商。同時，我們必須轉變思路，了解特定的工作負載（如微前端）應該利用哪些服務。例如，我認為，使用 AWS Step Functions 這樣的服務來簡化微前端的創建是有價值的，因為它很好地實現了與整個 AWS 生態系統的集成。這使我們能夠採用低代碼模式，從長遠來看，可以簡化維護工作。這是我們可以在雲上使用的許多模式中的一種，但用微前端探索這些模式非常引人入勝（至少對我來說是如此）。
一種框架無關的 React 服務器組件方法：當後端數據發生變化時，有一種機制可以使用 SSR 原子化地重新加載視圖的一部分，並與客戶端的微前端無縫集成。這樣可以提供混合了 CSR 和 SSR 的混合架構，針對每個微前端使用正確的方法。也許我們今天就可以創建這樣的機制，但像 React 18 那樣有一個優美的實現將是最終的目標。
如你所見，有很多機會擺在我們面前，有些比較具體，比如參考架構，有些是比較長期的，比如框架無關的 React 服務器組件方法。
在這個列表中，我將重點關注參考架構以及研究在微前端使用無服務器範式。我已經開始研究參考架構的原型，在無服務器方面我也有一些有趣的原型。敬請關注。
性能對每個前端應用程序來說都很關鍵，包括微前端。
我已經有一段時間沒有聽說過「島嶼架構」的概念了。不過我認為，最終，鑑於其原則和特點，這種架構可能屬於微前端範疇。
島嶼架構所引入了有趣的技術，有可能利用局部水合來提高服務器端渲染應用程序的性能。
部分水合併不是一項新技術，從 2019 年開始就有了（如果我沒記錯的話），但我沒有看到任何微前端應用涉及這項技術。考慮到微前端的性質和部分水合的機制，我認為這種技術應該獲得更多的青睞，從而進一步優化我們的 SSR 微前端應用。
在這條推文中，Addy Osmani 提供了一些有用的資源，可以幫助你更好地理解這個概念。
最後，如果你對這個話題感興趣，那麼建議你閱讀下這篇文章，其中有一個 UI 框架清單，它們可能使用了部分水合。
目前，我正使用 Preact 進行一個微前端概念驗證實驗，希望能把我的收穫儘快和大家分享。
在討論邊緣的微前端時，我們經常會想到 Edge-Side Includes（ESI）標記語言。我這裡指的是許多 CDN 正在提供的計算能力，如邊緣的 AWS Lambda 或 Cloudflare workers。
邊緣技術正在快速發展，因此部分應用可以移到邊緣，改善解決方案的延遲和可擴展性。不過，在許多 Web 應用中，我們不能只考慮使用多個微前端生成一個 HTML 頁面的計算工作量，還需要考慮整個應用的複雜性。
通常，計算是如今「最容易」解決的問題，當涉及到數據重力（數據庫、多區域數據複製、全球性基礎設施的寫與讀、數據複製延遲......）或身份驗證時（通常集中在雲基礎設施的一個特定區域甚或內部的一個數據中心，而且安全性很高）就不那麼容易了。
的確，SSR 微前端應用可以從邊緣計算中獲益，但它們需要訪問眾多其他資源（數據、身份驗證、緩存......），而這些資源在邊緣並非完全可用。
除非我們有一個封裝得非常好的工作負載，不需要其中的任何外部依賴，否則我們還無法真正把邊緣的能力全部利用起來。
我相信，未來我們會更多地採用邊緣技術，但同時，我認為我們必須更好地理解邊緣技術在哪些方面可以對我們的工作負載產生真正的影響，而不僅僅是因為使用邊緣節點看起來「很酷」（炒作驅動開發）。
在我看來，在不久的將來，邊緣計算將與微前端產生密切的聯繫，特別是對於提高應用程序的性能來說，但它並不像現在看起來那麼簡單。
在微服務中，有一套統一的做法來降低微服務新版本的部署風險，如特性標識、藍綠部署和金絲雀發布。
在過去的 12 個月中，我在微前端領域沒有看到類似的工作，特性標識除外，這看起來是許多團隊都熟知的一個模式。
我認為，必須有一種部署策略可以讓開發團隊建立信心。
在分布式系統中，持續部署通常是常態，我們必須為開發人員提供安全保障，使他們能夠通過迭代的方式，快速將代碼從筆記本電腦發布到生產環境中，而降低一次性部署讓所有用戶都受 Bug 影響的風險。
對於 SSR 微前端，我們很容易重用現有的工具和實踐，利用這些機制的一種來發布我們的基礎設施，儘管這些策略通常不被客戶端渲染的微前端應用程序所接受。
我們可以通過多種方式實現它們：客戶端、服務端甚至是邊緣端。
我的建議是儘快實施這些策略中的一種，因為它們可以為你的團隊創造一個更安全的環境，結果可能會讓你驚訝……積極的方面。
和部署策略密切相關，客戶端渲染的微前端應用程序缺乏可靠的路由策略。所有實現都使用了我們用於實現單體架構的路由庫。與此相反，我認為我們可以做得更好！
當我們將路由庫與前面介紹的部署策略混在一起時，就可以有一個非常智能的路由，它可以照顧到較新的微前端版本、不同的環境，甚至不同的用戶角色。
我們也可以有一些工具，逐漸增加某個版本的流量，並且可以用同樣的方式執行回滾。
例如，當我們在 AWS 中開發容器或無服務器工作負載時，可以通過幾行配置輕鬆創建我們喜歡的部署策略。
使用 AWS SAM 實現一個 AWS Lambda Function 的金絲雀發布應用程序前端的路由可以通過提供了不同可能性的外部 JSON 輕鬆編排，而不需要將這些信息集成到應用程序邏輯中。
最後，當這個靜態 JSON 與部署邏輯相結合時，我相信它們可以帶來很多價值，降低新版本的風險，並允許基於業務想要實現的任何邏輯進行動態配置。
路由和部署絕對是我最感興趣的領域。在接下來的幾個月里，我將花些時間來消除那些無差別的繁瑣工作，讓團隊更好地控制他們的部署和路由。我希望可以儘快分享我正在做的工作，因為工作組對這兩個主題非常感興趣。
這個領域我還沒有研究，但是我有一個工具列表，可以用來理解微前端的利弊。我主要關注的是單庫，因為我認為，如果使用庫，就不需要額外的工具來管理代碼，就像在同一個庫中有多個獨立的項目那樣。
目前，以下工具引起了我的注意：
Turborepo
PNPM
Projen
我相信，它們都有一些特性，可以幫助我們構建一個單庫策略，改善開發體驗。
這是我今年的一個延伸目標，我不確定自己是否能夠投入足夠的時間來考察每個工具，但我肯定會關注這個領域，因為我相信還有更多未探索的領域可以進一步改善開發體驗。
任何關於工具的建議都非常受歡迎，如果可以在分享經驗時提供簡單的評論就更好了。
如你所見，在微前端生態系統中仍然有很多領域需要探索，我們在過去幾年裡已經取得了很大的進步。
對我來說，這是一個非常令人興奮的機會，可以影響一個正在全球企業組織中提高成功率的「年輕」架構多方面的改進。
我相信，還有更多的東西需要去探索和發現，我希望這種快速的採用可以幫助我們了解，什麼在分布式 UI 架構中可行，什麼不可行。
我的雷達上還有其他主題，如 WebAssembly、增強客戶端安全性、進一步簡化開發體驗等等，但這篇文章中列出的主題應該已經可以為所有社區提供思考的素材，以便在未來幾個月內改進這種新的方式，進而擴展我們的應用程序和組織。
查看英文原文：
https://betterprogramming.pub/the-future-of-micro-frontends-2f527f97d506?
留言列表