簡介： 微前端帶來明顯好處的同時，也面臨着痛點。對于已有站點，如何在老的技術棧基礎上接入一個微前端？需要哪些通用功能？如何解決插件機制？本文分享一種微前端的接入方案和實作細則。
一 前言
微前端，這個概念已經在國内不止一次的登上各大熱門話題，它所解決的問題也很明顯，這幾個微前端所提到的痛點在我們團隊所維護的項目中也是非常凸顯。
但我始終認為，一個新的技術、浪潮，每每被讨論最熱門的一定是他背後所代表的傑出思考。
"微前端就是...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 & 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 安全遷移
對于我所在團隊負責的項目來說，萬萬做不得一刀切的方案，是以針對現有存量頁面，需要完整分析目前存量技術棧：
針對上述存量頁面來說，需要從左到右分批進行頁面級别控制上線部署，對于左側部分頁面甚至需要做些項目改造後才可部署接入上線。
這類遷移測試需要處理出一套自動化 e2e 測試流程，通過分批遷移同時梳理出 微前端系統資料庫 。
有了這兩項流程保證及範圍控制，目前方案所上線内容完全可控，剩下要處理的大部分就是較為重複的體力活了，覆寫率也可量化。
3 微前端形态
按照上述方案遷移，那麼預期的微前端形态将會是：
- 每個開啟微前端的頁面都可成為主應用。
- 微前端是插件可選項，如果因為微前端導緻的業務異常可随時關閉。
- 同為微前端的頁面路由互相之間切換可實作局部重新整理形态，而跳轉至非微前端系統資料庫中的頁面則會直接頁面跳轉。随着微前端頁面覆寫率提高，局部重新整理的覆寫率也會逐漸提高。
- 可通過不同擴充插件，加載不同技術棧類型的存量頁面，轉換為對應子應用。
在 SchemaResolver 中的注冊和調用路徑如下：
五 總結
透過技術看本質，微前端所代表的傑出思維，才是真正解決具體問題關鍵所在，隻有解決了具體的業務問題，這項技術才有價值轉換。
不要為了微前端做微前端，不要為了小程式做小程式。
目前，通過 SchemaResolver，可以針對不同角色提供不同的開放能力：
- 針對平台管理者，提供插件能力開放全局擴充能力。
- 針對頁面開發者，提供标準化接入方案路徑，提供多種技術棧接入能力，并無感覺提供微前端，多語言，埋點，菜單，主題加載等能力。解耦了不同系統公共能力，同時，這種方式可以讓頁面開發者快速将具體業務邏輯遷移到其他平台。
- 針對第三方接入者，不需要關心了解系統菜單、主題接入方式，提供統一的接入口徑，通過微前端隔離技術棧、隔離子應用樣式。最後通過統一的頁面系統管控，輕松入住對應平台，同時可以全局看到站點頁面情況。
https://developer.aliyun.com/article/779730?
版權聲明： 本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。