微服務（Microservices）是一種軟體架構風格，將單體應用程式拆分成多個小型、獨立部署的服務，每個服務專注單一業務功能，透過輕量級通訊協定（如 HTTP/REST、gRPC、訊息佇列）相互協作。它強調服務自治、技術異質性與獨立擴展，取代傳統單體架構，是雲端原生與 DevOps 的核心實踐。
微服務 vs 單體架構對比
傳統單體應用像一塊大石頭，所有功能緊密耦合：
單體：UI + 業務邏輯 + 資料庫 = 單一 WAR/JAR 檔案
優勢：開發簡單、部署容易
劣勢：規模大時難維護、單點故障、技術堆疊受限
微服務像樂高積木，鬆散耦合：
微服務：UserService + OrderService + PaymentService + NotificationService
優勢：獨立部署、技術自由、容錯性高
劣勢：分散式複雜性、網路延遲、資料一致性挑戰
微服務的核心原則（12 因素應用）
微服務遵循以下設計原則：
-
單一職責：每個服務僅負責一個業務功能
-
獨立部署：服務可無關他人影響而部署
-
API 優先：標準化 REST/gRPC 介面契約
-
資料主權：每個服務擁有獨立資料庫
-
自動化一切：CI/CD、容器化、基礎設施即程式碼
典型微服務架構圖
使用者請求 → API Gateway → 服務網格(Service Mesh)
↓
[UserSvc] → [OrderSvc] → [PaymentSvc] → [NotificationSvc]
↓
分散式追蹤 → 中央日誌 → 監控儀表板 → 告警系統
各元件職責：
-
API Gateway：統一入口、路由、認證、限流
-
Service Mesh：服務間通訊、觀測性、安全（Istio、Linkerd）
-
Service Discovery：動態服務註冊與發現（Consul、Eureka）
通訊模式分類
1. 同步通訊（Request-Response）
HTTP/REST：UserSvc GET /api/orders → OrderSvc 返回 JSON
gRPC：高性能二進位通訊，Google 開發
GraphQL：客戶端指定所需欄位
2. 非同步通訊（Event-Driven）
事件：OrderCreated → PaymentSvc、NotificationSvc 並行處理
工具：Kafka、RabbitMQ、NATS
優點：解耦、彈性擴展
資料管理策略
微服務面臨「分散式單體」陷阱，解決方案：
| 策略 | 原理 | 工具 |
|---|---|---|
| 資料庫每個服務 | 每個服務獨立 DB，透過 API 存取 | 避免共享 DB |
| CQRS | 命令（寫入）與查詢（讀取）分離 | Event Sourcing |
| Saga 模式 | 分散式交易，補償機制 | 最終一致性 |
| 資料庫 per 服務 | 異質資料庫（SQL + NoSQL） | 業務領域對齊 |
Saga 範例（訂單流程）：
1. 下訂單 → 庫存扣除 → 支付 → 發貨
2. 任一步驟失敗 → 執行補償操作（退款、還庫存）
部署與運維技術棧
容器化與編排：
# Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
spec:
replicas: 3 # 自動水平擴展
template:
spec:
containers:
- name: order-service
image: registry.com/order-service:v1.2.3
resources:
limits:
cpu: "500m"
memory: "512Mi"
服務網格實作：
Istio：自動 mTLS、流量管理、觀測性
Linkerd：輕量，Kubernetes 原生
微服務架構優點
-
技術異質性：UserSvc 用 Node.js，Payment 用 Go
-
獨立擴展：高流量服務獨立加機器
-
持續部署：服務間不互相阻塞
-
容錯設計：單服務故障不癱瘓全系統
-
團隊自治：每個團隊擁有完整服務生命週期
微服務的挑戰與解決方案
| 挑戰 | 影響 | 解決方案 |
|---|---|---|
| 分散式追蹤 | 除錯困難 | Jaeger、Zipkin、OpenTelemetry |
| 資料一致性 | 最終一致性 | Saga、2PC、Outbox 模式 |
| 服務發現 | 動態 IP | Consul、Eureka、Kubernetes Service |
| 網路延遲 | 效能瓶頸 | gRPC、快取、異步通訊 |
| 監控複雜 | 單一視圖缺失 | Prometheus + Grafana、ELK |
實際企業案例
Netflix（先驅）：
700+ 微服務，每秒 10 萬 RPC 呼叫
Spring Cloud Netflix（Eureka、Hystrix）
混亂工程（Chaos Monkey）測試容錯
**Amazon**：
1997 年拆分單體，每團隊擁有端到端責任
API Gateway + Lambda + DynamoDB
**Uber**：
從單體到 1000+ 服務，Go + Python 異質棧
Napkin 數學：團隊數 > 服務數
微服務導入決策矩陣
團隊規模 < 10 → 單體架構
團隊規模 10-50 → 模組化單體 → 微服務
團隊規模 > 50 → 微服務（有 DevOps 成熟度）
技術債高 → 先重構單體
業務變化頻繁 → 微服務優先
最佳實務總結
業務領域導向（DDD）服務邊界
API 版本控制（/v1/orders、/v2/orders）
電路斷路器（Hystrix、Resilience4j）
健康檢查 + 就緒探測
黃金信號監控（延遲、流量、錯誤率）
漸進遷移（Strangler Pattern）
微服務不是銀彈，而是解決大規模系統擴展性的工具。成功關鍵在於明確邊界、強大 DevOps與觀測性文化。從單體開始，當痛苦超過收益時再拆分，才能掌握真正價值，避免「分散式單體」陷阱。