2. 微服务架构与API事务边界
2.1 微服务拆分原则
微服务架构的核心挑战在于如何合理划分服务边界。错误的拆分会导致服务间过度耦合，使分布式事务问题成倍放大。以下是业界验证有效的四项基本原则：
| 原则 | 核心思想 | 反例警示 |
|---|---|---|
| 业务能力拆分 | 按领域驱动设计（DDD）的限界上下文划分，每个服务对应一个明确的业务能力 | 将“订单创建”与“库存扣减”拆成两个服务，但共享同一数据库表 |
| 数据主权独立 | 每个服务拥有自己的数据存储，禁止跨服务直接访问数据库 | 服务A通过JDBC直连服务B的数据库表 |
| 接口契约化 | 服务间通过API契约通信，契约是双方唯一的耦合点 | 服务B修改响应字段后，服务A在运行时解析失败 |
| 事务边界对齐 | 一个本地事务只在一个服务内完成，跨服务操作必须通过最终一致性 | 在服务A中开启全局事务，远程调用服务B并回滚 |
关键认知： 微服务拆分不是越细越好。事务边界必须与业务一致性要求对齐——强一致性操作应尽量留在同一个服务内，最终一致性操作才适合跨服务。
2.2 事务边界的定义
事务边界是指一组操作必须满足ACID（原子性、一致性、隔离性、持久性）特性的最小范围。在单体架构中，事务边界通常等于数据库连接边界；在微服务架构中，事务边界被严格限制在单个服务内部。
下图展示了单体架构与微服务架构中事务边界的本质差异：
实践要点： 在微服务架构中，事务边界就是服务边界。如果一个操作需要跨越多个服务才能完成，那么它就不再是一个本地事务，而是一个需要分布式协调的“业务事务”。
2.3 分布式事务的痛点
当业务操作必须跨越多个服务的事务边界时，分布式事务问题随之产生。以下是微服务实践中最常见的四大痛点：
- 两阶段提交（2PC）的性能瓶颈——协调者单点阻塞，资源锁定时间长，高并发场景下吞吐量急剧下降。
- 最终一致性的补偿复杂性——Saga模式需要为每个本地事务编写补偿操作，补偿逻辑的正确性难以验证。
- API契约的隐式耦合——服务间的API响应结构、超时策略、重试语义未显式约定，导致事务回滚时出现数据不一致。
- Kubernetes环境下的网络不确定性——Pod重启、网络分区、DNS缓存等问题使分布式事务的超时和重试更加不可控。
下表对比了三种主流分布式事务方案的适用场景与核心缺陷：
| 方案 | 一致性模型 | 适用场景 | 核心痛点 |
|---|---|---|---|
| 2PC（两阶段提交） | 强一致性 | 短事务、低并发、同构数据库 | 协调者单点、资源锁定、性能差 |
| TCC（Try-Confirm/Cancel） | 最终一致性 | 资源预留型业务（如库存、账户） | 业务侵入性强、Cancel逻辑复杂 |
| Saga（编排/ choreography） | 最终一致性 | 长事务、跨异构系统 | 补偿操作难验证、缺乏隔离性 |
常见误区： 很多团队在微服务初期选择2PC来保证跨服务强一致性，结果在Kubernetes环境下频繁出现事务超时和死锁。正确的做法是：优先通过服务合并将事务边界收窄，实在无法合并时再选择Saga或TCC，并辅以契约测试来验证补偿逻辑的正确性。
下图展示了分布式事务在Kubernetes环境中的典型故障链路：
核心结论： 分布式事务的痛点本质上是事务边界与API契约不匹配的体现。契约测试的核心价值正是在于：在Kubernetes环境下，通过显式验证API的请求/响应结构、超时语义、幂等性保障和补偿路径，确保跨服务的事务边界在运行时不会因契约偏差而断裂。