微前端總結

微前端概述

　　微前端概念是從微服務概念擴充套件而來的，摒棄大型單體方式，將前端整體分解為小而簡單的塊，這些塊可以獨立開發、測試和部署，同時仍然聚合為一個產品出現在客戶面前。可以理解微前端是一種將多個可獨立交付的小型前端應用聚合為一個整體的架構風格。

　　微前端不是一門具體的技術，而是整合了技術、策略和方法，可能會以腳手架、輔助外掛和規範約束這種生態圈形式展示出來，是一種宏觀上的架構。這種架構目前有多種方案，都有利弊之處，但只要適用當前業務場景的就是好方案。

常用微前端方案：

1. iframe
2. single-spa
3. qiankun 基於 single-spa 方案實現, 更強大更易上手
4. webpack5 ModuleFederationPlugin（EMP）
5. microApp
6. wujie-micro

　　single-spa太過於基礎，對原有專案的改造過多，成本太高； iframe在所有微前端方案中是最穩定的、上手難度最低的，但它有一些無法解決的問題，例如效能低、通訊複雜、雙卷軸、彈窗無法全域性覆蓋，它的成長性不高，只適合簡單的頁面渲染。剩下的只有qiankun、microApp和wujie-micro了。

qiankun

　　乾坤微前端架構則進一步對single-spa方案進行完善，主要的完善點：

• • 子應用資源由 js 列表修改進為一個url，大大減輕註冊子應用的複雜度
  • 實現應用隔離，完成js隔離方案 （window工廠） 和css隔離方案 （類vue的scoped）
  • 增加資源預載入能力，預先子應用html、js、css資源快取下來，加快子應用的開啟速度

　　總結一下方案的優缺點：

優點

• • 監聽路由自動的載入、解除安裝當前路由對應的子應用
  • 完備的沙箱方案，js沙箱做了SnapshotSandbox、LegacySandbox、ProxySandbox三套漸進增強方案，css沙箱做了兩套strictStyleIsolation、experimentalStyleIsolation兩套適用不同場景的方案
  • 路由保持，瀏覽器重新整理、前進、後退，都可以作用到子應用
  • 應用間通訊簡單，全域性注入

缺點

• • 基於路由匹配，無法同時啟用多個子應用，也不支援子應用保活
  • 改造成本較大，從 webpack、程式碼、路由等等都要做一系列的適配
  • css 沙箱無法絕對的隔離，js 沙箱在某些場景下執行效能下降嚴重
  • 無法支援 vite 等 ESM 指令碼執行

成本上：

• • 接入成本：子應用需要接入生命週期程式碼；主應用需要接入註冊微應用程式碼；
  • 改造成本：需要自己考慮微前端工程化問題，以及微前端平臺運維。

風險上：

• • 社群活躍度：github star 數量 13.4k （統計時間2022-10-09）
  • 檔案齊全，demo多

micro-app

　　京東1年前出品，官網地址：https://micro-zoe.github.io/micro-app/

功能上：

• • 拋棄了路由劫持的思路，選用類web component的方案
  • 基於CustomElement和樣式隔離、js隔離來實現微應用的載入，所以子應用無需改動就可以接入
  • 支援應用隔離
  • 通過劫持底層介面實現了元素隔離
  • 提供了外掛系統
  • 支援預載入
  • 沒有考慮工程化問題：如公用依賴，元件複用
  • 沒有考慮到微前端平臺運維
  • 不支援vite

成本：

• • 接入成本：子應用無需改動，主應用需要接入微應用程式碼
  • 改造成本：需要自己考慮微前端工程化問題，以及微前端平臺運維。

風險：

• • 這個框架基於CustomElement和Proxy API，前者針對低版本有polyfill，但後者沒有，且目前官方檔案說沒有做相容的計劃
  • 社群活躍度 star 3.5k（統計時間2022-10-09）
  • 檔案齊全

wujie

　　騰訊今年7月份出品，官網地址：https://wujie-micro.github.io/doc/guide/start.html。

功能上：

• • 支援vite
  • 多應用同時啟用線上
  • 框架具備同時啟用多應用，並保持這些應用路由同步的能力
  • 元件式的使用方式
  • 無需註冊，更無需路由適配，在元件內使用，跟隨元件裝載、解除安裝
  • 應用級別的 keep-alive
  • 子應用開啟保活模式後，應用發生切換時整個子應用的狀態可以儲存下來不丟失，結合預執行模式可以獲得類似ssr的開啟體驗
  • 純淨無汙染
  • 無界利用iframe和webcomponent來搭建天然的js隔離沙箱和css隔離沙箱
  • 利用iframe的history和主應用的history在同一個top-level browsing context來搭建天然的路由同步機制
  • 副作用侷限在沙箱內部，子應用切換無需任何清理工作，沒有額外的切換成本
  • 效能和體積兼具
  • 子應用執行效能和原生一致，子應用範例instance執行在iframe的window上下文中，避免with(proxyWindow){code}這樣指定程式碼執行上下文導致的效能下降，但是多了範例化iframe的一次性的開銷，可以通過 proload 提前範例化
  • 體積比較輕量，藉助iframe和webcomponent來實現沙箱，有效的減小了程式碼量

成本：

• • 開箱即用
  • 不管是樣式的相容、路由的處理、彈窗的處理、熱更新的載入，子應用完成接入即可開箱即用無需額外處理，應用接入成本也極低

風險：

• • 太新了，今年7月份才釋出
  • 社群活躍度 star 1.7k（統計時間2022-10-09）
  • 檔案齊全

微前端總結

　　qiankun 方案對 single-spa 微前端方案做了較大的提升同時也遺留下來了不少問題長時間沒有解決； micro-app 方案對 qiankun 方案做了較多提升但基於 qiankun 的沙箱也相應會繼承其存在的問題； EMP 方案基於 webpack 5 聯邦編譯則約束了其使用範圍； 目前的微前端方案在使用者的核心訴求上都沒有很好的滿足，有很大的優化提升空間。

正常的一些輕量業務，是沒有必要引入微前端的概念，這樣只會自找麻煩，只有在業務觸及了巨石應用範疇，給開發人員帶來困擾的時候，才需要引入，以便解決一下通用問題，並保證具備以下能力：

1. 自主的團隊，維護著各團隊解耦的程式碼庫；
2. 獨立部署：各團隊可以獨立部署；
3. 同步更新：各團隊各業務功能升級後，整體應用能夠同步更新；
4. 增量升級：做到不修改歷史包袱的情況下，進行逐步的更新；

　　適合的業務場景：

• • 前端巨石工程：業務越來越複雜，許多複雜需求堆積在一個工程裡，部署、debug、擴充套件過於困難，單個模組的重構成本大。
  • 前端碎石工程：不同專案之間的依賴維護成本巨大、專案之間的跳轉體驗糟糕。

　　具體什麼樣的情形適合使用微前端？

1. 技術棧切換又不想重構已有業務的，例如增量升級，就是在保留原來專案部分的基礎上，新功能或者模組採用新技術來實現。
2. 歷史包袱專案，比如歷史專案內部強耦合，但是又執行穩定的。
3. 自己造的輪子的庫（與業務相關）需要複用在新專案中。
4. 舊專案的業務頁面會在新專案中複用，又迫於專案時間壓力的情況。

　　場景1：老專案使用的jquery，新專案使用的是vue，兩個專案都要共存。或者老專案是使用的jquery，突然要在老專案上開發新功能，jquery沒有什麼人用了，此時使用其他技術，例如vue開發新功能。

　　場景2：一個專案裡面的不同功能模組由不同的前端技術團隊在做，兩個前端團隊採用的是不同的技術棧，且各個團隊相對獨立，獨立倉庫、獨立部署、獨立構建。

　　當前排程專案採用微前端會面臨哪些問題？

• • 第三方依賴重複參照的問題，導致需要載入太多的資源
  • 元件如何複用的問題。每個應用都有自己開發的元件庫
  • 構建流水線增加，原先一條，現在要幾條，伺服器埠增加，之前是一個現在是幾個。
  • 程式碼倉庫增加，原先一個，現在N個。
  • 子應用首先需要做支援跨域請求改造，這個是所有微前端框架執行的前提。