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