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