服务拆分原则

TIP

合理的服务拆分是微服务架构成功的关键。拆分的粒度既要足够细以实现独立部署，又要避免过细导致运维成本激增。

拆分原则

1. 单一职责原则

每个服务只负责一个业务领域内的功能。

// ❌ 错误：用户服务做了订单的事情
public class UserService {
    public void createUser(User user) { }
    public void createOrder(Order order) { } // 不该在这里
}

// ✅ 正确：各司其职
public class UserService {
    public void createUser(User user) { }
}
public class OrderService {
    public void createOrder(Order order) { }
}

2. 基于业务领域拆分（DDD）

• 用户域：注册、登录、权限
• 订单域：下单、支付、退款
• 商品域：SPU、SKU、库存
• 支付域：支付渠道、账单

3. 基于组织架构拆分

康威定律：系统设计反映组织的沟通结构。

4. 基于数据边界拆分

每个服务拥有独立的数据库，服务间通过 API 调用或消息队列通信。

拆分策略

垂直拆分（纵向）

按功能模块切分，降低业务耦合。

水平拆分（横向）

将同一类型的数据分区处理，如按用户 ID 分库。

拆分后的挑战

挑战	解决方案
服务间通信	HTTP(REST) / gRPC / 消息队列
数据一致性	分布式事务（Seata）
服务发现	Nacos / Consul
配置管理	Nacos Config
API 网关	Spring Cloud Gateway
链路追踪	Sleuth + Zipkin
日志聚合	ELK
监控告警	Prometheus + Grafana