簡介
大多數軟體系統都是從 Monolith 開始的——這是正確的。但隨著系統的成長、團隊的擴大、需求的不斷變化，Monolith架構逐漸成為瓶頸。本課程幫助您了解軟體架構演進的整個旅程，以及為什麼微服務 + 微前端是複雜系統的目的地。
1. Monolith — 合理的起點
1.1 什麼是單體架構？
Monolith 是一種架構，其中整個應用程式作為單一單元進行建置、部署和擴展。所有模組（使用者、產品、訂單...）在同一進程中運行，共享相同資料庫並一起部署。
1.2 整體式的優點
| 優勢 | 描述 |
|---|---|
| 簡單 | 易於開發、調試和初步測試 |
| 易於部署 | 只需部署 1 個工件 |
| 效能 | 在內部（進程內）而不是透過網路呼叫函數 |
| ACID 事務 | 輕鬆執行跨模組交易 |
| 易於重構 | 良好的IDE支持，輕鬆搜尋和重命名 |
1.3 Monolith什麼時候會成為問題？
隨著系統的成長，Monolith 遇到了瓶頸：
關於發展：
- 程式碼庫太大，新開發者需要大量時間來理解
- 建置時間增加到數十分鐘
- 合併團隊之間不斷發生的衝突
- 一個小錯誤可能會導致整個系統崩潰
關於部署：
- 只需進行 1 個小更改即可部署整個應用程式
- 發布週期持續（週/月）
- 回滾複雜，影響全面
關於縮放：
- 當只有一個模組需要更多資源時必須完全擴展
- 不能對每個部分使用不同的技術
經驗法則： 如果您少於 5 名開發人員且系統不太複雜，Monolith 仍然是最佳選擇。
2. 架構演進之旅
2.1 單體 → SOA → 微服務
Timeline:
2000s 2010s 2015+ 2020+
┌──────┐ ┌──────────┐ ┌──────────────┐ ┌───────────────────┐
│Monolith│ → │ SOA │ → │ Microservices│ → │ Microservices + │
│ │ │Services │ │ │ │ Micro Frontend │
└──────┘ └──────────┘ └──────────────┘ └───────────────────┘
2.2 SOA（服務導向的架構）
SOA 是將 Monolith 分開為服務的第一步。然而，SOA 有一些限制：
- 使用集中式 ESB（企業服務匯流排） → 單點故障
- 服務通常不是真正獨立的（共享資料庫、共享庫）
- 複雜協定（SOAP、WS-*）
2.3 微服務 — SOA 做得正確
微服務繼承了SOA思想，但具有核心原則：
┌──────────────────────────────────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────────┬─────────────────────┘
│ │ │
┌────┴────┐ ┌───┴────┐ ┌─────┴─────┐
│ User │ │Product │ │ Order │
│ Service │ │Service │ │ Service │
│ │ │ │ │ │
│ ┌─────┐ │ │┌─────┐ │ │ ┌──────┐ │
│ │ DB │ │ ││ DB │ │ │ │ DB │ │
│ └─────┘ │ │└─────┘ │ │ └──────┘ │
└─────────┘ └────────┘ └───────────┘
Mỗi service: Own database, Own deployment, Own team
比較 SOA 與微服務：
| 標準 | 服務導向架構 | 微服務 |
|---|---|---|
| 通訊 | ESB（集中式） | 智慧端點，啞管 |
| 資料 | 流行的共享資料庫 | 每個服務的資料庫 |
| 尺寸 | 可以很大 | 小而專注 |
| 部署 | 通常與 | 一起部署獨立部署 |
| 技術 | 通常是同質的 | 多語言 |
3. 前端整體－被忽略的問題
3.1 Backend已分離，Frontend仍合併
許多組織已在後端採用微服務，但前端仍然是一個巨大的 SPA 應用程式（React/Angular/Vue 單體應用）。
3.2 前端整體架構的後果
- 程式碼耦合：所有團隊都貢獻相同的前端儲存庫
- 技術鎖定：無法逐步升級框架
- 構建緩慢：捆綁包大小越來越大
- 部署瓶頸：必須部署整個前端
- 團隊依賴：團隊 A 等待團隊 B 合併程式碼
3.3 微前端—解決方案
┌─────────┐ ┌──────────┐ ┌─────────────┐
│ User │ │ Product │ │ Order │
│ MFE │ │ MFE │ │ MFE │
│ (React) │ │ (Vue) │ │ (React) │
└────┬────┘ └─────┬────┘ └──────┬──────┘
│ │ │
└─────────┬───┴──────────────┘
│
┌─────────┴──────────┐
│ SHELL / CONTAINER │
│ Application │
└────────┬────────────┘
│
┌─────────────┴────────────────────────┐
│ API GATEWAY │
└──────┬──────────┬──────────┬─────────┘
┌────┴────┐ ┌───┴────┐ ┌──┴────────┐
│User µS │ │Product │ │Order µS │
└─────────┘ └────────┘ └───────────┘
4. 什麼時候該切換？
4.1 訊號需要微服務
- 團隊 > 10 人 在同一程式碼庫上工作
- 發布被另一個團隊阻止
- 不均勻縮放：1 個模組需要縮放，但所有模組都必須縮放
- 技術鎖定：想要使用新技術但不能
- 級聯故障：1 個錯誤導致整個系統崩潰
4.2 訊號需要微前端
- 多個團隊在同一個前端應用程式上開發功能
- 前端建置時間 > 5 分鐘
- 頻繁合併衝突前端
- 想要升級框架但必須改變一切
- 每個 UI 部分獨立發布
4.3 什麼時候不應該這樣做？
**不要修復未損壞的東西。 **
- 小團隊（< 5 位開發人員）→ 整體就夠了
- MVP / Startup → 開發速度比架構更重要
- 系統簡單，改變很少 → 過度設計
- 團隊沒有足夠的 DevOps 經驗 → 微服務增加了營運複雜性
5.本系列概述
5.1 學習路線圖
Phần 1-3: Backend Foundation → DDD, Service Design, Data Architecture
Phần 4-5: Micro Frontend → Architecture, Implementation, Design System
Phần 6: Integration Layer → BFF, API Gateway, GraphQL Federation
Phần 7-8: Quality & Deploy → Testing, CI/CD, Deployment Strategies
Phần 9: Production → Observability, Performance, Readiness
Phần 10: Real World → Case Study, Migration Guide
5.2 跨領域項目
在整個系列中，我們將設計一個完整的電子商務平台：
- 5 個微服務：使用者、產品、購物車、訂單、付款
- 5 個微前端：主頁、產品詳細資料、購物車、結帳、帳戶
- 共享：設計系統、身份驗證、API 網關
總結
| 建築 | 何時使用 | 主要權衡 |
|---|---|---|
| 巨石 | 小型團隊、MVP、簡單系統 | 啟動容易，規模化難 |
| 微服務 | 團隊規模大，需要獨立擴展 | 使操作和數據複雜化 |
| 微前端 | FE團隊眾多，需要獨立部署 | 增加捆綁包大小，需要係統設計 |
| 全端（MS + MFE） | 組織龐大，產品複雜 | 需要高 DevOps 成熟度 |
閱讀更多
- Martin Fowler — Microservices
- Martin Fowler — Micro Frontends
- microservices.io — Pattern Language
- micro-frontends.org
下一篇文章： 第 2 課：領域驅動設計－系統分離思維