vivo 網際網路前端團隊- Jiang Zuohan
一、背景
VAPD是一款專為團隊協作辦公場景設計的項目管理工具，實踐靈活開發與持續傳遞，以「項目」為核心，融合需求、任務、缺陷等應用，使用靈活疊代、小步快跑的方式進行開發及品質跟蹤，簡化工作流程，幫助團隊快速疊代并高效完成産品開發傳遞。
但早期VAPD以“一切皆可配置”的設計理念開發運作了兩年，整個前端代碼複雜混亂，元件龐大（需要支援多種配置），狀态混亂，前端代碼打包出來有50M之巨。這個項目難以為繼，bug多、維護困難、新增功能處處受限，總之産品不滿意、測試不滿意、使用者不滿意。
是以改版是必然的選擇，而改版的要求就是不能耽誤使用者繼續使用，必須保證網站可用、逐漸更新，是以微前端是必然的選擇。
VAPD改版思路就是：
- 使用微前端架構，未改版部分作為子應用存在，繼續為使用者服務；
- 将項目子產品制定系統應用，并逐個改版，降低項目複雜度；
- 逐漸舍棄舊項目代碼，将功能轉移到新項目中，提升項目整體性能，提高代碼可維護性。
二、什麼是微前端
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. —— Micro Frontends.
微前端是一種多個團隊通過獨立釋出功能的方式來共同建構現代化 web 應用的技術手段及方法政策。
微前端将微服務的理念應用于浏覽器端，即将單頁面前端應用由單一的單體應用轉變為把多個小型前端應用聚合為一的應用，各個前端應用獨立開發、獨立部署。
微前端架構旨在解決單體應用在一個相對長的時間跨度下，由于參與的人員、團隊的增多、變遷，從一個普通應用演變成一個巨石應用(Frontend Monolith)後，随之而來的應用不可維護的問題。這類問題在企業級 Web 應用中尤其常見。
現行最出名的微前端是阿裡的qiankun，qiankun 是一個基于 single-spa 的微前端實作庫，旨在幫助大家能更簡單、無痛的建構一個生産可用微前端架構系統。
但我嘗試試用qiankun後發現qiankun 的npm包常常滞後于qiankun源碼，有些issue解決了但還要等待其發版；首次加載子應用頁面出現抖動；子應用更新後報 ChunkLoadError 問題 。
同時它存在微前端架構常有的性能問題及沖突問題：
1、加載慢
基本上所有的微前端架構都需要先加載父架構，再加載子應用，都要經曆如下圖的流程。整個流程是串行的，相同流程需要走兩遍，也就比普通的非微前端架構要慢1倍左右，直接影響了使用者體驗。
2、切換慢，每次切換都要重新走一次流程
微前端架構中不同子應用切換，需要銷毀目前子應用，然後加載其他子應用。子應用又需要進行“下載下傳html --> 下載下傳javascript檔案 --> 運作javascript代碼 --> 請求服務端資料 --> 頁面展示"整個流程，導緻微前端架構切換應用卡頓不流暢。
3、容易出現樣式沖突，不同子應用容易影響
傳統微前端架構中所有子應用都在同一上下文中，如出現全局樣式、全局監聽、全局變量，便會對其他子應用有影響，容易出現樣式沖突，記憶體洩漏，或者不可預知的bug。
三、Why Not Iframe
iframe 最大的特性就是提供了浏覽器原生的硬隔離方案，不論是樣式隔離、JS隔離這類問題統統都能被完美解決。
那為啥不使用iframe呢？
qiankun 團隊也給出了原因：看這裡 Why Not Iframe。
總結起來就是：
- url 不同步。浏覽器重新整理 iframe url 狀态丢失、後退前進按鈕無法使用。
- UI 不同步，DOM 結構不共享。想象一下螢幕右下角 1/4 的 iframe 裡來一個帶遮罩層的彈框，同時我們要求這個彈框要浏覽器居中顯示，還要浏覽器 resize 時自動居中..
- 全局上下文完全隔離，記憶體變量不共享。iframe 内外系統的通信、資料同步等需求，主應用的 cookie 要透傳到根域名都不同的子應用中實作免登效果。
- 慢。每次子應用進入都是一次浏覽器上下文重建、資源重新加載的過程。
其中有的問題比較好解決(問題1)，有的問題我們可以睜一隻眼閉一隻眼(問題4)，但有的問題我們則很難解決(問題3)甚至無法解決(問題2)，而這些無法解決的問題恰恰又會給産品帶來非常嚴重的體驗問題， 最終導緻我們舍棄了 iframe 方案。
四、擎天架構設計
4.1 設計理論
基于以上微前端缺陷，設計新型的微前端架構需要滿足以下要求：
- 快 —— 頁面加載速度、應用切換速度是前端極緻的追求，使用者操作的響應速度永遠是第一體驗。
- 完全隔離—— 不同子應用完全隔離，隻在子應用項目初始化時設定一次，之後不需要在後續開發中及後期維護中考慮，降低開發的心智負擔。
4.2 架構設計
擎天架構架構分為三層，分别是使用者入口（浏覽器位址欄），主應用層以及子應用集合層。
（1）浏覽器（位址欄）是使用者入口，使用者通過輸入URL進入該系統，同時浏覽器位址欄URL根據應用頁面進行變化，友善使用者複制分享二次進入。
（2）主應用是擎天架構的關鍵部分，主要是由以下兩部分組成：
- 路由引擎：實作浏覽器位址欄與子應用展示隐藏的協調控制，用來控制使用者第一次進入展示某個應用，當使用者切換頁面時需同步浏覽器位址欄（友善使用者複制，再次進入同一頁面），并根據頁面URL展示隐藏子應用。
- 資料共享引擎：實作子應用間的資料共享，保證各個應用間資料統一，如登入資訊，使用者資訊等。使用者在某個應用修改共享資料後，會同步到資料共享引擎，再分發給其他應用，進而保證共享資料一緻。
（3）子應用集合層
該層為系統提前設定好的子應用集合，子應用由全屏iframe加載，同一時刻僅有一個子應用處于可視狀态，其他子應用隐藏。當需要應用切換時，隐藏目前應用，顯示需要展示的應用，瞬間切換。
子應用響應擎天的路由引擎及資料共享引擎，做到實時的路由同步與資料同步，保證整個微前端項目路由及資料統一。
五、擎天架構實作
擎天架構突破了 iframe UI不同步、URL不同步、資料不共享以及加載慢等問題，并将iframe作為頁面容器存在，在實作硬隔離的同時做到了子應用瞬間切換，解決了微前端架構一直以來的通病，進而實作單應用級别的操作體驗。
5.1全屏iframe、共同元件
解決問題：UI 不同步
全屏iframe是指整個浏覽器視窗全部給子應用iframe，子應用接管浏覽器所有功能，無論是全局拖動、全部蒙層、resizie等，由此UI不同步的問題便不存在了。
但不同應用有個相同的公用部分，是以需要把公共部分做成統一元件，發到npm包中，在每一個應用中引入就行。
5.2 父子應用異步加載
解決問題：加載慢
在前端靜态頁面中預留子應用dom節點，如下圖 所示，每一個div有唯一id，代表一個預制子應用。同時該id對應子應用路由pathname，如New對應/New/*路由，即以New開頭的路由全部對應id為"New"的子應用。
當使用者進入頁面後，父架構拿到浏覽器url，并擷取到pathname，進而知道需要首先加載那個子應用。并且直接建立iframe，并直接挂到對應的dom節點中，父應用和子應用異步加載。
加載完首個子應用後，開始加載其他子應用，并使用display: none将它們隐藏到頁面dom結構中。最終dom節點如下圖所示。
5.3 子應用iframe瞬間切換
解決問題：子應用切換卡頓
使用者進行多個子應用切換時，擎天架構監聽浏覽器url位址，如pathname從/New/*變成/Web/*，則将/New/*對應的子應用iframe隐藏起來，将/Web/對應的子應用iframe顯示出來，實作應用的瞬間切換。
使用者可視範圍内隻能看一個應用，切換時僅僅是将New應用隐藏不可見，Web應用頁面可見。
5.4 路由引擎，同步切換
解決方案：URL不同步
受vue2中數組方法（如push、shift）響應式處理的啟發，擎天對前端路由架構進行特殊處理，重寫了vue-router的push、replace等方法，當監聽到子應用使用以上方法進行路由切換時，會同步到父架構進行操作。
父子應用簡單配置後，父子路由同步便做好了。路由切換分為單應用以及多應用間路由切換。
（1）單應用路由切換
單應用子iframe路由切換，如/New/b 切換到/New/c，其pathname結構一緻，是單應用的路由切換。子應用先切換路由，随後發送syncRoute給父架構，父架構使用replace方法改變浏覽器位址欄即可，具體流程如下圖所示。
（2）多應用間路由切換
如/New/b 切換到/Web/c，其pathname結構不一緻。子應用先切換路由，随後發送syncRoute消息給父架構，父架構使用replace方法改變浏覽器位址欄，同時将應用A隐藏起來，并發送消息到子應用B中。子應用B獲得消息後修改其本身路由。
5.5 資料共享
解決問題：記憶體變量不共享
父應用将需要共享的資料放到store中，并使用syncStore進行注冊。
子應用通過類vuex似的 mapGlobalState 方法可以擷取父應用store中資料，同時該資料為響應式，資料變更可觸發UI重新渲染。
通過mapGlobalMutations擷取修改資料的方法，通過該方法可以修改父應用store資料，修改成功後擎天共享資料引擎将修改好的資料分發給各個子應用，保證共享資料一緻。
其内部邏輯是：
父應用将需要共享的資料放到store中，并暴露getTopStore（擷取store資料）、syncTopMutation(更新store資料)、syncTopStore(分發store資料)等接口。
系統加載時子應用通過getTopStore方法可以擷取store中資料，并指派到子應用$pstore中，進而獲得資料響應式等能力。