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

案例背景

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

實例應用剖析

無界框架源碼與原理

實踐總結(jié)

一、案例背景

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

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

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

3.0階段：采用wujie微前端方案進行父子應用改造，組件式加載子應用方便快捷

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

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

收益變現(xiàn)

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

微應用倉庫獨立，部署完成后主框架刷新時自動完成同步更新，每個微應用之間狀態(tài)隔離，運行時狀態(tài)不共享，獨立運行時。

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

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

持續(xù)增值

開啟preloadApp預加載后，能顯著減少白屏時間，結(jié)合?；钅Ｊ娇色@得極速的打開體驗。

支持 vite 等 ESM 腳本運行。

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

未來接入其他第三方應用（如BI、3D）將成為剛需，可無負擔的擴展子應用。

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

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

什么是微前端？

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

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

趨勢：前端越豐富復雜，項目越龐大難以維護。

核心思想：獨立的團隊負責特定的業(yè)務和開發(fā)獨立的功能模塊。

架構(gòu)對比

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

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

微前端決策

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

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

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

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

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

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

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

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

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

三、實例應用剖析

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

控制臺展示

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

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

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

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

wujie使用

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

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

父應用安裝并全局引入wujie-vue2。

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

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

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

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

實際應用方案

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

?；钅Ｊ?/strong>