微服务拆分原则

微服务拆分是架构设计的核心环节，合理的拆分直接影响系统的可维护性、扩展性和开发效率。以下是经过实践验证的7大核心原则，附关键说明和常见陷阱：

一、核心拆分原则

业务能力优先（核心原则）
- 做法：按独立业务功能划分（如用户服务、订单服务、支付服务）。
- 关键点：每个服务对应一个完整的业务闭环（如订单服务包含创建、查询、取消等全流程）。
- 陷阱：避免按技术层拆分（如“API服务”“DB服务”）。
领域驱动设计（DDD）限界上下文
- 做法：通过DDD识别业务边界（如电商中“商品管理”“库存管理”属于不同上下文）。
- 关键点：上下文内高内聚，上下文间通过API/事件交互。
- 案例：用户注册（用户服务）与商品价格计算（商品服务）应分离。
单一职责（服务粒度控制）
- 标准：一个服务只做一件事（如“短信通知服务”不应包含用户验证逻辑）。
- 平衡点：服务不宜过小（避免“纳米服务”增加运维负担）或过大（退化成分布式单体）。
高内聚低耦合
- 内聚：服务内部功能紧密相关（如订单服务包含折扣计算）。
- 解耦：
  - ✅ 通过API网关暴露接口
  - ✅ 事件驱动（如Spring Cloud Stream）
  - ❌ 严禁共享数据库（最大陷阱！）
自治性
- 独立部署、独立数据库、独立技术栈选型。
- 关键实践：每个服务独占数据库Schema（MySQL）或Collection（MongoDB）。
演进式拆分
- 从单体逐步拆分，优先分离频繁变更或需独立扩展的模块。
- 信号：某模块修改需重新部署整个应用时，即需拆分。
康威定律适配
- 团队结构决定架构：一个团队负责1-2个服务（避免跨团队协作服务）。

二、必须规避的4大错误

共享数据库
- 后果：服务直接读写他人数据库 → 耦合爆炸，无法独立部署。
- 解决：只通过API交互，数据同步用CDC（Debezium）或事件总线。
过度拆分（纳米服务）
- 症状：调用链过长（A→B→C→D完成一次请求），性能暴跌。
- 修复：合并关联服务，或使用API网关聚合数据。
同步调用链过深
- 案例：用户请求触发10个同步RPC调用。
- 优化：
  - 改异步消息（RabbitMQ/Kafka）
  - 并行调用（CompletableFuture）
  - 缓存非实时数据
忽略分布式事务
- 正确做法：
  - 最终一致性：Saga模式（Choreography/Orchestration）
  - 补偿事务：TCC（Try-Confirm-Cancel）
  - 本地消息表

三、实践清单（快速行动）

启动步骤
- 步骤1：绘制业务流程图，圈出独立功能块（如支付、风控）。
- 步骤2：为每个功能块创建独立Spring Boot项目。
- 步骤3：每个服务配置私有数据源（spring.datasource.url指向独立Schema）。

技术集成（Spring Cloud）

# 服务注册（Nacos示例）
spring:
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848

# OpenFeign声明式调用
@FeignClient(name = "order-service")
public interface OrderServiceClient {
    @PostMapping("/orders")
    Order createOrder(OrderRequest request);
}

# 熔断降级（Resilience4j）
@CircuitBreaker(name = "orderService", fallbackMethod = "createOrderFallback")

拆分验证标准
- ✅ 修改服务A代码，无需重新部署服务B
- ✅ 服务B宕机时，服务A核心功能仍可用（有降级策略）
- ✅ 可单独扩展服务A的实例数应对流量高峰

四、经典案例：电商系统拆分

graph LR
  API网关 --> 用户服务
  API网关 --> 商品服务
  API网关 --> 订单服务
  订单服务 -->|消息队列| 库存服务
  订单服务 -->|Feign调用| 支付服务
  商品服务 -->|Redis缓存| 价格服务

解耦要点：
- 订单创建后发MQ事件，库存服务异步扣减（非同步调用）。
- 商品价格缓存，避免实时调用价格服务。
- 支付服务与订单服务通过API契约交互（而非共享订单表）。

终极心法：拆分时不断问三个问题

该服务是否拥有独立业务价值？

修改此服务是否需要牵连其他服务？

此服务能否独立扩缩容？
若答案全为“是”，即是合理拆分。