系統的組織在不斷變化的同時，其設計和架構也在不斷地調整。
如同數據庫的分庫分表一樣，既然一個組織的部門已經過於龐大，就進一步將它細化。
軟件的不同部分又被拆分到不同的部門之下。
隨着不同部門的業務發展，技術棧越來越難統一，出現了多樣化。
在走向多樣化后，用戶越來越厭倦一家公司的應用軟件分散在多個不同應用上。
應用的獲客成本越來越高，應用又一次走向聚合。
在分離了前后端之后，拆分降低了系統的復雜度，並進一步提高了軟件的開發效率。
隨着業務不斷擴張，需求也不斷擴張，應用又開始變得臃腫。
既然應用變大了，我們就繼續往下拆分，拆分成更小的單位。
-----摘選自《前端架構 從入門到微前端》
“任何物體在沒有接受外界能量的條件下，總是朝着熵增（無序）的方向變化。”
分庫分表，前后端分離，聚合，拆分到粒度更小的單位等軟件架構解決方案，解決的核心問題是，熵減。
應用臃腫，管理成本增加，獲客成本增加，組織臃腫等表現形式，表現形式的本質是，熵增。
總的來說，“微前端”這個名詞，以及它所帶來的一系列策略。都是為了解決軟件和組織在某一階段的，熵增的問題。
一、微前端架構
特點
- 應用自治
- 單一職責
- 技術棧無關
為什么需要
- 遺留系統遷移
- 后端解耦，前端聚合
- 熱鬧驅動開發
技術拆分方式
- 路由分發式
- 前端微服務化。不同框架之上設計通信和加載機制，以在一個頁面內加載對應應用。
- 微應用。軟件工程方式，在部署構建環境中，把多個獨立的應用組合成一個單體應用。
- 微件化。開發一個新的構建系統，將部分業務功能構建成一個獨立的chunk代碼，使用時只需遠程加載。
- 前端容器化。將iframe作為容器來容納其他前端應用。
- 應用組件化內。借助Web Components技術，來構建跨框架的前端應用。
說明：
①微件（Widget），flutter框架作為移動端的解決方案，就是微件化的實踐之一。
②Web component技術的推廣受限於瀏覽器的支持程度。
微前端架構設計
- 組件與模式庫
- 應用通信機制
- 數據共享機制
- 專用的構建系統（可選）
架構模式
- 基座模式
- 自組織模式
設計理念
- 中心化：應用注冊表
- 標識化應用
- 應用生命周期管理（微前端框架Single-SPA的基本生命周期，load->bootstrap->mount->unload->unmount）
- 高內聚，低耦合
微架構
- 后端拆分。微服務。
- App拆分。App存在多種容器，有插件化、組件化、小程序等不同的方案。
- 前端拆分。前端微服務、微應用化、微件化等。（前端走向微前端架構的原因，除了龐大的單體應用，還有一部分是要聚合舊的遺留系統）
二、實戰篇-前端微服務化
緣起：
- 注冊表。應用可以自動加載、運行，並能夠與應用注冊表進行聯系
- 完全隔離。每個應用的開發是完全隔離的，開發時互不影響。它可以接入某個框架，以更好地支持構建
適用性：
- 應用地掛載DOM節點
- 應用的服務地址
- 應用的唯一標識符
- 應用的名稱
- 應用所需要加載的腳本文件
設計方案：
- 通用型微前端方案 Single-SPA
- 定制型微前端方案 Mooa
說明：
①Single-SPA官網https://single-spa.js.org/docs/examples/
②Single-SPA參考GitHub-https://github.com/single-spa/single-spa