一文讓你了解微前端的現狀 react什么意思 _生活經驗

在前端 Web 開發中，微前端（microfrontends）是一個備受爭議的話題。它是否值得開發者采用？面對如此之多的神奇案例，人們無法否認微前端正日益流行這個事實。本文將探究微前端的具體使用場景和使用群體，并給出能快速輕松上手的現有解決方案。
什么是微前端？微前端將大規模的后端系統切分為很多面向前端的微服務，力圖實現一定程度的改進。
這里的主要問題是，各個部分總是作為一個整體被使用和體驗的。
用戶體驗（UX）是由前端直接負責的，因為后端系統從來不會被直接整體訪問。
該問題存在多種解決方案。最簡單的做法是將現有 API 的數據交換模型替換為 HTML 輸出。只需一個超鏈接即可實現服務（視圖）間的跳轉。盡管這種解決方案是有效的，但缺點是在很多情況下并不能提供用戶所需的 UX 。

文章插圖
分布式 Web 應用的演進
顯然，要將那些各自獨立的較小 UI 部分聚合為一個整體的前端，需要的是一些更為復雜的解決方案。這應視為分布式 Web 應用演進的下一步。
一個重要的問題是，如何理解微前端與組件和模塊的關系。事實上，組件、模塊、微前端等概念，都是以構建單元的形式實現可重用性和所承擔的功能。它們之間的唯一差別是所處的層級不同，具體而言：

組件是底層 UI 庫的構建單元；
模塊是相應運行時的構建單元；
軟件包是依賴解析器的構建單元；
微前端是當前應用的構建單元。

如上，微前端可視為組成人體的各個器官，軟件包則對應于組成各器官的細胞，而模塊就是分子，組件對應于原子。
為什么要使用微前端？使用微前端的原因多種多樣，常見的原因多是技術性的，但往往有現實的商業用例（或者提升 UX 的用例）在背后提供支持。
究其根本，微前端解決方案可提供如下特性：

單個前端部分可獨立開發、測試和部署；
無需重新構建即可添加、移除或替換單個前端部分；
不同的前端部分可使用不同的技術構建。

由此可見，微前端主要實現了解耦。在應用到達一定規模后，微前端就有了用武之地。其中一個潛在優點是，它支持組織分割為更多團隊，乃至創建更小的全棧團隊。

文章插圖
微前端對全棧團隊的支持
微前端在如下場景中將更發揮更大作用：

多個團隊貢獻同一個前端
一些獨立的部分需由特定的用戶或團隊激活、終止激活或 roll out
需支持外部開發人員對 UI 進行擴展
UI 的特性集每日 / 每周都在增長，并不會影響系統其它部分
不論應用如何增長，都需要維持恒定的開發速度
支持不同團隊使用不同的開發工具

微前端的使用者目前，微前端得到越來越多企業的積極采納，下面給出部分最新列表：

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 服務提供商。還有更多傳統企業已經押注微前端，典型實例就是德國的隱形巨頭 Hoffmann 集團。
Hoffmann 集團很好地展示了微前端并不需要多么大型的團隊，也不需要占用多少內部資源。該集團與多家服務提供商有業務往來，這是其選擇微前端的一個重要因素。
實例：微前端及所使用的組件Bit.dev 平臺及其市場營銷網站均使用 React 組件構建，并且由 Bit 自身維護。
用戶在瀏覽網站查看其“原生服務”時，可停留在不同組件上。點擊位于組件上方的名字，即可查看組件詳情，進而安裝到用戶項目中。

文章插圖
構建該頁面的組件，基于GitHub 上兩個不同的代碼庫，“ base-ui ”（在Bit 上的訪問位置）和“ evangelist ”（在Bit 上的訪問位置) 。

文章插圖
base-ui 代碼庫使用 Bit 發布，實現設計系統。evangelist 代碼庫用于市場營銷頁面，其中使用了 base-ui 提供的一些組件，以在不同 MF 之間保持統一的觀感。
在此， Bit 不僅用于自動交付特性，而且用來在不同微前端間維護一致的 UI 。
如何構建微前端？這個問題沒有確切答案。和微服務一樣，并不存在適用于所有人的單一方法，也沒有已確立的業界標準。
相比微服務實現，微前端不僅在實現細節上存在差異，而且在所有的細枝末節上均有所不同。因此需要區分主要使用場景。一些服務端框架也支持客戶端組裝，反之依然。
客戶端框架客戶端微前端的可選擇范圍很廣。其中部分支持服務端渲染。

文章插圖
客戶端構成
下列框架實現了這種（或類似的）模式：

Piral
Open Components
qiankun
Luigi
Frint.js

服務端框架服務端框架有多種選項。但其中一些只是用于 express 的軟件庫或框架；還有一些以服務形式提供，需加載到用戶的基礎架構中。

文章插圖
服務端構成
下列框架實現這種（或類似的）模式：

Mosaic
PuzzleJs
Podium
Micromono

Helper 庫還可考慮一些幫助（helper）庫。這些幫助庫或是提供共享依賴、路由事件的基礎架構，或是將不同的微前端及其生命周期組織起來。
下例通過 Import Maps 或打包特定 Chunk 實現對共享依賴的處理。

文章插圖
使用 Import Maps 共享依賴。
下面的庫可用于削減模板代碼：

Module Federation
Siteless
Single SPA
Postal.js
EventBus

微服務的下一步發展雖然有些人覺得 Module Federation 之類的幫助庫很好用，但多數人還是會繼續用原來的解決方案。好的一面是，有很多不受大廠商控制的框架可以用來輕松編寫代碼。但至少從技術上看，微前端依然缺少便于解決方案互通的通用標準。
另一個問題是，微前端的社區接受度和采用率仍顯不足。
盡管微前端模式已經有一定知名度，但是社區中大多數人仍對其存疑。
究其原因，其一是微服務被視為一種后端設計的最佳實踐和標準，但并未當作是一種新的，可用于特定場景的工具。顯然這并不是人們當初想的那樣，所以微前端也不應該被視為靈丹妙藥。
小結微前端現有解決方案的可用數量及其在全球許多項目中的用途都發出了強烈的信號：微前端已經隨時可以使用！我建議，在實際開始大型 / 生產級項目之前，先考察各種模式和解決方案。
【一文讓你了解微前端的現狀 react什么意思】我想了解大家的觀點及原因，對微前端持喜愛、可容忍態度，還是棄若敝屣？