微前端的現狀和趨勢
微前端是前端開發最具爭議的話題之一。值得嗎？真的需要切分應用嗎？真的需現在就轉向微前端嗎？這是不是又一個咨詢公司為了多賺錢發明出來的概念？
盡管人們對微前端多有誤解，我們不能否認微前端日益流行這一事實。讓我們看下誰在使用微前端，到底為什么用微前端，還有一些方便上手的現成解決方案。
微前端到底是什么
微前端試圖把拆分大型后端系統的一些益處引入前端。
最大的問題在于部分總是被整體使用。
后端系統從不被整體使用，而前端直接為用戶體驗（UX）負責。
應對這一問題有很多方式。最簡單的方式是把現有的 API 數據交換模型換成 HTML 輸出，只需一個超鏈接就可以從一個服務（視圖）轉到另一個服務（視圖）。缺點是在大多數使用場景下，這么做肯定無法滿足用戶體驗方面的需求。
顯然，我們需要更復雜的方法，將單獨開發的用戶界面小組件組合成一致的前端界面。這可以算是分布式 web 應用演進的下一步。
微前端和組件、模塊的關系是什么？這是一個好問題。這些概念都意味著通過拆分單元的方式讓代碼更易復用，更易歸責。唯一的差別是層次不同：
- 組件構成界面庫。
- 模塊構成相應的運行時。
- 包構成依賴關系。
- 微前端構成呈現的應用。
因此，如果把微前端比作器官，那么包就相當于細胞，模塊就相當于分子，組件就相當于原子。
為什么要用微前端
采用微前端的原因有許多種，經常主要是為了技術本身，不過，理想情況下，采用微前端是基于真實業務場景，或是出于改善用戶體驗的需要。
微前端方案的核心在于追求以下特性：
- 前端各部分可以單獨開發、測試、部署。
- 前端各部分的增加、移除、替換無需重新構建。
- 前端各部分可以采用不同的技術。
因此，微前端的精髓在于解藕。應用達到特定規模后，微前端開始變得有意義。其中一個好處是更多潛在的團隊劃分可能性，包括組建更小的全棧團隊。
在滿足以下一項或多項條件時，微前端值得考慮：
- 多個團隊貢獻前端代碼
- 面向特定用戶或用戶組激活、關閉、推出前端的某一部分
- 允許外部開發者擴展用戶界面
- 用戶界面每天或每周都會加入新特性，同時又不能影響系統的其他部分
- 在應用增長的情況下保持開發速度恒定
- 不同團隊能夠使用自己的工具
誰在用微前端
有越來越多的公司正在使用微前端，包括：
- DAZN
- Elsevier
- entando
- Fiverr
- Hello Fresh
- IKEA
- Bit.dev
- Microsoft
- Open Table
- OpenMRS
- Otto
- SAP
- Sixt
- Skyscanner
- smapiot
- Spotify
- Starbucks
- Thalia
- Zalando
- ZEISS
- …… 以及更多
這些公司使用微前端的具體方式各不相同，不過，使用微前端的意圖大同小異。
（上圖來自 Luca Mezzalira）
這個列表每天都在增長，從 ThoughtWorks、HLC 這樣的咨詢公司到 SalesPad、Apptio 這樣的 SaaS 提供商。但是很多傳統的公司也開始押注微前端。德國的隱形冠軍霍夫曼集團就是其中的一個例子。
霍夫曼集團是一個很好的例子，微前端不需要非常大的團隊，也不需要公司內部的資源?；舴蚵瘓F選擇微前端的原因正是因為它們要和多個服務提供商打交道。
微前端組件的例子
[Bit.dev] 平臺和營銷網站都是基于 React 組件構建，管理 React 組件是通過……Bit。
看看它們的頁面。懸停在不同組件上會顯示這些組件原本屬于哪個組件集。點擊組件名可以查看組件，甚至在你的項目中加入這一組件。
這個頁面是通過兩個組件集中的組件構建的，這兩個組件集對應 GitHub 上兩個不同的代碼倉庫，[base-ui] (Bit.dev 頁面) 和 evangelist。
base-ui 組件集起到了設計系統的作用。evangelist 組件集中的組件（用于營銷頁面）使用了 base-ui 中的一些組件，以便在不同的微前端上保持統一的風格。
在這個例子中，Bit 既用于實現自主交付，也用于保持不同微前端的界面一致。
如何構建微前端
很不幸，這個有趣的問題只有一個含混的答案：就像微服務一樣，并不存在適用于所有人的單一方法，也沒有業界標準。
不同于微服務，微前端引入了基本性的差異，而不僅僅是實現細節上的差異。所以，我們需要區分微前端的使用范圍。一些服務端框架也允許客戶端復合（client-side composition），不過，相反的情況也是成立的。
客戶端框架
客戶端微前端框架有很多，有些也同時支持服務端渲染。
以下框架實現了微前端模式（或類似微前端的模式）：
服務端框架
服務端微前端框架也不少。有些不過是基于 express 的庫或框架，但另一些框架則需要依托于你的基礎設施。
以下框架實現了微前端模式（或類似微前端的模式）：
輔助庫
還有一些輔助庫提供了一些基礎設施，例如共用依賴、路由事件、組合不同的微前端及其生命周期。
下面是一個[處理共用依賴]的例子，利用了 import maps、chunk （webpack 內部使用的一個概念） 之類的機制。
下面這些庫有助于減少模板代碼：
微前端調研
我希望以后基于社區數據重新梳理一下這部分的內容。但我需要你們幫忙提供數據。
我用 谷歌表單做了一份簡單的調查表，應該能在 5 分鐘之內填完。請幫忙擴散（比如通過 Twitter）。非常感謝！
調查到八月底截止，九月初會發表結果。
微前端的下一步
盡管有些人覺得微前端會集體轉向模塊聚合（module federation）之類的輔助庫，大多數人仍將使用自研解決方案。好消息是在許多框架下很容易編寫避開強供應商鎖定的代碼。不管怎么說，微前端缺少一個公共標準，方便在技術層面交換解決方案。
另外，目前微前端仍未被社區廣泛接受和采用。
盡管微前端模式變得流行，社區中仍有很多人心存疑慮。
有一個原因是微服務并沒有被視為面向特定場景的另一個工具，而是被視為設計后端時的一種最佳實踐和標準。顯然微服務不應該這么用。因此，微前端也不應該被視為銀彈。
結語
微前端有許多現成的解決方案，許多項目也已經采用微前端，這是一個強烈的信號：微前端已就緒！我建議在開始一個具有一定規模的生產環境項目前，先調研下各種模式和方案。
我希望你喜歡這篇文章！我希望知道你持哪一方的觀點及其原因。你喜歡微前端，可以容忍微前端，還是討厭微前端？
