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

做者:郭凌波 恆生LIGHT雲社區前端

1、什麼是微前端?

「微前端」一詞最先於2016年末在《ThoughtWorks Technology Radar》中提出,它將微服務的概念擴展到前端世界,目的是構建一個在微服務架構上功能豐富且強大的前端應用。git

大型組織的組織結構、軟件架構在不斷地發生變化。移動優先、App中臺、中臺戰略等,各類口號在不斷提出和演進。同時業務也在不斷地發展,而現有 Web 應用不能很好的拓展和部署,隨着時間的推移,各個項目變得愈來愈臃腫,web 應用變得愈來愈難以維護。github

微前端將微服務的理念應用於瀏覽器端,讓Web應用由單體應用轉變爲多個小型前端應用聚合爲一的應用。各個前端應用還能夠獨立運行、開發和部署。web

2、實施微前端的六種方式:

1 路由分發式

路由分發式微前端,即經過路由將不一樣的業務分發到不一樣獨立前端應用上。其一般能夠經過反向代理(Nginx/HSIAR)來實現,配合使用應用框架自帶的路由管理。後端

就當前而言,經過路由分發式的微前端架構應該是採用最多、最易採用的 「微前端」方案。可是這種方式看上去更像是多個前端應用的聚合,即咱們只是將這些不一樣的前端應用拼湊到一塊兒,使他們看起來像是一個完整的總體。瀏覽器

系統總體結構如圖:前端框架

1.png

2 iFrame前端容器化

iFrame 做爲一個古老而普通的技術,但卻一直很管用。採用 <iframe>標籤將另外一個Web頁嵌入到當前頁面中來,使得多web應用能在一個web中打開。服務器

其能夠建立一個全新獨立的宿主環境,使不一樣的前端應用之間能夠相互獨立運行,但會拋棄網站對SEO的支持、失去頁面以前交互的能力。架構

在不少業務場景下,不免會遇到一些難以解決的問題,那麼可使用iframe 來做爲保底的手段。框架

3 前端微服務化

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

採用這種方式意味着,一個頁面上能夠同時存在兩個以上的前端應用在運行。

1.png

目前主流的框架有 Single-SPAqiankunMooa,後二者都是基於 Single-SPA 的封裝。

4 微應用

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

微應用化大都是以軟件工程的方式來完成前端應用的聚合,所以又能夠稱之爲組合式集成。微應用化只能使用惟一的一種前端框架。

1.png

5 微件化

微件化(Widget)是一段能夠直接嵌入應用上運行的代碼,它由開發人員預先編譯好,在加載時不須要再作任何修改或編譯。微前端下的微件化是指,每一個業務團第編寫本身的業務代碼,並將編譯好的代碼部署到指定的服務器上,運行時只須要加載指定的代碼便可。

1.png

6 Web Components

Web Components 是一套不一樣的技術,容許開發者建立可重用的定製元素(它們的功能封裝在代碼以外)而且在您 Web 應用中使用它們。

在真正的項目上使用 Web Components 技術,離如今還有一些距離,結合 Web Components 來構建前端應用,是一種面向將來演進的架構。或者說在將來能夠採用這種方式來構建應用。

1.png

微前端幾種方式對比

1.png

3、真實的業務場景

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

假設現有三個內部系統,下面稱之爲 old-a、old-b 和 C,其中,old-a 和 old-b 是老舊的先後端未分離項目,C 爲先後端分離的 SPA 應用(React+HUI),三個系統的架構圖大體以下:

1.png

能夠看到,old-a 運行在一臺服務器 1 上,old-b 運行在服務器 2 上,C 系統的前端資源在服務器 2 上,而且 C 沒有本身的域名。

三個系統均在後端同窗維護和開發,他們的需求以下:

一、統一的域名

二、統一的界面和交互

三、系統須要方便拓展

考慮開發同窗的需求和開發成本、維護成本、將來的可拓展性,系統改造關鍵點以下:

一、申請統一的域名(暫且稱之爲 crm.mi.com)

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

三、三個系統使用統一的菜單和權限

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

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

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

對於 C 系統和正在開發的N個系統使用 single-spa 作改造,對於老舊的系統 old-a 和 old-b 使用iFrame接入。改造後以下圖:1.png

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

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

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

1.png

改造後微前端架構圖:

1.png

4、總結

微前端不是一個框架或者工具,而是一套架構體系。這套體系除了微前端的基礎設施外還須要具有微前端配置中心(版本管理、發佈策略、動態構建、中心化管理)、微前端觀察工具(應用狀態可見、可控)等。

整個體系的搭建將是一個龐大的工程,目前大部分團隊是在使用微前端的模式和思想來解決現有系統中的痛點。就像咱們的HUI前端框架,經歷HUI1時的微應用模式到如今HUI2的微件化模式,結合恆生統一權限管控體系操做員中心和恆生統一網關服務HSIAR,在咱們統一運維監控平臺天鑑管理下造成了一套完整的微前端方案,減小了業務部門和客戶自研的開發工做。