如何接地氣地接入微前端?

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

一 、前言

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

但我始終認爲，一個新的技術、浪潮，往往被討論最熱門的必定是他背後所表明的傑出思考。

"微前端就是...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：用於統一管控用戶引導

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

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

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

4、 實現細則

基於上述一個加載思路，首先須要作的是頁面加載路徑收口，須要保證全部頁面的加載入口是在一個統一的 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 測試流程，經過分批遷移同時梳理出 微前端註冊表 。

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

三、 微前端形態

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

• 每一個開啓微前端的頁面均可成爲主應用。
• 微前端是插件可選項，若是由於微前端致使的業務異常可隨時關閉。
• 同爲微前端的頁面路由相互之間切換可實現局部刷新形態，而跳轉至非微前端註冊表中的頁面則會直接頁面跳轉。隨着微前端頁面覆蓋率提升，局部刷新的覆蓋率也會逐漸提升。
• 可經過不一樣擴展插件，加載不一樣技術棧類型的存量頁面，轉換爲對應子應用。

在 SchemaResolver 中的註冊和調用路徑以下：

五 、總結

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

不要爲了微前端作微前端，不要爲了小程序作小程序。

當前，經過 SchemaResolver，能夠針對不一樣角色提供不一樣的開放能力：

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

做者：開發者小助手_LS
原文連接本文爲阿里雲原創內容，未經容許不得轉載