# 使用 Spring Cloud Contract 實踐事件驅動的微服務契約測試

{%hackmd @coscup/announcement-2025 %}

> [投影片](https://drive.google.com/file/d/1EtTghcPDL_7GvnmjgqC-eW4_FocDYlIj/view?usp=sharing)

## 1. 傳統微服務整合困境

### 共用資料庫
**優點**
- 資料一致性高
- 開發初期整合成本低

**缺點**
- 資料庫 schema 變更影響所有服務
- 擴展性差，難以分散負載
- 無法真正實現服務自治

---

### 各服務獨立資料庫，透過 HTTP 溝通
**優點**
- 服務自治，資料耦合度低
- 可以獨立部署與擴展

**缺點**
- 高度耦合於 API 規格
- API 變更需同步協調
- 測試與維護成本上升

---

## 2. 事件驅動架構 (EDA)
**副標題**：透過事件傳遞訊息，實現服務間鬆耦合
- 以事件為核心，服務間透過消息系統（Kafka、RabbitMQ 等）交換資訊
- Producer 發布事件，Consumer 訂閱事件
- 提高擴展性與可維護性

---

## 3. SAGA 模式處理交易一致性

### Choreography（編舞式）
- 無中央協調者，服務依序觸發事件完成交易
- 自治性高，擴展性佳
- 缺點：流程分散，觀察與管理較難

### Orchestration（編排式）
- 有中央 Orchestrator 控制流程
- 流程可觀測、錯誤補償集中
- 缺點：中央節點成為單點風險，耦合度高

---

## 4. 落實微服務的建築藍圖
### DDD 與 Clean Architecture
- **DDD**：以業務為中心，劃分邊界，建立領域模型
- **Clean Architecture**：依賴方向指向內層，確保業務邏輯不依賴技術細節

---

### Food Ordering System 範例
- Order Service（唯一對外 HTTP API）
- Payment Service（事件消費）
- Restaurant Service（事件消費）
- 透過 Kafka Event Channel 互通

---

### 測試策略：E2E 痛點
**E2E 常見問題**
- 🐢 效能低：需啟動完整系統，耗時長
- 🔥 脆弱性高：任一服務異常即測試失敗
- 💸 維護成本高：流程或 API 變更需大量改測
- 🧱 部署困難：依賴上下游與完整環境

---

## 5. Spring Cloud Contract (SCC) 簡介
- 契約測試框架，支援 REST API 與 Messaging
- Consumer-Driven Contract：由消費者定義需求，生產者驗證
- 減少整合測試成本，提前發現介面變更風險

---

## 6. SCC 契約測試流程
1. Producer 撰寫 Groovy Contract
2. SCC 產生並執行 Producer 測試（驗證 response 與事件）
3. 發佈 stub
4. Consumer 引入 stub，使用 StubRunner 模擬事件
5. 驗證 Consumer 處理邏輯與資料寫入

---

### 案例：訂單建立成功發送事件
### Producer 測試
- 合約定義 request、response 與 outputMessage
- `triggeredBy("createOrder()")`：告訴 SCC 呼叫 ContractTestBase 方法
- KafkaMessageVerifierReceiver：攔截並驗證事件

### Consumer 測試
- 引入 Producer 發佈的 stub
- StubTrigger 觸發事件
- 驗證 Consumer 的業務邏輯與資料落庫

---

## 7. 收尾
- 契約測試可在開發階段驗證服務邊界
- 減少 E2E 測試的負擔與風險
- 提高跨服務協作的穩定性與可追溯性

###### tags: `COSCUP2025`, `zhtw`, `intermediate`