簡介： 微前端帶來明顯好處的同時，也面臨着痛點。對於已有站點，如何在老的技術棧基礎上接入一個微前端？需要哪些通用功能？如何解決插件機制？本文分享一種微前端的接入方案和實現細則。
一 、前言
微前端，這個概念已經在國內不止一次的登上各大熱門話題，它所解決的問題也很明顯，這幾個微前端所提到的痛點在我們團隊所維護的項目中也是非常凸顯。
但我始終認爲，一個新的技術、浪潮，每每被討論最熱門的一定是他背後所代表的傑出思考。
"微前端就是...xx 框架，xx 技術"
這種話就有點把這種傑出的思路說的侷限了，我只能認爲他是外行人，來蹭這個詞的熱度。
在我所負責的項目和團隊中，已經有非常大的存量技術棧和頁面已經在線上運行，任何迭代升級都必須要保證小心翼翼，萬無一失。
可以說，從一定程度來講，微前端所帶來的這些好處是從用戶體驗和技術維護方面的，對業務的價值並不能量化體現，落地這項技術秉着既要也要還要的指導方針。
我們對存量技術棧一定需要保持敬畏，隔離，影響範圍可控的幾個基本要素，然後再考慮落地實施微前端方案。
所以，在這個基本要素和指導方針下，要落地這項新的技術，一定要充分了解當前改造站點所存在的技術方案、佔比以及當前成熟的微前端框架已提供的能力差異，切勿生搬硬套。
二 、背景
我所在團隊維護的項目都是些 PC 操作後臺（Workstation），這些工作臺會存在不同的國家，不同時區，不同合作方等等問題。
如果需要開發一個新的頁面需求，很可能投入進來的開發人員都來自不同團隊，此時我們要在完成現有需求的同時還需要保證多個管理頁面的風格統一，設計規範統一，組件統一，交互行爲統一這非常困難。
當該業務需要遷移到另外一個工作臺時，雖然需要保持邏輯一致，但導航欄、主題等卻不同。
當前存量的方案都是採用 Java 直接進行 Template 渲染出 HTML，經過前面幾代前輩的迭代，不同系統中已經存在幾種不同技術棧產出的頁面。
雖然都是 React 來實現的，但是前輩們都非常能折騰，沒有一個是按照常規 React 組件形式開發出來的。
比如：
- 大部分頁面是通過一份 JSON 配置，消費組件生成的頁面。
- 部分頁面是通過另外一個團隊定義的 JSON 配置消費組件生成的，與上面 JSON 完全不一樣。
- 還有一部分頁面，是通過一套頁面發佈平臺提供的 JS Bundle 加載出來的。
面對這樣的技術背景下，除了微笑的喊 MMP，含淚說着自己聽不懂的話（存在即合理，不難要你幹嘛？），還得接地氣地出這樣一個落地方案。
三 、方案 & 流程圖
首先，需要明確的分析出站點所有頁面，所需要加載的通用特性：
[圖片上傳失敗...(image-647d18-1613979234492)]
上述是精簡過後的一些通用功能特性，這裏簡單做下介紹：
- Layout Loader：用於加載不同工作臺的導航
- DADA Loader：用於加載 JSON 配置的頁面
- Source Code Loader：用於加載 JS Bundle
- Micro Loader：用於處理微前端加載
- Log Report：用於日誌埋點
- Time Zone：用於切換時區
- i18n：用於切換多語言
- Guider：用於統一管控用戶引導
除此以外可能還會存在以下這些頁面擴展能力：
- 安全監控
- 流量管控
- 彈窗管控
- 問卷調查
- 答疑機器人
粗略統一歸類後來看，頁面的大體加載流程應該是這樣：
[圖片上傳失敗...(image-7bd133-1613979234492)]
四、 實現細則
基於上述一個加載思路，首先需要做的是頁面加載路徑收口，需要保證所有頁面的加載入口是在一個統一的 Loader 下，然後纔可以較爲系統的處理所有頁面的加載生命週期。
在收斂的同時，同樣需要保持開放，對核心加載路徑要保持插件化開放，隨時支持不同的擴展能力，渲染技術棧接入。
1 、插件機制
所以，在主路徑上，通過 Loader 加載配置進行處理，這份配置在主路徑中提供上下文，然後交由插件進行消費，如圖所示：
[圖片上傳失敗...(image-3a0e07-1613979234492)]
舉個例子，拿一個獨立的 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 & country
resource: {
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 、安全遷移
對於我所在團隊負責的項目來說，萬萬做不得一刀切的方案，所以針對現有存量頁面，需要完整分析當前存量技術棧：
[圖片上傳失敗...(image-a2ae29-1613979234492)]
針對上述存量頁面來說，需要從左到右分批進行頁面級別控制上線部署，對於左側部分頁面甚至需要做些項目改造後纔可部署接入上線。
這類遷移測試需要處理出一套自動化 e2e 測試流程，通過分批遷移同時梳理出 微前端註冊表 。
有了這兩項流程保證及範圍控制，當前方案所上線內容完全可控，剩下要處理的大部分就是較爲重複的體力活了，覆蓋率也可量化。
3、 微前端形態
按照上述方案遷移，那麼預期的微前端形態將會是：
- 每個開啓微前端的頁面都可成爲主應用。
- 微前端是插件可選項，如果因爲微前端導致的業務異常可隨時關閉。
- 同爲微前端的頁面路由相互之間切換可實現局部刷新形態，而跳轉至非微前端註冊表中的頁面則會直接頁面跳轉。隨着微前端頁面覆蓋率提高，局部刷新的覆蓋率也會逐漸提高。
- 可通過不同擴展插件，加載不同技術棧類型的存量頁面，轉換爲對應子應用。
[圖片上傳失敗...(image-3f3985-1613979234492)]
在 SchemaResolver 中的註冊和調用路徑如下：
[圖片上傳失敗...(image-52dfcd-1613979234492)]
五 、總結
透過技術看本質，微前端所代表的傑出思維，纔是真正解決具體問題關鍵所在，只有解決了具體的業務問題，這項技術纔有價值轉換。
不要爲了微前端做微前端，不要爲了小程序做小程序。
當前，通過 SchemaResolver，可以針對不同角色提供不同的開放能力：
- 針對平臺管理員，提供插件能力開放全局擴展能力。
- 針對頁面開發者，提供標準化接入方案路徑，提供多種技術棧接入能力，並無感知提供微前端，多語言，埋點，菜單，主題加載等能力。解耦了不同系統公共能力，同時，這種方式可以讓頁面開發者快速將具體業務邏輯遷移到其他平臺。
- 針對第三方接入者，不需要關心瞭解系統菜單、主題接入方式，提供統一的接入口徑，通過微前端隔離技術棧、隔離子應用樣式。最後通過統一的頁面系統管控，輕鬆入住對應平臺，同時可以全局看到站點頁面情況。
作者：開發者小助手_LS
本文爲阿里雲原創內容，未經允許不得轉載
作者：開發者小助手_LS
本文爲阿里雲原創內容，未經允許不得轉載