微前端是將Web應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的一種手段。本文從微前端的基礎(chǔ)理論出發(fā)，與大家分享長(zhǎng)亮科技Web 前端團(tuán)隊(duì)的探索與實(shí)踐經(jīng)驗(yàn)。
作者
Yang.Q 前端架構(gòu)師
擁有10年前端開(kāi)發(fā)和從業(yè)經(jīng)驗(yàn)，負(fù)責(zé)前端生態(tài)建設(shè)以及低代碼、微前端等前端前沿技術(shù)的探索工作。
數(shù)字時(shí)代，隨著技術(shù)的不斷變革，前后端分離架構(gòu)的研發(fā)模式已成為主流。但爆發(fā)式增長(zhǎng)的業(yè)務(wù)量讓前端功能需求不斷增多，小而美的應(yīng)用不復(fù)存在。當(dāng)一個(gè)普通應(yīng)用演變成一個(gè)巨石應(yīng)用( Frontend Monolith )后，邏輯復(fù)雜和臃腫的問(wèn)題開(kāi)始暴露，隨之而來(lái)的是多人難以協(xié)作、功能耦合性高、頁(yè)面加載速度變慢等一系列難題亟待解決。
當(dāng)后端「微服務(wù)」廣泛普及時(shí)，「微」的概念也影響到了前端，「微前端」應(yīng)運(yùn)而生。
微前端（Micro-Frontends）是一種類似于微服務(wù)的架構(gòu)，它將微服務(wù)的理念應(yīng)用于瀏覽器端，即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用，各個(gè)前端應(yīng)用可以獨(dú)立運(yùn)行、獨(dú)立開(kāi)發(fā)、獨(dú)立部署。
通過(guò)跟微服務(wù)進(jìn)行對(duì)比，我們可以更清晰地理解微前端的概念：
相比于傳統(tǒng)的前端工程，微前端架構(gòu)具備以下幾大優(yōu)勢(shì)：
大幅提升研發(fā)效能：將大工程進(jìn)行拆分，顯著提高打包構(gòu)建速度，代碼簡(jiǎn)潔、解耦、更易維護(hù)；
定制化編排產(chǎn)品：將微應(yīng)用進(jìn)行個(gè)性化編排組合，快速進(jìn)行產(chǎn)品創(chuàng)新；
定向增量升級(jí)：各微前端單獨(dú)部署，可定向增量升級(jí)某一微應(yīng)用，而不影響其他微應(yīng)用，大大節(jié)省了部署成本和降低升級(jí)風(fēng)險(xiǎn)。
基于豐富的技術(shù)實(shí)踐經(jīng)驗(yàn)，長(zhǎng)亮科技Web前端團(tuán)隊(duì)在微前端領(lǐng)域的深入探索已有所建樹(shù)。本文將重點(diǎn)分享在微服務(wù)框架的背景下，長(zhǎng)亮科技自主研發(fā)和設(shè)計(jì)的微前端解決方案。
微前端技術(shù)選型之路
微前端架構(gòu)的實(shí)現(xiàn)方式有多種技術(shù)路線，包括路由分發(fā)式、應(yīng)用微服務(wù)化、微應(yīng)用、微件化、前端容器化、應(yīng)用組件化等，需根據(jù)具體場(chǎng)景選用合適的方式。在某些場(chǎng)景下，可能沒(méi)有合適的方案，也可能同時(shí)使用多種方案。
因此在做技術(shù)選型前，首先需要對(duì)公司的產(chǎn)品現(xiàn)狀進(jìn)行整體梳理，結(jié)果如下：
現(xiàn)有前端框架：公司主流使用vue,但是一些老舊系統(tǒng)仍使用react、jquery等；
前端工程拆分粒度：大部分產(chǎn)品還是傳統(tǒng)的大工程形態(tài)；有部分產(chǎn)品已進(jìn)行了模塊化、組件化拆分，將一個(gè)大工程拆分成了多個(gè)小工程，各工程通過(guò)發(fā)布npm插件的形式，最終被一個(gè)主工程安裝聚合。
通過(guò)對(duì)公司現(xiàn)有產(chǎn)品的分析，最終我們最終確認(rèn)了技術(shù)選型的要求：
能夠做到跨技術(shù)棧，不局限于一種前端框架；
能夠?qū)pm插件改造成以微應(yīng)用的形式進(jìn)行聚合。
此外，根據(jù)我們的產(chǎn)品特性，微前端框架還需滿足以下幾點(diǎn)需求：
● 微應(yīng)用獨(dú)立開(kāi)發(fā)
● 微應(yīng)用獨(dú)立部署
● 跨技術(shù)棧，不局限于一種前端框架
● 能夠?qū)pm插件改造成以微應(yīng)用的形式進(jìn)行聚合
● 可將微應(yīng)用進(jìn)行編排組合，輸出不同的產(chǎn)品
● 加載器底座使用vue
結(jié)合公司的框架能力需求，我們最終選定三種微前端技術(shù)路線結(jié)合的方式：
應(yīng)用微服務(wù)化：針對(duì)于無(wú)法拆分的系統(tǒng)和非vue系統(tǒng)，采取微服務(wù)化接入，進(jìn)行技術(shù)驗(yàn)證后選擇了阿里qiankun框架；
微應(yīng)用化：針對(duì)vue技術(shù)棧已做模塊化拆分的系統(tǒng)工程，采取微應(yīng)用化接入，使用了webpack5提供的模塊聯(lián)邦；
前端容器化: 針對(duì)一些老舊的非spa單頁(yè)面的系統(tǒng)，采取iframe接入。
微前端解決方案設(shè)計(jì)思路
從前文所述的微前端概念可知，中心加載器是微前端的核心所在，而加載器需具備三個(gè)基本能力：
路由分發(fā)；
加載微應(yīng)用的靜態(tài)資源；
可在加載器上任意上架下架微應(yīng)用。
基于上述認(rèn)知，我們對(duì)微前端解決方案的各個(gè)模塊做了如下設(shè)計(jì)：
標(biāo)識(shí)微應(yīng)用
如何保證加載器能正確的識(shí)別到對(duì)應(yīng)的微應(yīng)用呢？
我們決定為每一個(gè)微應(yīng)用定制一個(gè)唯一id標(biāo)記，即編碼appCode。
中心化路由
微服務(wù)的核心是注冊(cè)中心，微前端是否也需要一個(gè)注冊(cè)中心呢？如果需要，那么微前端的注冊(cè)中心又是什么呢？
通常情況下，前端頁(yè)面的渲染是靠路由來(lái)控制的，那我們是否可以利用前端的路由體系來(lái)設(shè)計(jì)一套微前端的注冊(cè)中心呢？
基于這個(gè)思路，我們初步設(shè)計(jì)了一套加載器的工作流程：
1) 加載器底座拉取微應(yīng)用配置信息
2) 將配置中的微應(yīng)用注冊(cè)到注冊(cè)中心
3) 瀏覽器url變更驅(qū)動(dòng)loader加載器加載對(duì)應(yīng)微應(yīng)用的資源
4) 加載微應(yīng)用
微應(yīng)用配置
依據(jù)上述加載器的工作流程圖，我們整理出微應(yīng)用的配置文件結(jié)構(gòu)以及字段：
注冊(cè)中心
依據(jù)上文提到的注冊(cè)中心即是路由的思路，構(gòu)建出如下路由結(jié)構(gòu)（以vue-router為例）：
以微應(yīng)用唯一編碼做為路由的name[path]。
這里需要注意的是，考慮到微應(yīng)用的動(dòng)態(tài)加載，加載器加載的微應(yīng)用個(gè)數(shù)不做限制，如一次性將所有的微應(yīng)用路由全部加載，勢(shì)必會(huì)造成路由數(shù)據(jù)過(guò)于龐大，因此初始化時(shí)只注冊(cè)中心路由，微應(yīng)用對(duì)應(yīng)的頁(yè)面路由，則在第一次進(jìn)入當(dāng)前微應(yīng)用的時(shí)候創(chuàng)建。此步驟放在loader加載器中實(shí)現(xiàn)。
Loader加載器
加載器通過(guò)監(jiān)聽(tīng)路由切換，主動(dòng)獲取路由對(duì)應(yīng)的微應(yīng)用的靜態(tài)資源，繼而進(jìn)行頁(yè)面渲染。
加載器主要工作流程如下：
依據(jù)此流程可以編寫出加載器的流程代碼(以vue為例)：
微應(yīng)用設(shè)計(jì)
微應(yīng)用的設(shè)計(jì)分為微服務(wù)化接入（qiankun）和微應(yīng)用化接入。
1、微服務(wù)化-qiankun
首先在應(yīng)用入口增加qiankun的生命周期
為了讓微應(yīng)用能被加載器順利加載，其構(gòu)建后的文件結(jié)構(gòu)以及構(gòu)建路徑需做適配。
為了區(qū)分請(qǐng)求資源的歸屬，在每個(gè)靜態(tài)資源前都加上了appCode(微應(yīng)用編碼)，例如/app1/index.index,/app1/lib.js ,/app1/lib.css。因此在構(gòu)建時(shí)候publicPath需設(shè)置成”./”相對(duì)路徑。
構(gòu)建后的文件夾一級(jí)目錄下需包含微應(yīng)用的配置文件和入口文件。
以下為qiankun應(yīng)用打包后的文件結(jié)構(gòu)：
config.json：微應(yīng)用配置文件
Index.html：微應(yīng)用入口文件
2、微應(yīng)用化-模塊聯(lián)邦
模塊聯(lián)邦主要是利用wenpack5提供的ModuleFederationPlugin將組件模塊化輸出。
通過(guò)模塊聯(lián)邦導(dǎo)出組件，最終生成的文件結(jié)構(gòu)如下：
config.json：微應(yīng)用配置文件
remoteEntry.js：微應(yīng)用入口文件
長(zhǎng)亮科技微前端框架產(chǎn)品
綜上所述方案設(shè)計(jì)整體思路，經(jīng)過(guò)產(chǎn)品化打磨后，長(zhǎng)亮科技Web前端團(tuán)隊(duì)基于公司現(xiàn)有前端低代碼平臺(tái)，自主研發(fā)和設(shè)計(jì)的微前端框架產(chǎn)品正式落地。
基礎(chǔ)類庫(kù)：為解決樣式和編碼規(guī)范統(tǒng)一等問(wèn)題，需要一系列的基礎(chǔ)類庫(kù)，如基礎(chǔ)組件庫(kù)，樣式庫(kù)等；
微前端底座：提供基礎(chǔ)的admin能力，通過(guò)門戶布局組件提供擴(kuò)展修改能力，底座核心包含注冊(cè)中心，資源加載器；
微應(yīng)用開(kāi)發(fā)腳手架：提供標(biāo)準(zhǔn)工程結(jié)構(gòu)的開(kāi)發(fā)腳手架，開(kāi)發(fā)者可專注于業(yè)務(wù)開(kāi)發(fā)，不需重復(fù)調(diào)試編譯構(gòu)建等復(fù)雜的接入規(guī)范；
低代碼平臺(tái)輸出標(biāo)準(zhǔn)微應(yīng)用：通過(guò)低代碼平臺(tái)的可視化配置，快速輸出標(biāo)準(zhǔn)的微應(yīng)用，無(wú)縫接入微前端底座。
微前端部署場(chǎng)景示例
微前端的部署有兩種形式，一種是將所有微應(yīng)用的資源與底座加載器合并成一個(gè)文件夾，進(jìn)行合并部署，只提供一個(gè)Web服務(wù)；另一種則是將底座和微應(yīng)用分開(kāi)部署，每個(gè)微應(yīng)用都提供單獨(dú)的Web服務(wù)。
合并部署
獨(dú)立部署
問(wèn)題與反思
在微前端框架的實(shí)施過(guò)程中，遇到的主要問(wèn)題有如下幾點(diǎn)：
頁(yè)面樣式混亂：因?yàn)槲?yīng)用具備獨(dú)立開(kāi)發(fā)的特性，不同團(tuán)隊(duì)開(kāi)發(fā)的微應(yīng)用聚合到一起時(shí)，無(wú)法避免出現(xiàn)頁(yè)面混亂、不統(tǒng)一等問(wèn)題；
團(tuán)隊(duì)協(xié)同性差：伴隨著團(tuán)隊(duì)自治程度的提升，協(xié)作困難等問(wèn)題隨之產(chǎn)生；
用戶流量負(fù)擔(dān)：獨(dú)立構(gòu)建意味著公共資源的冗余，繼而增加用戶的流量負(fù)擔(dān)；
問(wèn)題排查困難：當(dāng)微應(yīng)用與加載器底座的對(duì)接出現(xiàn)問(wèn)題時(shí)，除框架構(gòu)建者外，開(kāi)發(fā)人員往往很難定位問(wèn)題所在。
當(dāng)前，因?yàn)榧夹g(shù)發(fā)展的桎梏，有些問(wèn)題確實(shí)難以短期內(nèi)有效解決，但這也正是我們軟件開(kāi)發(fā)者們需要不斷為之努力和探索的方向所在。未來(lái)，微前端不一定是未來(lái)發(fā)展趨勢(shì)的收束點(diǎn)，但是它在未來(lái)一定會(huì)發(fā)揮重要作用。
