微前端在大數(shù)據(jù)產(chǎn)品中的應(yīng)用背景和應(yīng)用原理

導(dǎo)讀：本文由梯度科技前端研發(fā)部高級開發(fā)工程師賀信撰寫，主要介紹如何基于前沿開源的前端技術(shù)方案實(shí)現(xiàn)微前端在大數(shù)據(jù)平臺中的應(yīng)用落地，并對所取得的應(yīng)用效果進(jìn)行剖析。主要包括以下幾個(gè)方面：

案例背景

微前端解決方案對比和決策

實(shí)例應(yīng)用剖析

無界框架源碼與原理

實(shí)踐總結(jié)

一、案例背景

根據(jù)公司產(chǎn)品某項(xiàng)需求，需要引入一個(gè)新應(yīng)用作為一個(gè)獨(dú)立模塊集成進(jìn)已有大型平臺。公司本身產(chǎn)品的前端技術(shù)棧與待引入的新應(yīng)用技術(shù)棧不同，分別采用的是vue和react，使用的UI框架也截然不同。新應(yīng)用可以獨(dú)立開發(fā)部署，但為了產(chǎn)品體驗(yàn)的一致性，需要將新應(yīng)用嵌入已有業(yè)務(wù)中，并通過少量的改造使產(chǎn)品功能融為一體。

1.0階段：采用外鏈跳轉(zhuǎn)的方式，點(diǎn)擊菜單打開新tab頁展示數(shù)據(jù)開發(fā)模塊功能

2.0階段：采用iframe內(nèi)嵌頁面的方式，點(diǎn)擊菜單在當(dāng)前頁面通過iframe加載url

3.0階段：采用wujie微前端方案進(jìn)行父子應(yīng)用改造，組件式加載子應(yīng)用方便快捷

4.0階段：利用微前端能力實(shí)現(xiàn)模塊拆分節(jié)約50%工作量，新增跨模塊功能不再受限于技術(shù)棧

在引入wujie微前端方案后，對大數(shù)據(jù)平臺產(chǎn)生了積極影響：

收益變現(xiàn)

主框架不限制接入應(yīng)用的技術(shù)棧，微應(yīng)用具備完全自主權(quán)，做到新技術(shù)選型時(shí)“技術(shù)棧無關(guān)”。

微應(yīng)用倉庫獨(dú)立，部署完成后主框架刷新時(shí)自動(dòng)完成同步更新，每個(gè)微應(yīng)用之間狀態(tài)隔離，運(yùn)行時(shí)狀態(tài)不共享，獨(dú)立運(yùn)行時(shí)。

在面對各種復(fù)雜場景時(shí)，對已經(jīng)存在的系統(tǒng)做全量的技術(shù)棧升級或重構(gòu)不現(xiàn)實(shí)，而微前端是一種非常好的實(shí)施漸進(jìn)式重構(gòu)的手段和策略，能夠做到增量升級。

便捷的alive?；钅Ｊ剑梢源_保在用戶經(jīng)常切換路由的場景下不丟失編輯狀態(tài)，非常適合大數(shù)據(jù)平臺的離線開發(fā)、實(shí)時(shí)開發(fā)、算法開發(fā)、低代碼等業(yè)務(wù)場景。

持續(xù)增值

開啟preloadApp預(yù)加載后，能顯著減少白屏?xí)r間，結(jié)合保活模式可獲得極速的打開體驗(yàn)。

支持 vite 等 ESM 腳本運(yùn)行。

提供無感知的iframe降級方案，理論上兼容到IE9，配合插件系統(tǒng)能解決99%的兼容問題。

未來接入其他第三方應(yīng)用（如BI、3D）將成為剛需，可無負(fù)擔(dān)的擴(kuò)展子應(yīng)用。

二、微前端解決方案對比和決策

可能有人會問目前市面上主流的微前端方案有很多，為什么選擇wujie微前端方案呢？該如何對比和決策？在這之前先來了解一下什么是微前端：

什么是微前端？

微前端是多個(gè)團(tuán)隊(duì)通過獨(dú)立發(fā)布功能的方式來共同構(gòu)建現(xiàn)代化 web 應(yīng)用的技術(shù)手段及方法策略，英文名稱叫 micro-frontends。

2016年，首次提出“微前端”的概念，微服務(wù)這個(gè)被廣泛應(yīng)用于服務(wù)端的技術(shù)范式開始擴(kuò)展到前端領(lǐng)域。

趨勢：前端越豐富復(fù)雜，項(xiàng)目越龐大難以維護(hù)。

核心思想：獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)特定的業(yè)務(wù)和開發(fā)獨(dú)立的功能模塊。

架構(gòu)對比

需要注意的是，這些技術(shù)并不是相互排斥的，實(shí)際應(yīng)用中可能會使用它們的組合來實(shí)現(xiàn)應(yīng)用程序的需求。例如，同構(gòu)應(yīng)用可以與JAMStack和微前端一起使用，以提高應(yīng)用程序的性能、可維護(hù)性和可擴(kuò)展性。

實(shí)踐經(jīng)驗(yàn)告訴我們，永遠(yuǎn)不要追求最好的架構(gòu)，而要追求最不糟糕的架構(gòu)。真實(shí)世界里完美的架構(gòu)并不存在，架構(gòu)也沒有對錯(cuò)之分，只有根據(jù)環(huán)境進(jìn)行利弊權(quán)衡后的最佳結(jié)果。

微前端決策

在選擇何種方案決策的時(shí)候 我們整理了一份決策要素清單：

參考這份清單可以全方位對比每個(gè)框架的優(yōu)缺點(diǎn)，幫助選擇最適合的方案。我們選取了目前市面上最流行的幾種方案進(jìn)行技術(shù)調(diào)研：

阿里開源的 qiankun 方案，基于 single-spa

京東開源的 micro-app 方案，基于 webcomponent + qiankun sandbox

歡聚時(shí)代開源的 EMP 方案，基于 webpack5 module federation

字節(jié)跳動(dòng)開源 Garfish 方案，這是一個(gè)集部署、框架、調(diào)試于一體的全套解決方案

騰訊開源的 Wujie 方案，基于 WebComponent 容器 + iframe 沙箱

詳細(xì)調(diào)研了各類方案的優(yōu)缺點(diǎn)之后，我們根據(jù)主客觀判斷給出了一個(gè)評分表：

最終經(jīng)過多方面的對比和分析，并且在基于產(chǎn)品開發(fā)周期短、使用和改造成本低的實(shí)際情況下，決定選擇wujie方案。

三、實(shí)例應(yīng)用剖析

這部分內(nèi)容主要介紹wujie的實(shí)施方案和細(xì)節(jié)，對應(yīng)wujie使用以及具體開發(fā)過程中解決的問題和最佳實(shí)踐。

控制臺展示

從瀏覽器按F12調(diào)出開發(fā)者工具，可以查看大數(shù)據(jù)平臺實(shí)施微前端改造后的父子應(yīng)用前端代碼結(jié)構(gòu)：

從元素窗口看到，引入wujie后html里面的實(shí)際結(jié)構(gòu)，其中wujie-app就是wujie創(chuàng)建的webcomponent自定義組件，可以理解為當(dāng)前位置之前使用的iframe標(biāo)簽，現(xiàn)在把標(biāo)簽替換為了wujie-app，里面的內(nèi)容就是子應(yīng)用也就是引入的新模塊的內(nèi)容，外面的內(nèi)容就是父應(yīng)用也就是原來已有的部分。

另外可以看到該自定義組件里面只有dom元素和css樣式內(nèi)容，最關(guān)鍵的js代碼去哪里了呢？繼續(xù)往下翻閱代碼到底部，發(fā)現(xiàn)在最底下多了一個(gè)iframe標(biāo)簽，這個(gè)標(biāo)簽的路徑是當(dāng)前網(wǎng)頁的路徑，樣式是隱藏的狀態(tài)。

子應(yīng)用的js是通過一個(gè)iframe沙箱的形式加載進(jìn)來的。在wujie微前端框架的影響下，子應(yīng)用的js和dom元素以及css樣式是分開的。

wujie使用

wujie的組件式加載方式非常方便快捷，本部門將介紹wujie的vue組件的使用方式。

wujie基于vue2、vue3、React框架的組件封裝了對應(yīng)的npm包：wujie-vue2、wujie-vue3、wujie-react

父應(yīng)用安裝并全局引入wujie-vue2。

常規(guī)的使用組件方式和props傳遞參數(shù)，與普通組件別無二致。

子應(yīng)用本身無需安裝任何包，無界對子應(yīng)用注入了$wujie對象，可以通過多種方式獲取。

也就是說在滿足跨域條件下子應(yīng)用可以不用做任何改造，可以直接把iframe替換為wujie組件。

需要特別注意一點(diǎn)的是wujie的運(yùn)行模式，子應(yīng)用是否開啟了?；钜约笆欠襁M(jìn)行生命周期的改造會進(jìn)入完全不同的處理流程。

實(shí)際應(yīng)用方案

以下是我們根據(jù)項(xiàng)目實(shí)際情況使用的實(shí)施方案和原因理由，需要說明的是在不同公司不同項(xiàng)目是完全可以根據(jù)需求和wujie提供的各種能力來靈活調(diào)整方案的，這里并沒有什么最佳實(shí)踐，個(gè)人認(rèn)為只要能很好的滿足需求就都是最佳實(shí)踐。

?；钅Ｊ?/strong>