簡介
遷移到微服務時，服務分離是最重要的架構決策。劃分太小→複雜性爆炸。分太大→分散式整體。本文指導了正確定義服務邊界的系統方法。
1.分離原理
1.1 服務的單一責任
每個服務負責獨特的業務能力：
- 使用者服務→使用者生命週期管理（註冊、登入、個人資料）
- 產品服務→產品目錄、搜尋、評論
- 訂單服務 → 訂單處理、履行、歷史記錄
1.2 兩個主要策略
依業務能力分解：
根據組織提供的業務功能：
E-Commerce Business Capabilities:
├── Customer Management → User Service
├── Product Management → Product Service
├── Order Management → Order Service
├── Payment Processing → Payment Service
├── Inventory Management → Inventory Service
└── Shipping & Delivery → Shipping Service
按子域（DDD）分解：
基於透過 DDD 識別的子域：
Core Subdomains (competitive advantage):
├── Product Catalog → Product Service (custom-built, best team)
├── Order Processing → Order Service (complex logic)
Supporting Subdomains (necessary but not differentiating):
├── Inventory → Inventory Service
├── Customer Profile → User Service
Generic Subdomains (solved problems):
├── Authentication → Keycloak (off-the-shelf)
├── Payment Gateway → Stripe integration
├── Email → SendGrid/SES
1.3 正確的服務邊界標誌
- 服務可以獨立開發、部署、擴展
- 服務 A 的變更很少需要服務 B 的變更
- 每個服務都有自己的資料庫（無共享表）
- 團隊可以在服務上工作無需與其他團隊協調
- 服務具有內聚的 API - 密切相關的端點
2. 上下文映射模式
一旦確定了有界上下文，您需要定義它們之間的關係：
2.1 合作夥伴
兩個團隊密切合作，共同開發介面：
Product Team ←→ Search Team
(cùng định nghĩa product schema cho search indexing)
2.2 客戶-供應商
上游（供應商）提供資料/API，下游（客戶）消耗：
Product Service (Supplier) → Order Service (Customer)
(Order Service cần product info nhưng không thay đổi product)
2.3 反腐敗層（ACL）
用於保護域模型免受外部/遺留系統影響的轉換層：
┌──────────┐ ┌─────┐ ┌──────────────┐
│ Order │ ──► │ ACL │ ──► │ Legacy ERP │
│ Service │ │ │ │ (SOAP/XML) │
└──────────┘ └─────┘ └──────────────┘
ACL convert REST/JSON ↔ SOAP/XML
3. 應避免反模式
3.1 分散式整體架構
❌ Services phụ thuộc chặt chẽ:
Service A → Service B → Service C → Service A (circular!)
Kết quả: phải deploy A, B, C cùng lúc = worse than monolith
3.2 奈米服務
❌ Chia quá nhỏ:
├── ProductNameService
├── ProductPriceService
├── ProductImageService
└── ProductReviewService
✅ Chia hợp lý:
└── ProductService (gom lại thành 1 service)
3.3 共享資料庫
❌ Nhiều services dùng chung DB:
Service A ──┐
Service B ──┼──► Shared PostgreSQL (products table)
Service C ──┘
Thay đổi schema → break tất cả services
✅ Database per Service:
Service A → DB_A
Service B → DB_B (replicate data nếu cần)
Service C → DB_C
4. 實務：分離電子商務平台
適用於整個系列的項目：
E-Commerce Platform Services:
┌─────────────────────────────────────────┐
│ User Service (Supporting) │
│ - Registration, Login, Profile │
│ - PostgreSQL (users, addresses) │
│ - Team: 2-3 devs │
├─────────────────────────────────────────┤
│ Product Service (Core) │
│ - Catalog, Search, Reviews, Categories │
│ - PostgreSQL + Elasticsearch │
│ - Team: 3-4 devs │
├─────────────────────────────────────────┤
│ Cart Service (Supporting) │
│ - Add/Remove items, Apply coupon │
│ - Redis (fast, ephemeral) │
│ - Team: 2 devs │
├─────────────────────────────────────────┤
│ Order Service (Core) │
│ - Place order, Track, History │
│ - PostgreSQL (orders, order_items) │
│ - Team: 3-4 devs │
├─────────────────────────────────────────┤
│ Payment Service (Generic) │
│ - Stripe/VNPay integration │
│ - PostgreSQL (transactions) │
│ - Team: 2 devs │
└─────────────────────────────────────────┘
總結
| 原則 | 描述 |
|---|---|
| 依領域劃分 | 使用DDD Bounded Context，不依技術層劃分 |
| 鬆散耦合 | 服務 A 發生變化，無需部署服務 B |
| 高凝聚力 | 相關功能位於同一個服務 |
| 自己的資料 | 每個服務都有自己的資料庫 |
| 尺寸合適 | 不太大（整體），也不太小（奈米服務） |