微服务架构设计模式：从单体拆分到服务治理

何时需要微服务

微服务适合：多团队并行开发、独立部署需求、异构技术栈、弹性伸缩要求高的场景。不适合：早期项目（过度设计）、简单 CRUD 应用、团队规模小。

DDD 限界上下文拆分

按业务领域拆分，而非按技术层拆分：

❌ 按技术层：Controller层 → Service层 → Repository层
✅ 按业务领域：订单服务、用户服务、库存服务、支付服务

Saga 分布式事务

在微服务中，跨服务事务用 Saga 模式替代 2PC：

// 编排式 Saga
async function createOrder(order) {
  await orderService.create(order);        // 1. 创建订单
  await inventoryService.reserve(order);   // 2. 预留库存
  await paymentService.charge(order);      // 3. 扣款
  // 任一步失败 → 触发补偿事务回滚
}
// 补偿： cancelPayment() → releaseInventory() → cancelOrder()

CQRS 读写分离

将读和写拆分为独立服务，查询端可独立优化：

• Command 端：处理写操作，保持领域模型完整性
• Query 端：为查询场景定制数据视图，可多副本扩展
• 通过事件(Event)同步两端数据

API Gateway 模式

// Nginx/Kong 统一入口
location /api/users/   { proxy_pass http://user-service; }
location /api/orders/  { proxy_pass http://order-service; }
// 统一鉴权、限流、日志、聚合

服务治理 checklist

• 服务注册与发现（Consul/Eureka/Nacos）
• 负载均衡（客户端负载均衡）
• 熔断降级（断路器模式）
• 分布式链路追踪（Jaeger/Zipkin）
• 统一配置中心
• 健康检查 + 优雅关闭