字節(jié)跳動面試官:你是怎么理解微前端？
點擊上方“前端簡報”，選擇“設為星標”
第一時間關注技術干貨！
面對如此之多的神奇案例， 人們難以否認微前端正日益流行這個事實 。本文將探究微前端的具體使用場景和使用群體 ，并給出可快速輕松上手的現(xiàn)有解決方案。
微前端將大規(guī)模的后端系統(tǒng)切分為 很多面向前端的微服務，力圖實現(xiàn)一定程度的改進。
這里的主要問題是， 各個部分總是作為一個整體被使用和體驗的。
用戶體驗（UX）是由前端直接負責的，因為后端系統(tǒng)從來不會被直接整體訪問。
該問題存在多種解決方案。最簡單的做法是將現(xiàn)有 API 的數(shù)據(jù)交換模型替換為 HTML 輸出。只需一個超鏈接即可實現(xiàn)服務（視圖）間的跳轉。盡管這種解決方案 是 有效 的 ，但缺點是在很多情況下并不能提供用戶所需的 UX。
圖 1 分布式 Web 應用的演進
顯然，要將那些 各自 獨立的 較小 UI 部分聚合為一個整體的前端，需要的是一些更為復雜的解決方案。這應視為分布式 Web 應用演進的下一步。
一個重要的問題是，如何理解微前端與組件和模塊的關系。事實上，組件、模塊、微前端等概念，都是以 構建 單元的形式實現(xiàn)可重用性和所承擔 的 功能。它們之間的唯一差別是所處的層級不同，具體而言：
組件是底層 UI 庫的構建單元；
模塊是相應運行時的構建單元；
軟件包是依賴解析器的構建單元；
微前端是當前應用的構建單元。
如上，微前端可視為組成人體的各個器官，軟件包則對應于組成各器官的細胞，而模塊就是分子，組件對應于原子。
使用微前端的原因多種多樣， 常見的原因多是技術性的 ，但 往往 有 現(xiàn)實 的商業(yè)用例（或者提升 UX 的用例）在背后提供支持。
究其根本，微前端解決方案 可 提供如下特性：
單個前端部分可獨立開發(fā)、測試和部署；
無需重新構建即可添加、移除或替換單個前端部分；
不同的前端部分可使用不同的技術構建。
由此可見，微前端主要實現(xiàn)了解耦。在應用到達一定規(guī)模后，微前端就有了用武之地。其中一個潛在優(yōu)點是， 它 支持 組織分割為 更多團隊，乃至創(chuàng)建更小的全棧團隊。
圖 2 微前端對全棧團隊的支持。
微前端在如下場景中將更發(fā)揮更大作用：
多個團隊貢獻同一個前端。
一些 獨立的部分需由特定的用戶或團隊激活、終止激活或 roll out 。
需支持外部開發(fā)人員對 UI 進行擴展。
UI 的特性集每日 / 每周都在增長，并不會影響系統(tǒng)其它部分；
不論應用如何增長，都需要維持恒定的開發(fā)速度；
支持不同團隊使用不同的開發(fā)工具。
微前端得到越來越多企業(yè)的積極采納，下面給出部分最新列表：
各個企業(yè)所采用的方法當然各有千秋，但是大家的目標 是一致的 。
圖 3 使用微前端技術的企業(yè)（Luca Mezzalira 提供）
企業(yè)列表正不斷增長，從 ThoughtWorks、HLC 等咨詢公司，到 SalesPad、Apptio 等 SaaS 服務提供商。還有更多傳統(tǒng)企業(yè)已經(jīng)押注微前端，典型實例就是德國的隱形巨頭 Hoffmann 集團。
Hoffmann 集團很好地展示了微前端并不需要多么大型的團隊，也不需要占用多少內(nèi)部資源。該集團與多家服務提供商有業(yè)務往來，這是其選擇微前端的一個重要因素。
Bit.dev 平臺及其市場營銷網(wǎng)站均使用 React 組件構建，并且由 Bit 自身維護。
用戶在瀏覽 網(wǎng)站 查看其“原生服務”時，可停留在不同組件上。點擊位于組件上方的名字，即可查看組件詳情，進而安裝到用戶項目中。
構建該頁面的組件，基于 GitHub 上兩個不同的代碼庫，“ base-ui”（ 在 Bit 上的訪問位置）和“ evangelist”（ 在 Bit 上的訪問位置)。
base-ui 代碼庫 使用 Bit 發(fā)布，實現(xiàn)設計系統(tǒng)。evangelist 代碼庫 用于市場營銷頁面，其中使用了 base-ui 提供的一些組件，以在不同 MF 之間保持 統(tǒng)一的觀感。
在此， Bit 不僅用于自動交付特性，而且用來在不同微前端間維護一致的 UI。
這個 問題沒有確切答案。和微服務一樣，并不存在適用于所有人的單一方法，也沒有已確立的業(yè)界標準。
相比微服務實現(xiàn)，微前端不僅在實現(xiàn)細節(jié)上存在差異，而且在所有的細枝末節(jié)上均有所不同。因此需要區(qū)分主要使用場景。一些服務端框架也支持客戶端組裝，反之依然。
客戶端微前端的可選擇范圍很廣。其中部分支持服務端渲染。
圖 4 客戶端組裝
下列框架實現(xiàn)了這種（或類似的）模式：
Piral
Open Components
qiankun
Luigi
Frint.js
服務端框架有多種選項。但其中一些只是用于 express 的軟件庫或框架；還有一些以服務形式提供，需加載到用戶 的基礎 架構中。
圖 5 服務端組裝
下列框架實現(xiàn)這種（或類似的）模式：
Mosaic
PuzzleJs
Podium
Micromono
還可考慮一些幫助庫。這些幫助庫或是提供共享依賴、路由事件的基礎架構，或是將不同的微前端及其生命周期組織起來 。
下例通過 Import Maps 或打包特定 Chunk 實現(xiàn)對共享依賴的處理。
圖 6 使用 Import Maps 共享依賴。
下面的庫可用于削減模板代碼：
Module Federation
Siteless
Single SPA
Postal.js
EventBus
我想使用一些社區(qū)數(shù)據(jù)做深入分析，這需要讀者們的幫助。
我已使用 Google Forms 做了一個簡單的在線調查，只需占用不到五分鐘就能填完。歡迎讀者們通過各自渠道擴散鏈接。多謝！
https://forms.gle/Wxngf3KgTCf5TgcM6
調查截止八月，結果將在九月初公布。
雖然有些人覺得 Module Federation 之類的幫助庫很好用 ，但多數(shù)人還是會繼續(xù)用原來的解決方案 。好的一面是， 有很多不受大廠商控制的框架可以用來輕松編寫代碼 。但至少從技術上看，微前端依然缺少便于解決方案互通的通用標準。
另一個問題是，微前端的社區(qū)接受度和采用率仍顯不足。
盡管微前端模式已經(jīng)有一定知名度，但是社區(qū)中大多數(shù)人仍對其存疑。
究其原因，其一是微服務被視為一種后端設計的最佳實踐和標準， 但并未當作是一種新的，可用于特定場景的工具。顯然這并不是人們當初想的那樣，所以微前端也不應該被視為靈丹妙藥。
微前端 現(xiàn)有解決方案的可用數(shù)量及其在全球許多項目中的用途都發(fā)出了強烈的信號：微前端已經(jīng)隨時可以使用！我建議，在實際開始大型 / 生產(chǎn)級項目之前， 先考察各種模式和解決方案。
希望讀者喜歡這篇文章！我想了解大家的觀點及原因，對微前端持喜愛、可容忍態(tài)度，還是棄若敝屣？
https://blog.bitsrc.io/state-of-micro-frontends-9c0c604ed13a