微前端總結

微前端概述

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

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

常用微前端方案：

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

標籤：其他

上一篇：超強的純 CSS 滑鼠點擊拖拽效果

下一篇：基于elementUi + Vxe + Echarts 二次封裝業務組件庫，commonUtils方法呼叫