使用 Microservices 架構設計系統的優勢解析
從單體架構（Monolith）開始理解
在談 microservices 之前，我們先從最常見的「單體架構（Monolithic Architecture）」開始。
在單體架構中，整個系統會被寫成一個完整的應用程式。無論是使用者登入、訂單處理、支付流程，還是通知服務，全部都在同一個 codebase 中運作。這種設計在專案初期非常直覺，也容易開發與部署。
然而，當系統逐漸變大時，問題就會開始浮現。任何一個小改動，都可能影響整個系統；部署一次就必須整體更新；團隊之間的協作也容易互相干擾。這些限制，正是 microservices 架構誕生背後的動力。
什麼是 Microservices 架構？
例如，一個電商系統可以被拆成：
- 使用者服務（User Service）
- 商品服務（Product Service）
- 訂單服務（Order Service）
- 支付服務（Payment Service）
這些服務之間通常透過 HTTP API 或 message queue（例如 Kafka）來進行溝通，而不是直接呼叫內部 function。
從架構的角度來看，它會比較像這樣：
Client
↓
API Gateway
↓
┌───────────────┬───────────────┬───────────────┐
│ User Service │ Order Service │ Payment Service│
└───────────────┴───────────────┴───────────────┘
這種設計讓系統從「一個巨大應用」轉變為「多個協作的小系統」。
為什麼要使用 Microservices？
接下來我們從幾個核心面向來理解 microservices 的優勢，而這些優勢通常會在系統規模變大後變得非常關鍵。
一、系統可以獨立擴展（Scalability）
在單體架構中，如果系統某一部分（例如訂單服務）流量暴增，你通常只能「整個系統一起擴展」。
但在 microservices 架構中，你可以只針對「需要的服務」進行擴展。例如：
- 訂單服務流量高 → 只增加 Order Service 的 instances
- 使用者服務穩定 → 不需要額外資源
這種「細粒度擴展」可以有效降低成本，並提升資源使用效率。常搭配 Kubernetes 等容器編排平台來實作。
二、服務之間解耦（Decoupling）
Microservices 的核心精神之一是「高內聚、低耦合」。
每個服務只關心自己的業務邏輯，例如：
- User Service 不需要知道 Payment 的內部實作。
- Order Service 只需要呼叫 Payment API，而不是直接操作其資料庫。
這樣的好處是：
- 修改某個服務，不會影響其他服務。
- 可以降低系統的複雜度傳播（complexity propagation）。
三、可以使用不同技術棧（Polyglot Architecture）
在單體架構中，你通常會被限制使用同一種語言與框架。
但在 microservices 架構中，每個服務可以根據需求選擇最適合的技術：
- 高併發 API → 使用 Go
- 資料分析 → 使用 Python
- 即時通訊 → 使用 Node.js
這種「技術多樣性」讓團隊可以針對不同問題選擇最佳解。
四、部署更靈活（Independent Deployment）
在 microservices 架構中，每個服務都可以獨立部署。
這代表：
- 修正 Payment bug，不需要重新部署整個系統。
- 可以針對單一服務做 rollback。
- 支援 CI/CD pipeline 的細粒度發布。
五、系統更具容錯能力（Fault Isolation）
在單體架構中，一個模組出錯，可能會導致整個系統崩潰。
但在 microservices 中：
- Payment Service 掛掉 → 不影響 User Service。
- 某個 API timeout → 可以 fallback 或 retry。
這種「故障隔離（Fault Isolation）」讓系統更穩定，也更容易設計 resiliency 機制（如 circuit breaker）。
六、團隊可以並行開發（Team Scalability）
當系統拆分成多個服務後，團隊也可以依照服務來分工。每個團隊可以獨立開發、獨立部署，並擁有自己的 release cycle。這會大幅提升開發效率，並降低跨團隊溝通成本。
Microservices 的代價
也就是說，microservices 解決了「系統規模問題」，但引入了「系統複雜度問題」。
什麼時候適合使用 Microservices？
你可以用一個簡單的判斷原則：
如果你的系統還很小，請先使用 Monolith。
如果你的系統已經開始出現 scaling、部署、團隊協作問題，再考慮 microservices。
很多成功公司都是從 monolith 開始，逐步演進到 microservices，而不是一開始就採用。
總結
Microservices 架構的核心價值，在於將一個大型系統拆分為多個可獨立運作的小服務。這種設計帶來了更好的擴展性、部署彈性、技術自由度與團隊協作效率。但同時，它也會引入分散式系統的複雜性。
因此，是否採用 microservices，應基於你的系統規模、團隊結構與實際需求來做出判斷。