簡介
微前端將微服務的概念擴展到前端：將Web應用程式劃分為小部分，每個部分都由團隊獨立擁有、開發和部署。本文解釋了為什麼需要微前端以及何時應該（或不應該）使用它。
1.什麼是微前端？
1.1 定義
“一種架構風格，其中可獨立交付的前端應用程式被組合成一個更大的整體。” — 卡姆·傑克遜，馬丁·福勒博客
Monolith Frontend: Micro Frontend:
┌─────────────────────────┐ ┌─────────────────────────┐
│ Single SPA │ │ Shell Application │
│ ┌─────────────────────┐ │ │ ┌──────┐ ┌──────┐ ┌──┐ │
│ │ Header │ │ │ │Shared│ │Shared│ │ │ │
│ ├──────┬──────┬───────┤ │ │ │Header│ │Footer│ │ │ │
│ │Produ-│ Cart │ Order │ │ │ └──────┘ └──────┘ │ │ │
│ │cts │ │ │ │ │ ┌──────┐ ┌──────┐ │ │ │
│ │ │ │ │ │ ──► │ │Produc│ │ Cart │ │Or│ │
│ │ │ │ │ │ │ │t MFE │ │ MFE │ │de│ │
│ │ │ │ │ │ │ │Team A│ │Team B│ │rC│ │
│ ├──────┴──────┴───────┤ │ │ └──────┘ └──────┘ └──┘ │
│ │ Footer │ │ │ Deploy Deploy De │
│ └─────────────────────┘ │ │ riêng riêng ploy │
└─────────────────────────┘ └─────────────────────────┘
1 team, 1 repo, 1 deploy N teams, N repos, N deploys
1.2 微前端與元件庫
| 元件庫 | 微前端 | |
|---|---|---|
| 部署 | 相同的應用程式主機 | 獨立 |
| 團隊所有權 | 共享 | 敬業的團隊 |
| 技術堆疊 | 類似 | 可以不同 |
| 運行時載入 | 建置時 | 運行時 |
| 資料/狀態 | 記憶體共享 | 隔離 |
2. 為什麼我們需要微前端？
2.1 實際問題
您有 5 個團隊 致力於 1 個整體 SPA：
- 持續的 PR 衝突（500 多個元件，共享狀態）
- 長合併佇列→每週部署一次
- 一個團隊想要升級 React 18，但需要遷移整個應用程式
- 產品頁面上的錯誤→回滾整個應用程式（購物車、訂單也受到影響）
→ 微前端解決了組織規模問題。
2.2 主要好處
| 好處 | 描述 |
|---|---|
| 獨立部署 | 在不影響購物車的情況下發送產品頁面 |
| 團隊自治 | 每個團隊都有端對端（UI → BFF → Service） |
| 技術彈性 | A 團隊使用 React，B 團隊使用 Vue（如有必要） |
| 增量升級 | 升級每個MFE，無需大爆炸 |
| 故障隔離 | MFE A 中的錯誤不會導致 MFE B 崩潰 |
| 更快的發展 | 更小的程式碼庫 = 更快的建置、測試、部署 |
3. 權衡與挑戰
3.1 當微前端不適合時
- 小團隊（< 5 位開發人員）：與收益相比，開銷太大
- 簡單的應用程式：登陸頁面、部落格、簡單的儀表板
- 緊密的使用者體驗耦合：應用程式需要零件之間的無縫使用者體驗
- 效能關鍵：增加運行時開銷（載入、開機）
3.2 複雜性成本
Micro Frontend thêm complexity:
├── Infrastructure: CI/CD cho nhiều apps
├── Shared dependencies: versioning hell
├── UX Consistency: design system bắt buộc
├── Communication: cross-MFE events
├── Performance: bundle size, load time
├── Testing: integration testing across MFEs
└── Developer Experience: local dev setup phức tạp
4. 決策框架
Bạn nên dùng Micro Frontend khi:
✅ Team size: 15+ frontend developers
✅ Multiple teams working on same app
✅ Deploy frequency: team muốn deploy độc lập
✅ App complexity: 10+ distinct features/pages
✅ Tech migration: cần incremental migration
❌ Skip Micro Frontend khi:
❌ Team < 5 developers
❌ Single team, shared ownership
❌ App chưa đủ phức tạp
❌ Performance là yếu tố quyết định
❌ Team chưa có experience với Microservices
總結
微前端不是靈丹妙藥－它解決了組織規模問題。如果您沒有這個問題，就不要造成不必要的複雜性。
下一篇文章： 第 11 課：微前端整合策略 - 建置時與運行時