三、如何實現(xiàn)微前端架構(gòu)

微前端不是一個庫，是一種前端架構(gòu)的設(shè)計思路，要實現(xiàn)微前端，本質(zhì)上就是在運行時遠程加載應(yīng)用。

實現(xiàn)微前端，有幾個思路，從構(gòu)建的角度來看有兩種，編譯時構(gòu)建微前端和運行時構(gòu)建微前端：

編譯時微前端，通常將第三方庫中的組件作為包，在構(gòu)建時引入依賴。這種實現(xiàn)引入新的微前端需要重新編譯，不夠靈活。編譯時的微前端可以通過Web Components，Monorepo等方式來實現(xiàn)。其中Monorepo非常流行，常見的工具有nx，rush，lerna等。

運行時微前端，是一次加載或通過延遲加載按需動態(tài)將微型前端注入到容器應(yīng)用程序中時。當引入新的微前端的時候，不需要構(gòu)建，可以動態(tài)在代碼中定義加載。我眼中的微前端更多是指這種運行時加載的微前端，因為獨立構(gòu)建，部署和測試是我們對于“微”的定義。

從前后端責任分層來看，可以從前端或者后端來實現(xiàn)。

通過客戶端框架來實現(xiàn)

微前端通常由客戶端工具來支持實現(xiàn)（聽上去好有道理），有許多支持客戶端開發(fā)微前端的實現(xiàn)工具，包括：Piral，Open Components，qiankun，Luigi，F(xiàn)rint．js等。其中qiankun是螞蟻金服開發(fā)的。

在客戶端還可以通過輔助庫的方式來實現(xiàn)，輔助庫可以為共享依賴項，路由事件或不同的微前端及其生命周期來提供一些基礎(chǔ)架構(gòu)。

下面的一個示例是通過諸如導(dǎo)入映射或打包特定塊等機制處理共享依賴關(guān)系。

相關(guān)的工具有Webpack5 Module Federation，Siteless，Single SPA，Postal．js等

通過服務(wù)器端實現(xiàn)

微前端并非只能在客戶端來實現(xiàn)，類似于服務(wù)端渲染，同樣可以通過服務(wù)端來實現(xiàn)。

服務(wù)端微前端的支持工具有：Mosaic，PuzzleJs，Podium，Micromono等。

好了，說了這么多我相信你是一臉懵逼的，到底怎么實現(xiàn)的？我們拋開架構(gòu)不說，來看看到底如何實現(xiàn)吧。

四、運行時微前端的具體實現(xiàn)方式

Iframe

iframes是可以在html中嵌入另一個HTML。下面就是用iframe實現(xiàn)微前端的一個例子：

＜！DOCTYPE html＞＜html＞＜body＞＜iframe src＝＂http：／／localhost：3006＂ width＝＂600＂ height＝＂900＂＞  ＜p＞Your browser does not support iframes．＜／p＞＜／iframe＞＜iframe src＝＂http：／／localhost：3007＂ width＝＂600＂ height＝＂900＂＞  ＜p＞Your browser does not support iframes．＜／p＞＜／iframe＞＜／body＞＜／html＞

如果不考慮體驗問題，iframe 幾乎是最完美的微前端解決方案了。iframe 提供了瀏覽器原生的隔離方案，不論是樣式隔離、js 隔離這類問題統(tǒng)統(tǒng)都能被完美解決。但它的最大問題也在于他的隔離性無法被突破，導(dǎo)致應(yīng)用間上下文無法被共享，隨之帶來的開發(fā)體驗、產(chǎn)品體驗的問題。這里的主要問題包括：

url 不同步。瀏覽器刷新 iframe url 狀態(tài)丟失、后退前進按鈕無法使用。

UI 不同步，DOM 結(jié)構(gòu)不共享。

全局上下文完全隔離，內(nèi)存變量不共享。

慢。每次子應(yīng)用進入都需要次瀏覽器上下文的重建、資源重新加載。

所以雖然使用iframe可以實現(xiàn)遠程加載的效果，但是因為這些限制，很少會有應(yīng)用會使用。

Nginx路由

利用Ngix路由，我們可以把不同的請求路由到不同的微前端的應(yīng)用。

例如Nginx的路由能力，在前端可以動態(tài)請求不同的后端應(yīng)用，而每一個后端應(yīng)用獨立運行，前端可以把這些不同的后端應(yīng)用加載，編排在一起。下面的代碼是一個Nginx的配置，customers／users／admins分別表示了三個不同的應(yīng)用，前端通過路由來加載位于不同服務(wù)的后端應(yīng)用。

worker＿processes 4；events ｛ worker＿connections 1024； ｝http ｛    server ｛        listen 80；        root  ／usr／share／nginx／html；        include ／etc／nginx／mime．types；        location ／app1 ｛            try＿files ＄uri app1／index．html；        ｝
       location ／app2 ｛            try＿files ＄uri app2／index．html；        ｝
       location ／app3 ｛            try＿files ＄uri app3／index．html；        ｝    ｝｝

無論你采用哪一種的微前端架構(gòu)，Nginx方向代理或者其它的API網(wǎng)關(guān)的解決方案都能夠提供方便靈活的后端路由功能。但是通過這種方式，需要定義一個通用可擴展的路由規(guī)則，否則當引入新的應(yīng)用的時候，還需要修改Nginx的路由配置，那就很不方便了。

Webpack 5 Module Federation

Webpack5 的Module Federation是一個令人興奮的革新，它能夠很方便的支持微前端的構(gòu)建。模塊聯(lián)合允許JavaScript應(yīng)用程序從另一個應(yīng)用程序動態(tài)加載代碼，并在此過程中能共享依賴關(guān)系。如果使用Module Federation的應(yīng)用程序不具有聯(lián)合代碼所需的依賴關(guān)系，則Webpack將從該聯(lián)合構(gòu)建源中下載缺少的依賴關(guān)系。

在Module Federation的上下文中，啟動代碼是一種將運行時代碼附加到遠程容器啟動序列的實施策略。這真的很有用，因為通過Hook無法訪問ModuleFederation及其運行時，無法對其進行擴展或添加一行代碼，這些代碼可以像動態(tài)設(shè)置遠程容器的公共路徑那樣進行操作。這在普通的webpack應(yīng)用程序中是微不足道的，但是在一個無法訪問的自定義運行時容器中卻很難做到，該容器為模塊聯(lián)合遠程編排提供了動力。簡單來說，Module Federation注入一段運行時的代碼來負責加載和編排遠程的應(yīng)用代碼，并能夠管理和加載遠程應(yīng)用的依賴。

下面是一個對應(yīng)的例子：

module．exports ＝ ｛    mode： ＇development＇，    devServer： ｛        port： 8080，    ｝，    plugins： ［        new ModuleFederationPlugin（｛            name： ＇container＇，            remotes： ｛                microFrontEnd1： ＇microFrontEnd1＠http：／／localhost：8081／remoteEntry．js＇，                microFrontEnd2： ＇microFrontEnd2＠http：／／localhost：8082／remoteEntry．js＇，            ｝，        ｝）    ］｝；

上面的代碼是微前端的容器端的配置，容器負責加載其它遠程應(yīng)用的代碼。這個例子里，它加載了兩個遠程應(yīng)用。

module．exports ＝ ｛    mode： ＇development＇，    devServer： ｛        port： 8081，    ｝，    plugins： ［        new ModuleFederationPlugin（｛            name： ＇microFrontEnd1＇，            filename： ＇remoteEntry．js＇，            exposes： ｛                ＇．／MicroFrontEnd1Index＇： ＇．／src／index＇，            ｝，        ｝），    ］｝；

每一個微前端的Webpack配置如上。

利用ModuleFederationPlugin，remote可以用來加載遠端的應(yīng)用，而Expose可以把自己的組件暴露為遠端組件。

在container中，只需要調(diào)用以下的代碼來加載遠端組件。

import ＇microFrontEnd1／MicroFrontEnd1Index＇；import ＇microFrontEnd2／MicroFrontEnd2Index＇；

Module Federation的加載過程如上圖所示：

localhost 加載index．html

main．js 是Module Federation的核心的編排代碼，負責加載遠程組件。

remoteEntry．js 是Module Federation暴露的遠程組件的代碼

src＿ 是打包后的代碼，其中 bootstrap＿js是容器側(cè)的代碼，index＿js是微前端側(cè)的代碼。

Module Federation實現(xiàn)了類似動態(tài)鏈接庫的能力，可以在運行時加載遠程代碼，遠程代碼本質(zhì)上是一個加載在window上的全局變量，Module Federation可以幫助解決依賴的問題。Javascrip作為上古語言，沒有提供依賴管理，導(dǎo)致留給各路大神各種發(fā)揮的空間。

Module Federation的缺點就是依賴Webpack 5，包直接掛載為全局變量。

EMP微前端是基于Module Federation的微前端解決方案。

Single SPA

單頁面應(yīng)用是當今為Web應(yīng)用的主流，區(qū)別于傳統(tǒng)的多頁面應(yīng)用，整個SPA只有一個頁面，其內(nèi)容都是通過Javascript的功能來加載。

SPA是一個Web應(yīng)用程序，僅包含一個HTML頁面。提供動態(tài)更新，它允許在不刷新頁面的情況下與頁面進行交互。利用單頁應(yīng)用程序，可以顯著降低服務(wù)器負載并提高加載速度，從而獲得更好的用戶體驗，因為SPA僅在先前加載整個頁面時才按需導(dǎo)入數(shù)據(jù)。

除了開發(fā)復(fù)雜，對于SEO不友好，但頁面應(yīng)用的最大技術(shù)缺陷是URL不適合共享，因為SPA只有一個地址。

single－spa是一個框架，用于將前端應(yīng)用程序中的多個JavaScript微前端組合在一起。

使用single－spa構(gòu)建前端可以帶來很多好處，例如：

在同一頁面上使用多個框架而無需刷新頁面（React，AngularJS，Angular，Embe）

獨立部署微前端

使用新框架編寫代碼，而無需重寫現(xiàn)有應(yīng)用程序

延遲加載代碼可縮短初始加載時間

single－spa應(yīng)用程序包含以下內(nèi)容：

single－spa根配置，用于呈現(xiàn)HTML頁面和注冊應(yīng)用程序的JavaScript。每個應(yīng)用程序都注冊了以下三項內(nèi)容：name，加載應(yīng)用程序代碼的函數(shù)，確定應(yīng)用程序何時處于活動狀態(tài)／非活動狀態(tài)的函數(shù)，

打包成模塊的單頁應(yīng)用程序的應(yīng)用程序。每個應(yīng)用程序必須知道如何從DOM引導(dǎo)，安裝和卸載自身。傳統(tǒng)SPA和Single－SPA應(yīng)用程序之間的主要區(qū)別在于，它們必須能夠與其他應(yīng)用程序共存，因為它們各自沒有自己的HTML頁面。例如，React或Angular SPA應(yīng)用程序。處于活動狀態(tài)時，他們可以偵聽url路由事件并將內(nèi)容放在DOM上。處于不活動狀態(tài)時，它們不偵聽url路由事件，并且已從DOM中完全刪除。

Single－SPA注冊的應(yīng)用程序擁有普通SPA所具有的所有功能，只是它沒有HTML頁面。SPA包含許多已注冊的應(yīng)用程序，每個應(yīng)用程序都有其自己的框架。已注冊的應(yīng)用程序具有其自己的客戶端路由和它們自己的框架／庫。它們呈現(xiàn)自己的HTML，并且在安裝時有完全的自由去做他們想做的任何事情。掛載的概念是指已注冊的應(yīng)用程序是否正在將內(nèi)容放在DOM上。決定是否掛載已注冊應(yīng)用程序的是其活動功能。每當未掛載已注冊的應(yīng)用程序時，它都應(yīng)保持完全休眠狀態(tài)直到掛載。

Single SPA的樣例代碼如下：

1． 微前端代碼：

import React from ＂react＂；import ReactDOM from ＂react－dom＂；import singleSpaReact from ＂single－spa－react＂；import Root from ＂．／root．component＂；const lifecycles ＝ singleSpaReact（｛  React，  ReactDOM，  rootComponent： Root，  errorBoundary（err， info， props） ｛    ／／ Customize the root error boundary for your microfrontend here．    return null；  ｝，｝）；export const ｛ bootstrap， mount， unmount ｝ ＝ lifecycles；

Single SPA的微前端是純的JS組件，不包含HTML，需要通過容器來加載。

2．容器的Root Config

在容器側(cè)，需要通過Import Map或者Webpack來定義遠程組件，并注冊遠程應(yīng)用。

｛  ＂imports＂： ｛    ＂＠naughty／root－config＂： ＂／／localhost：9000／naughty－root－config．js＂，    ＂＠naughty／app＂： ＂／／localhost：8500／naughty－app．js＂，    ＂react＂： ＂https：／／cdn．jsdelivr．net／npm／react＠16．13．1／umd／react．production．min．js＂，    ＂react－dom＂： ＂https：／／cdn．jsdelivr．net／npm／react－dom＠16．13．1／umd／react－dom．production．min．js＂  ｝｝

容器側(cè)的HTML文件使用import map來定義遠程依賴，其中root－config是編排代碼，負責遠程應(yīng)用的注冊和加載。同時需要定義所有共享的依賴，這里例子中是react和react－dom

import ｛ registerApplication， start ｝ from ＂single－spa＂；registerApplication（｛  name： ＂＠single－spa／welcome＂，  app： （） ＝＞    System．import（      ＂https：／／unpkg．com／single－spa－welcome／dist／single－spa－welcome．js＂    ），  activeWhen： ［＂／welcome＂］，｝）；registerApplication（  ＇＠naughty／app＇，  （） ＝＞ System．import（＇＠naughty／app＇），  location ＝＞ location．pathname．startsWith（＇／app＇））；start（｛  urlRerouteOnly： true，｝）；

在root－config中，我們注冊了兩個遠程應(yīng)用，使用不同的url來加載。／welcome會加載welcome應(yīng)用，而／app會加載我們的app應(yīng)用。

Single SPA的核心是利用不同的URL路由來加載遠程組件，它可以和Webpack（打包時構(gòu)建依賴）或者Import Map（運行時使用瀏覽器導(dǎo)入依賴）一起工作。注意，不要在你的微前端中混用兩種依賴機制。

Single SPA還提供一個layout 引擎，可以幫助你快速的構(gòu)建微前端。

相比Module Federation，Single SPA的代碼和生命周期的管理更清楚，提供清晰的接口，缺點是共享的依賴需要手工通過import map來管理。

要做一個好的微前端因為受限于瀏覽器和JS的一些特性，并不容易。除了我們今天分享的內(nèi)容，還面臨著諸多的挑戰(zhàn)：如何解決css／js的沖突，使得組件和應(yīng)用完全隔離；如何解決不同應(yīng)用間的通信；如何處理路由；如何保證UI風格的統(tǒng)一等等。

五、微前端的問題和缺點

講了這么多的優(yōu)點和實現(xiàn)，那么微前端是不是解決前端開發(fā)問題的銀彈呢？當然不是。所有的架構(gòu)都是取舍和權(quán)衡，這個世界上并不存在銀彈，微前端架構(gòu)和微服務(wù)一樣也存在他的弊端，單體架構(gòu)未必就差。

1． 微前端的構(gòu)建通常比較復(fù)雜，從工具，打包，到部署，微前端都是更為復(fù)雜的存在，天下沒有免費的午餐，對于小型項目，它的成本太高。

2． 每個團隊可以使用不同的框架，這個聽上去很美，但是實際操作起來，除了要支持歷史遺留的應(yīng)用，它的意義不大。同時也為帶來體驗上的問題。可以遠程加載不同的框架代碼是一回事，把它們都用好是另一回事。

3． 性能上來看，如果優(yōu)化得不好微前端的性能可能會存在問題，至少微前端框架是額外的一層加載。如果不同的微前端使用了不同的框架，那么每一個框架都需要額外的加載。

微前端架構(gòu)還在發(fā)展之中，本文提到的iframe／nginx／module federation／single－spa只是諸多解決方案中的一小部分，前端的發(fā)展變化和生態(tài)系統(tǒng)實在是豐富，其他的方案諸如umd／乾坤，Piral，open comonent等等。當使用你也可以選擇標準的Web Component或者ES Modules來構(gòu)建微前端，但是這些標準的瀏覽器支持不是特別好，這個是前端開發(fā)永遠的痛。（詛咒IE）
大家對于微前端有什么想法或者問題，歡迎一起討論。

關(guān)于作者：陶剛，Splunk資深軟件工程師，架構(gòu)師，畢業(yè)于北京郵電大學，現(xiàn)在在溫哥華負責Splunk機器學習云平臺的開發(fā)，曾經(jīng)就職于SAP，EMC，Lucent等企業(yè)，擁有豐富的企業(yè)應(yīng)用軟件開發(fā)經(jīng)驗，熟悉軟件開發(fā)的各種技術(shù)，平臺和開發(fā)過程，在商務(wù)智能，機器學習，數(shù)據(jù)可視化，數(shù)據(jù)采集，網(wǎng)絡(luò)管理等領(lǐng)域都有涉及。