前言
其實在小企業裏，我對微前端的概念一直很模糊，接觸不到，所以只是一種概念性的認知，在這裏記錄下最近看的一篇文章總結。
微前端架構：旨在解決單體應用在一個相對長的時間跨度下，由於參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用(Frontend Monolith)，隨之而來的應用不可維護的問題。這類問題在企業級 Web 應用中尤爲常見。
微前端要解決的問題
搞微前端目的就是要將產品原子化，由龐大的應用體系拆分爲多個模塊，再根據客戶業務場景進行組合。每個功能模塊能單獨迭代，自由集成。
明確一點：
微前端不是框架，不是工具/庫，而是一套架構體系，它包括若干庫，工具，中心化的治理平臺及相關配套設施
- 微前端包括3個部分：
- 微前端的基礎設施，這是目前討論最多的，一個微應用如何通過一個組件基座加載進來，腳手架工具，怎麼單獨構建和部署，怎麼聯調。
- 微前端配置中心：標準化的配置文件格式，支持灰度，回滾，紅藍，A/B等發佈策略
- 微前端的可觀察性工具：對於 任何分佈式特點的架構，線上/線下治理都很重要。
具體要解決好的10個問題：
- 微應用的註冊、異步加載和生命週期管理；
- 微應用之間、主從之間的消息機制；
- 微應用之間的安全隔離措施；
- 微應用的框架無關、版本無關；
- 微應用之間、主從之間的公共依賴的庫、業務邏輯(utils)以及版本怎麼管理；
- 微應用獨立調試、和主應用聯調的方式，快速定位報錯（發射問題）；
- 微應用的發佈流程；
- 微應用打包優化問題；
- 微應用專有云場景的出包方案；
- 漸進式升級：用微應用方案平滑重構老項目
基本原理
盜圖如下：
傳統項目管理工具通常是命令行工具，包括構建、發佈、測試，會升級爲項目工作臺，通過 Web 界面管理項目。一個項目包括哪些微應用，版本，發佈策略等在配置中心統一管理。一個大型應用被「碎片化」後，還要能做到「一目瞭然」。哪個模塊報錯，加載失敗等異常發生第一時間反應在配置中心裏