摘要：螞蟻金服前端技術專家有知在 D2 帶來以“标準微前端架構在螞蟻的落地實踐”為題的演講。首先提出了微前端的場景域在螞蟻落地時常遇到的問題，然後詳細介紹了微前端的定義，最後通過實施一個标準的微前端架構，提出面臨的技術決策以及需要處理的技術細節，經過在螞蟻的實踐證明，微前端是一個具有優勢的方案。
微前端的場景域
在選擇一個微前端方案之前，常常需要思考這樣一個問題，我們為什麼需要微前端。通常對微前端的訴求有兩個方面，一是工程上的價值，二是産品上的價值。
對于工程上的價值，可以從一個三年陳的項目來看，如上圖所示，左上角commit的記錄顯示，第一次送出是2016年8月。它的下面是一個codebase代碼，中間是基本的依賴樹dependencies，右側為打包的體積。
雖然這個三年陳的項目看上去版本比較低，但仍然是相對主流的全家桶方案。這樣一個樂觀的項目，在真實的場景中經過三年的時間，也不實用了。因為開發的時間比較長，并且人員流動也比較大，會導緻一些祖傳的代碼出現，其次，在技術上不能及時的更新，導緻開發體驗變得很差，例如打包的時間就超過三分鐘。也有可能在不經意間依賴一些不相容的架構，導緻項目無法更新。種種原因，最後很有可能變成一個遺産項目。
對于産品體驗上的問題，例如上圖所示，要完成一個跳多個控制台任務，在過程中發現每個控制台視覺不統一、流程出現斷點以及重複加載或認證的問題導緻整個産品的體驗較差。
微前端的定義
上圖是來自Micro Frontends網站對微前端的定義。意思是所謂微前端就是一種多個團隊之間可以使用不同技術建構一個現代化web的技術手段以及方法政策。其中的關鍵字是多團隊、采用不同的技術棧以及現代化的web。
微前端的思路是繼承自微服務的思想，如上圖所示。
上圖所示為微前端的架構圖，其中上層為統一共享的拼接層，主要做一些基礎資訊的加載，和對來自不同團隊不同技術棧的用戶端在運作時動态組成一個完整的SPA應用，以及生命周期的排程和事件的管理。總之，微前端是将微服務概念做了一個很好的延伸和實作。
在具體實踐中，衡量一個微前端方案是否是可利用的，需要滿足以下幾個條件，一是技術棧無關性，不僅指子應用之間使用多個不同的架構，也指在使用同一個架構時，有可能在一個長的時間跨度下，由于架構的不相容的更新，導緻應用被鎖死的情況。二是開發、釋出及部署獨立，要求子應用和主應用做到工程上的解耦和獨立。三是應用隔離的能力，是指需要考慮如何不幹擾到原來子應用的開發模式和部署模式的情況下，做好運作時的樣式隔離、JS隔離以及異常隔離等。以上幾點是基于工程價值方面考慮的。此外，也需要動态組合的能力，是基于産品價值方面考慮的。
落地的關鍵問題
微前端架構中的技術選擇
按架構類型區分，正常web應用的架構類型分為兩種，一種是MPA，另一種是SPA。如上圖所示為2017年各雲産品控制台架構調研，除了google cloud之外，大部分的雲廠商都使用MPA架構。MPA的優點在于部署簡單，具備獨立開發和獨立部署的特性。但是，它的缺點是完成一個任務要跳到多個控制台，并且每個控制台又是重複重新整理的。而SPA能極大保證多個任務之間串聯的流暢性，但問題是通常一個SPA是一個技術棧的應用，很難共存多個技術棧方案的選型。SPA和MPA都是微前端方案的基礎選型，但是也都存在各自的問題。
按運作時特性區分，微前端包含兩個類别，一類是單執行個體，另一類是多執行個體。單執行個體場景如上圖中左側，通常是一個頁面級别的組合，例如一個運作時隻有一個App被激活。多執行個體場景如上圖右側，像一個元件或者是容器級别的應用，運作時可以做到多個應用被同時激活。這兩種模式都有自己适應的場景和優勢。微前端架構的核心訴求是實作能支援自由組合的微前端架構，将其他的SPA應用以及其他元件級别的應用自由的組合到平台中。那麼，如何選擇SPA和MPA以及單執行個體和多執行個體是一個問題，我們是否能探索出一種方案，将SPA和MPA工程上的特點結合起來，同時兼顧多執行個體和單執行個體運作時的場景來實作。
技術細節上的決策
為了實作上述的方案，在技術細節上的決策需要注意以下問題：
一是如何做到子應用之間的技術無關；
二是如何設計路由和應用導入；
三是如何做到應用隔離；
四是基礎應用之間資源的處理以及跨應用間通信的選擇。
對于如何做到子應用之間的技術無關問題，我們是通過協定來解決的。如上圖所示的方式，就可以完成子應用的導入。如果子應用接入時做了一些架構上的耦合或者依賴一個具體實作庫的機制，就一定會存在與實作庫版本耦合的可能，不利于整個微前端生态的統一和融合。
如上圖所示是一個不與某個具體架構實作耦合的例子。
對于路由的問題，如上圖所示。這樣一條通路鍊路後，重新整理目前URL通常情況下會發生什麼？正常通路一個站點，經過一番操作之後，進入到站點的清單頁，路由會變大很複雜，但如果是一個微前端使用者，重新整理一下頁面會出現404的情況。解決思路是将404路由fallback到一個異步注冊的子應用路由機制上。
對于應用導入方式的選擇，比較常見的方案是Config Entry，如上圖所示。通過在主應用中注冊子應用依賴哪些JS。這種方案一目了然，但是最大的問題是ConfigEntry的方式很難描述出一個子應用真實的應用資料資訊。真實的子應用會有一些title資訊，依賴容器ID節點資訊，渲染時會依賴節點做渲染，如果隻配JS和CSS，那麼很多資訊是會丢失的，有可能會導緻間接上的依賴。
另外一種方案是HTML Entry，如上圖所示，直接配html，因為html本身就是一個完整的應用的manifest，包含依賴的資訊。HTML Entry的優點是接入應用的資訊可以得到完整的保留，接入應用位址隻需配一次，子應用的原始開發模式得到完整保留，因為子應用接入隻需要告知主應用html在哪，包括在不接入主應用時獨立的打開。它的缺點是将解析的消耗留給了運作時。而Config Entry相較于HTML Entry減少了運作時的解析消耗。Config Entry的缺點是主應用需配置完整的子應用資訊，包含初始DOM資訊、js/css 資源位址等。
對于樣式隔離問題，例如BEM，每個子應用在寫樣式之前要加一些字首，做一些隔離，但是這個做法并不推薦。相對而言，CSS Module更簡單高效，也更智能化，是比較推薦的方式，但是也存在着問題。而Web Components看上去很不錯，但在實踐過程中也會發生一些問題。
例如在Web Components渲染的流程中出現了問題，如上圖所示。
解決方案為上圖所示。在antd中提供了全局的API，可以提前設定好所有的彈框的container，但是也不是每個元件庫都能像antd一樣完成度那麼高。
螞蟻所采用的解決方案是做動态的加載和解除安裝樣式表，如上圖所示，這種方案是很有效的。
對于JS隔離，螞蟻提出了JS Sandbox機制，如上圖所示，其中bootstrap、mount及unmount生命周期是子應用需要暴露出來的，因為子應用的整個生命周期都是被主應用所管理的，是以可以在主應用中給子應用插入各種攔截的機制，也可以捕獲到子應用在加載期間做了哪些全局上的修改。在unmount時，可以将全局上的副作用全部手動移除掉，同時也可以實作在重新進來時，将上次忘記解除安裝的副作用重建一遍，因為需要保證下次進來時能完整回複到與上次一緻的上下文。
對于資源加載問題，在微前端方案中存在一個典型的問題，如果子應用比較多，就會存在之間重複依賴的場景。解決方案是在主應用中主動的依賴基礎架構，然後子應用保守的将基礎的依賴處理掉，但是，這個機制裡存在一個問題，如果子應用中既有react15又有react16，這時主應用該如何做？螞蟻的方案是在主應用中維護一個語義化版本的映射表，在運作時分析目前的子應用，最後可以決定真實運作時真正的消費到哪一個基礎架構的版本，可以實作真正運作時的依賴系統，也能解決子應用多版本共存時依賴去從的問題，能確定最大程度的依賴複用。
對于應用之間資料共享及通信的問題，螞蟻提出了兩個原則，第一個原則是基于props以單向資料流的方式傳遞給子應用。第二個原則是基于浏覽器原生事件做跨業務之間的通信。
在真實的生産實踐中，螞蟻總結出了幾點經驗及建議：兄弟節點間通信以主應用作為消息總線，不建議自己封裝的Pub/Sub機制，也不推薦直接基于某一狀态管理庫做資料通信。
上圖所示為螞蟻在實踐中做的性能優化，包括異步樣式導緻閃爍問題的解決以及預加載問題的解決。
上圖所示為微前端方案涉及到的技術點，本文分享了圖中三分之二的内容。
在螞蟻金服做了大量關于微前端方案之後，總結了衡量一個微前端方案是否友好的兩個标準，第一個标準是技術無關，也是微前端最核心的特性，不論是子應用還是主應用都應該做到架構不感覺。第二個标準是接入友好，子應用接入應該像接入一個iframe一樣輕松自然。
螞蟻的微前端落地的實踐成果
螞蟻内部基于微前端基礎架構提出了一體化上雲解決方案，稱為OneX，是一個基礎的平台，它可以将各種流程和工具串聯，其價值展現在品牌、産品和技術方面。
品牌價值指的是統一的界面架構、UI、互動形成了螞蟻金服科技品牌心智。
上圖所示為螞蟻的一個真實應用的例子，除了中間接入的産品是自己控制之外，其他内容都是由平台提供，這樣，如論是一個三年陳項目還是新做的項目，在基本的視覺上可以做到統一。
産品價值指的是産品具有自由組合能力。之前的産品是多個産品、多個站點的控制台，而現在隻需要一個控制台，将多個産品自由的組合，這樣，可以在商業上有更多的相應空間以及更多自由的搭配。基于這樣的系統也可以做一些全局性的事情，例如埋點、使用者的轉化跟蹤業務。
技術價值指的是研發上的提效。經過微前端的改造後，螞蟻可以将大型的系統解耦成可以獨立開發的并行的小型的系統，這些小型系統可以交給别的團隊或者使用可視化的系統去實作，最後在運作時隻需要将他們內建起來。
在技術價值方面也可以實作傳遞上的提效，隻需要在某一個環境的任意一個環境中做平台上的接入，應用就可以做到在多餘的環境中不改代碼，直接運作。
上圖所示為阿裡雲剛上市的一個産品例子，其中包括15個來自不同團隊的應用進行維護，它的特點是并不是單獨為阿裡雲而設計的，之前在螞蟻也有運作，隻不過在阿裡雲中做了動态的組合。OneTour微應用元件主要解決的是在多個産品控制台之間自由切換導緻流程割裂的問題。
螞蟻微前端的落地成果包括：有70+線上應用接入（阿裡雲+螞蟻雲+專有雲），最複雜一個控制台同時內建15個應用，并且有4+不同技術棧，以及開發到釋出上線全鍊路的自動化支援，一雲入駐多雲運作。
螞蟻也熱衷于分享技術上的成果，包括微前端核心的開源、umi插件。上圖所示為qiankun方案，是與架構無關的微前端核心，umi-plugin-qiankun是基于umi應用提供的一個插件，如果是umi應用，就可以通過內建插件和更改配置成為微前端應用。基于上述實踐的檢驗和内部的實踐結果來看，在大規模中背景應用場景下，微前端架構是一個值得嘗試的方案。
關注「Alibaba F2E」
把握阿裡巴巴前端新動向