1、什么是微前端
微前端是一種架構風格，其中眾多獨立交付的前端應用組合成一個大型整體，
將前端應用分解成一些更小、更簡單的能夠獨立開發、測驗、部署的小塊，而在用戶看來仍然是內聚的單個產品——這樣的一個架構思想稱為【微前端】，
2、為什么要提出微前端
任何新技術的產生都是為了解決現有場景和需求下的技術痛點，
微服務所解決的痛點：
- 拆分與解耦
目前，單頁面應用（SPA）是非常流行的專案形態之一，隨著業務的拓展以及應用功能的豐富，單頁面應用變得不再單一而是越來越龐大也越來越難以維護，往往是改一處而動全身，由此帶來的打包、發版成本也越來越高，
微前端的意義就是將這些龐大的應用進行拆分，并隨之解耦，每個部門可以單獨進行維護和部署，提升效率，
- 整合歷史系統
在不少業務中，或多或少會存在一些歷史專案，也沒有足夠的精力和膽量去升級重構，
微前端可以對老舊專案進行少量代碼修改之后，將老舊專案整合到新的專案應用中，
3、微前端的特點
微前端的優點
- 獨立開發部署，加快編譯、打包速度
- 減少首屏加載內容，增加首屏加載速度
- 應用自治
只需要遵循統一的介面規范或者框架，以便系統集成到一起，相互之間是不存在依賴關系的，
- 單一職責
每個前端應用可以只關注于自己所需要完成的功能，
- 技術堆疊無關
每個模塊之間使用的技術堆疊都不相互影響，可以使用不同的技術堆疊
微前端的缺點
- 開發體驗不太友好
- 使用多種的技術堆疊：依賴復雜，管理成本高
- 相對與SPA體驗有折損
4、微前端的方案
架構模式
- 基座模式：通過一個主應用，來管理其它應用，設計難度小，方便實踐，但是通用度低，
- 自組織模式：應用之間是平等的，不存在相互管理的模式，設計難度大，不方便實施，但是通用度高，
技術方案
| 方案 | 描述 | 優點 | 缺點 |
|---|---|---|---|
| Nginx路由轉發 | Nginx配置反向代理來實作不同路徑映射到不同應用，例如www.abc.com/app1 對應app1，www.abc.com/app2 對應app2，這種方案本身并不屬于前端層面的改造，更多的是運維的配置 | 簡單，快速，易配置 | 在切換應用時會觸發瀏覽器重繪，影響體驗 |
| iframe嵌套 | 父應用單獨是一個頁面，每個子應用嵌套一個iframe，父子通信可采用postMessage或者contentWindow方式 | 實作簡單，子應用之間自帶沙箱，天然隔離，互不影響 | iframe的樣式顯示、兼容性等都具有局限性；太過簡單而顯得low |
| Web Components | 每個子應用需要采用純Web Components技術撰寫組件，是一套全新的開發模式 | 每個子應用擁有獨立的script和css，也可單獨部署 | 對于歷史系統改造成本高，子應用通信較為復雜易踩坑 |
| 組合式應用路由分發 | 每個子應用獨立構建和部署，運行時由父應用來進行路由管理，應用加載，啟動，卸載，以及通信機制 | 純前端改造，體驗良好，可無感知切換，子應用相互隔離 | 需要設計和開發，由于父子應用處于同一頁面運行，需要解決子應用的樣式沖突，變數物件污染，通信機制等技術點 |
微前端拆分方式
- 按照業務拆分
- 按照權限拆分
- 按照變更的頻率拆分
- 按照組織結構拆分
- 跟隨后端微服務劃分
5、微前端的難點
- 資源的隔離：由于存在不同應用各自定義CSS和全域變數的情況，應用聚合時需要考慮彼此之間的影響，應用JS沙箱和CSS隔離等相關技術，使各應用之間互不影響，
- 應用的注冊：Html Entry 和 Config Entry，是關于如何注冊子應用資訊，
- 對性能的影響：按需加載、公共依賴加載和預加載，是關于性能的，這些很重要，否則雖然上了微前端，但性能嚴重下降，或者由于升級引起線上故障，就得不償失了，
- 應用間通信：父子應用通訊，顧名思義，無需解釋，
- 應用嵌套/并行：子應用嵌套 和 子應用并行 是微前端的進階應用，在某些場景下會用到，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/233616.html
標籤：其他