> 作者：郭凌波
> [恆生LIGHT雲社群](https://developer.hs.net/thread/1020 "恆生LIGHT雲社群")

### 一、什麼是微前端？

“微前端”一詞最早於2016年底在《ThoughtWorks Technology Radar》中提出，它將微服務的概念擴充套件到前端世界，目的是構建一個在微服務架構上功能豐富且強大的前端應用。

大型組織的組織結構、軟體架構在不斷地發生變化。移動優先、App中臺、中臺戰略等，各種口號在不斷提出和演進。同時業務也在不斷地發展，而現有 Web
應用不能很好的擴充和部署，隨著時間的推移，各個專案變得越來越臃腫，web 應用變得越來越難以維護。

微前端將微服務的理念應用於瀏覽器端，讓Web應用由單體應用轉變為多個小型前端應用聚合為一的應用。各個前端應用還可以獨立執行、開發和部署。

### 二、實施微前端的六種方式：

#### 1 路由分發式

路由分發式微前端，即透過路由將不同的業務分發到不同獨立前端應用上。其通常可以透過反向代理（Nginx/HSIAR）來實現，配合使用應用框架自帶的路由管理。

就當前而言，透過路由分發式的微前端架構應該是採用最多、最易採用的 “微前端”方案。但是這種方式看上去更像是多個前端應用的聚合，即我們只是將這些不同的前端應用拼湊到一起，使他們看起來像是一個完整的整體。

系統整體結構如圖：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/v6lytx8mHzvvKHuwV8pe549mnG0balFVCIS77kVp_thumb.png "1320")

#### 2 iFrame前端容器化

iFrame 作為一個古老而普通的技術，但卻一直很管用。採用 `<iframe>`標籤將另一個Web頁嵌入到當前頁面中來，使得多web應用能在一個web中開啟。

其可以建立一個全新獨立的宿主環境，使不同的前端應用之間可以相互獨立執行，但會拋棄網站對SEO的支援、失去頁面之前互動的能力。

在很多業務場景下，難免會遇到一些難以解決的問題，那麼可以使用iframe 來作為保底的手段。

#### 3 前端微服務化

前端微服務化，是微服務架構在前端的實施。每個前端應用技術棧、開發、部署、構建都是完全獨立自主執行的，最後透過模組化的方式組合成一個完整的應用。

採用這種方式意味著，一個頁面上可以同時存在兩個以上的前端應用在執行。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/nu5bgSL0uUGhsOCu07Q6npMkv3FV4AGkY5AS8NLA_thumb.png "1321")

目前主流的框架有 [Single-SPA](https://single-spa.js.org/)、[qiankun](https://qiankun.umijs.org/)、[Mooa](https://github.com/phodal/mooa)，後兩者都是基於 Single-SPA 的封裝。

#### 4 微應用

微應用化是指在開發時應用都是以單一、微小應用的形式存在的，而在執行時，則是透過構建系統合併這些應用，並組合成一個新的應用。

微應用化大都是以軟體工程的方式來完成前端應用的聚合，因此又可以稱之為組合式整合。微應用化只能使用唯一的一種前端框架。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/5Joj0nnTKLKgE6p78WvC7yxiHeKM4ECrRJSGT8U7_thumb.png "1322")

#### 5 微件化

微件化（Widget）是一段可以直接嵌入應用上執行的程式碼，它由開發人員預先編譯好，在載入時不需要再做任何修改或編譯。微前端下的微件化是指，每個業務團第編寫自己的業務程式碼，並將編譯好的程式碼部署到指定的伺服器上，執行時只需要載入指定的程式碼即可。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/tnoXa92oJ2hNwGIrTpg0nSmjA58AeTtaq223sGq4_thumb.png "1323")

#### 6 Web Components

Web Components 是一套不同的技術，允許開發者建立可重用的定製元素（它們的功能封裝在程式碼之外）並且在您 Web 應用中使用它們。

在真正的專案上使用 Web Components 技術，離現在還有一些距離，結合 Web
Components 來構建前端應用，是一種面向未來演進的架構。或者說在未來可以採用這種方式來構建應用。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/dROduIyCmB79kBGKd27bAXjRznNvsANnbQ3NEcyv_thumb.png "1324")

微前端幾種方式對比

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/dWMJaFU6sTCYy8mWZ8XXUlrcsnzaV6R3waPdCmNx_thumb.png "1325")

### 三、真實的業務場景

在真實的業務場景中，往往是上面提到六種方式中的幾種的結合使用，或者是某種方式的變種

假設現有三個內部系統，下面稱之為 old-a、old-b 和 C，其中，old-a 和 old-b 是老舊的前後端未分離專案，C 為前後端分離的 SPA 應用（React+HUI），三個系統的架構圖大致如下：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/YRvT2sPGVKRoU0EVNohNAtdKxPhXcQPUBanJN37v_thumb.png "1326")

可以看到，old-a 執行在一臺伺服器 1 上，old-b
執行在伺服器 2 上，C 系統的前端資源在伺服器 2 上，並且 C 沒有自己的域名。

三個系統均在後端同學維護和開發，他們的需求如下：

1、統一的域名

2、統一的介面和互動

3、系統需要方便擴充

考慮開發同學的需求和開發成本、維護成本、未來的可擴充性，系統改造關鍵點如下：

1、申請統一的域名（暫且稱之為 crm.mi.com）

2、將 old-a 和old-b 兩個老舊的系統樣式調整，像系統 C 靠攏

3、三個系統使用統一的選單和許可權

4、三個系統使用統一的 SSO

5、C 系統和正在開發的N個系統使用CI/CD解決打包和手動複製的問題

對於上面幾種方式，在具體的實施使用了路由分發、iFrame、應用微服務化、微應用化的融合方式。或者說是某種方案的變種，因為改造之後同時具備了這幾種方案的特點。

對於 C 系統和正在開發的N個系統使用
single-spa 做改造，對於老舊的系統 old-a 和
old-b 使用iFrame接入。改造後如下圖：![1.png](https://developer.hs.net/storage/attachments/2021/06/04/RLH292r00wFxtnZLs8n4pqJr4hHQKieN7ku38L9S_thumb.png "1327")

此時，兩個老系統分別部署在各自的伺服器，C和未來的多個應用部署在同一臺伺服器。然後在 Nginx 層為老系統分配了兩個路由，分別將請求打到各自的伺服器，根路由打到C和XX應用的伺服器。

使用 React 框架的C和XX應用基於single-spa改造後，那麼老系統iFrame 如何接入？

在配置選單時，老系統路由會被帶上標識，統一交給其中一個應用以iFrame 的方式處理：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/mVrzMovbyGZDzt1j8uFff4FYmnfF5Sdp4LCTfZbo_thumb.png "1328")

改造後微前端架構圖：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/JTMWuTB9UMEt8wFPiZMg4r9xzWZM1nhZJXPJ8QPS_thumb.png "1329")

### 四、總結

微前端不是一個框架或者工具，而是一套架構體系。這套體系除了微前端的基礎設施外還需要具備微前端配置中心（版本管理、釋出策略、動態構建、中心化管理）、微前端觀察工具（應用狀態可見、可控）等。

整個體系的搭建將是一個龐大的工程，目前大部分團隊是在使用微前端的模式和思想來解決現有系統中的痛點。就像我們的HUI前端框架，經歷HUI1時的微應用模式到現在HUI2的微件化模式，結合恆生統一許可權管控體系操作員中心和恆生統一閘道器服務HSIAR，在我們統一運維監控平臺天鑑管理下形成了一套完整的微前端方案，減少了業務部門和客戶自研的開發工作。</iframe>

網頁上的微服務—微前端架構實踐

相關文章