微前端總結

微前端概述

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

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

常用微前端方案：

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隔離來實現微應用的載入，所以子應用無需改動就可以接入
• 支持應用隔離
• 通過劫持底層介面實現了元素隔離
• 提供了插件系統
• 支持預載入
• 沒有考慮工程化問題：如公用依賴，組件復用
• 沒有考慮到微前端平臺運維
• 不支持vite3

成本：

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

風險：

• 這個框架基於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個。
• 子應用首先需要做支持跨域請求改造，這個是所有微前端框架運行的前提。