簡介：微前端帶來明顯好處的同時，也面臨著痛點。對于已有站點，如何在老的技術棧基礎上接入一個微前端？需要哪些通用功能？如何解決插件機制？本文分享一種微前端的接入方案和實現細則。

一 前言

微前端，這個概念已經在國內不止一次的登上各大熱門話題，它所解決的問題也很明顯，這幾個微前端所提到的痛點在我們團隊所維護的項目中也是非常凸顯。

但我始終認為，一個新的技術、浪潮，每每被討論最熱門的一定是他背后所代表的杰出思考。

"微前端就是...xx 框架，xx 技術"

這種話就有點把這種杰出的思路說的局限了，我只能認為他是外行人，來蹭這個詞的熱度。

在我所負責的項目和團隊中，已經有非常大的存量技術棧和頁面已經在線上運行，任何迭代升級都必須要保證小心翼翼，萬無一失。

可以說，從一定程度來講，微前端所帶來的這些好處是從用戶體驗和技術維護方面的，對業務的價值并不能量化體現，落地這項技術秉著既要也要還要的指導方針。

我們對存量技術棧一定需要保持敬畏，隔離，影響范圍可控的幾個基本要素，然后再考慮落地實施微前端方案。

所以，在這個基本要素和指導方針下，要落地這項新的技術，一定要充分了解當前改造站點所存在的技術方案、占比以及當前成熟的微前端框架已提供的能力差異，切勿生搬硬套。

二 背景

我所在團隊維護的項目都是些 PC 操作后臺（Workstation），這些工作臺會存在不同的國家，不同時區，不同合作方等等問題。

如果需要開發一個新的頁面需求，很可能投入進來的開發人員都來自不同團隊，此時我們要在完成現有需求的同時還需要保證多個管理頁面的風格統一，設計規范統一，組件統一，交互行為統一這非常困難。

當該業務需要遷移到另外一個工作臺時，雖然需要保持邏輯一致，但導航欄、主題等卻不同。

當前存量的方案都是采用 Java 直接進行 Template 渲染出 HTML，經過前面幾代前輩的迭代，不同系統中已經存在幾種不同技術棧產出的頁面。

雖然都是 React 來實現的，但是前輩們都非常能折騰，沒有一個是按照常規 React 組件形式開發出來的。

比如：

• 大部分頁面是通過一份 JSON 配置，消費組件生成的頁面。
• 部分頁面是通過另外一個團隊定義的 JSON 配置消費組件生成的，與上面 JSON 完全不一樣。
• 還有一部分頁面，是通過一套頁面發布平臺提供的 JS Bundle 加載出來的。

面對這樣的技術背景下，除了微笑的喊 MMP，含淚說著自己聽不懂的話（存在即合理，不難要你干嘛？），還得接地氣地出這樣一個落地方案。

三 方案 & 流程圖

首先，需要明確的分析出站點所有頁面，所需要加載的通用特性：

上述是精簡過后的一些通用功能特性，這里簡單做下介紹：

• Layout Loader：用于加載不同工作臺的導航
• DADA Loader：用于加載 JSON 配置的頁面
• Source Code Loader：用于加載 JS Bundle
• Micro Loader：用于處理微前端加載
• Log Report：用于日志埋點
• Time Zone：用于切換時區
• i18n：用于切換多語言
• Guider：用于統一管控用戶引導

除此以外可能還會存在以下這些頁面擴展能力：

• 安全監控
• 流量管控
• 彈窗管控
• 問卷調查
• 答疑機器人

粗略統一歸類后來看，頁面的大體加載流程應該是這樣：

四 實現細則

基于上述一個加載思路，首先需要做的是頁面加載路徑收口，需要保證所有頁面的加載入口是在一個統一的 Loader 下，然后才可以較為系統的處理所有頁面的加載生命周期。

在收斂的同時，同樣需要保持開放，對核心加載路徑要保持插件化開放，隨時支持不同的擴展能力，渲染技術棧接入。

1 插件機制

所以，在主路徑上，通過 Loader 加載配置進行處理，這份配置在主路徑中提供上下文，然后交由插件進行消費，如圖所示：

舉個例子，拿一個獨立的 JS Bundle 類型的子應用來說：

<div id="root"></div> <script src="https://cdn.address/schema-resolver/index.js"></script> <script src="https://cdn.address/schema-resolver/plugin/layout.js"></script> <script src="https://cdn.address/schema-resolver/plugin/source-code.js"></script> <script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></script> <script src="https://cdn.address/schema-resolver/plugin/i18n.js"></script><script>SchemaResolver.render({micro: true,host: "dev.address",hfType: "layout1",externals: ["//{HOST}/theme1/index.css"],// host is cdn prefix, the resource maybe in different env & countryresource: {js: "/index.js",css: "/index.css",},},{ container: document.querySelector("#root") }); </script>

通過上述的 Plugin 引入，即可開啟和消費不同的配置。

這里引入了 Layout Plugin，該插件會消費 hfType 字段然后去加載對于的 Layout 資源提供 Container 交給下一個環節。

按照配置，當前頁面開啟了微前端，那么 Micro Loader 將會消費提供下來的 Container，然后建立沙箱（這里基于 qiankun），再提供 Container 出來。

最后交由 SourceCode Plugin 進行 Bundle 加載運行和渲染。如果這里是另外一種渲染協議或者技術棧，則可以根據不同配置交由不同插件消費 Container。

這個過程中，每個環節的插件是不依賴的，可插拔的。

比如：

如果不加載 Layout Plugin 將不會消費 hfType 字段，也就不會將 Layout 插件邏輯注入到getContainer方法中，那么將直接得到由最外層下穿的 Container 進行渲染，也就不會有菜單相關透出。

如果不加載 Micro Plugin 同樣不會有微前端的邏輯注入，也就不會建立沙箱，那么頁面渲染流程將會按照常規模式繼續運行。

2 安全遷移

對于我所在團隊負責的項目來說，萬萬做不得一刀切的方案，所以針對現有存量頁面，需要完整分析當前存量技術棧：

針對上述存量頁面來說，需要從左到右分批進行頁面級別控制上線部署，對于左側部分頁面甚至需要做些項目改造后才可部署接入上線。

這類遷移測試需要處理出一套自動化 e2e 測試流程，通過分批遷移同時梳理出 微前端注冊表 。

有了這兩項流程保證及范圍控制，當前方案所上線內容完全可控，剩下要處理的大部分就是較為重復的體力活了，覆蓋率也可量化。

3 微前端形態

按照上述方案遷移，那么預期的微前端形態將會是：

• 每個開啟微前端的頁面都可成為主應用。
• 微前端是插件可選項，如果因為微前端導致的業務異常可隨時關閉。
• 同為微前端的頁面路由相互之間切換可實現局部刷新形態，而跳轉至非微前端注冊表中的頁面則會直接頁面跳轉。隨著微前端頁面覆蓋率提高，局部刷新的覆蓋率也會逐漸提高。
• 可通過不同擴展插件，加載不同技術棧類型的存量頁面，轉換為對應子應用。

在 SchemaResolver 中的注冊和調用路徑如下：

五 總結

透過技術看本質，微前端所代表的杰出思維，才是真正解決具體問題關鍵所在，只有解決了具體的業務問題，這項技術才有價值轉換。

不要為了微前端做微前端，不要為了小程序做小程序。

當前，通過 SchemaResolver，可以針對不同角色提供不同的開放能力：

• 針對平臺管理員，提供插件能力開放全局擴展能力。
• 針對頁面開發者，提供標準化接入方案路徑，提供多種技術棧接入能力，并無感知提供微前端，多語言，埋點，菜單，主題加載等能力。解耦了不同系統公共能力，同時，這種方式可以讓頁面開發者快速將具體業務邏輯遷移到其他平臺。
• 針對第三方接入者，不需要關心了解系統菜單、主題接入方式，提供統一的接入口徑，通過微前端隔離技術棧、隔離子應用樣式。最后通過統一的頁面系統管控，輕松入住對應平臺，同時可以全局看到站點頁面情況。

原文鏈接：https://developer.aliyun.com/article/779730?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的如何接地气地接入微前端?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。