4、事务边界定义：分布式事务的ACID与BASE，在微服务中如何界定事务边界
在单体应用中，事务边界由数据库的本地事务管理器清晰界定，ACID（原子性、一致性、隔离性、持久性）是默认的强保证契约。进入微服务架构后，数据被拆分到多个独立的服务与数据库中，传统的单机ACID事务无法跨越进程边界。此时，我们需要重新定义“事务”的含义，在分布式一致性（ACID）与可用性/最终一致性（BASE）之间做出权衡，并明确每个服务的事务边界。
4.1 ACID vs BASE：分布式事务的两种哲学
ACID 适用于单节点或强一致性场景，而 BASE（基本可用、软状态、最终一致性）是分布式系统为了可用性与分区容错性而做出的妥协。下表对比了两者的核心差异：
| 维度 | ACID（强一致性） | BASE（最终一致性） |
|---|---|---|
| 原子性 | 全做或全不做，通过两阶段提交（2PC）实现 | 允许部分成功，通过补偿事务（Saga）回滚 |
| 一致性 | 事务前后数据完整约束不变 | 允许中间状态，最终达到一致 |
| 隔离性 | 串行化或可重复读，避免脏读/幻读 | 读未提交或快照隔离，容忍短暂不一致 |
| 持久性 | 写入即持久，依赖磁盘日志 | 依赖异步复制与重试机制 |
| 适用场景 | 支付、库存扣减、账户余额 | 社交动态、日志聚合、推荐系统 |
| 典型协议 | XA、2PC、Percolator | Saga、TCC、本地消息表 |
关键认知： 在微服务中，不存在“银弹”事务模型。一个复杂的业务流（如订单创建）往往需要混合使用ACID（本地强一致）与BASE（跨服务最终一致）两种模式，关键在于识别每个子操作的边界。
4.2 微服务中事务边界的界定原则
界定事务边界不是技术选型问题，而是业务建模问题。以下四条原则帮助你在微服务中正确划分事务范围：
- 服务内强一致，服务间最终一致： 每个微服务内部使用本地数据库事务保证ACID；跨服务调用通过异步消息或Saga协调，接受最终一致性。
- 以业务聚合根为边界： 一个事务只应修改一个聚合根（Aggregate Root）的状态。例如“订单”聚合根包含订单头、订单项、支付记录，这些应在一个服务内完成。
- 避免分布式事务的“长连接”： 不要用2PC锁住多个服务的资源超过秒级。超过100ms的跨服务锁会导致严重的吞吐量下降。
- 可观测性驱动边界验证： 通过OpenTelemetry追踪每个跨服务调用的耗时与错误率，如果发现某个“事务”频繁因网络超时而回滚，说明边界划分过粗，需要拆分为更细粒度的本地事务+补偿。
4.3 事务边界模型：从本地到全局
下图展示了微服务中三种典型的事务边界模型，以及它们对应的ACID/BASE策略：
4.4 实战：订单创建流程的事务边界拆解
以一个典型的“下单”流程为例，展示如何将一个大事务拆解为多个有明确边界的小事务：
| 步骤 | 服务 | 操作 | 事务模型 | 边界说明 |
|---|---|---|---|---|
| 1 | 订单服务 | 创建订单（状态：待支付） | 本地ACID | 订单表 + 订单项表，单库事务 |
| 2 | 库存服务 | 预扣库存 | 本地ACID | 库存表，乐观锁防止超卖 |
| 3 | 支付服务 | 发起支付（异步） | Saga（BASE） | 若支付失败，触发补偿：回滚库存 |
| 4 | 物流服务 | 创建物流单 | 本地ACID | 物流表，依赖订单ID |
| 5 | 通知服务 | 发送确认消息 | 最终一致 | 消息队列，允许重复消费 |
边界界定结论： 上述流程中，每个服务内部的事务边界就是其自身的数据库。跨服务的“全局事务”实际上是一个Saga编排，由订单服务作为协调者，通过消息或事件驱动后续步骤。如果步骤2（预扣库存）成功但步骤3（支付）失败，订单服务会发送“库存回滚”事件，库存服务消费该事件并执行本地补偿事务。整个流程没有跨服务的2PC锁，每个服务的事务边界清晰且独立。
4.5 事务边界与可观测性的映射
在OpenTelemetry中，事务边界直接对应Span的边界。每个本地事务应生成一个独立的Span，而跨服务的Saga流程则对应一个Trace。通过为每个事务步骤添加属性（如 transaction.type、transaction.boundary），可以在追踪系统中快速定位事务失败点：
// 伪代码：在订单服务中标记事务边界
span.setAttribute("transaction.type", "local_acid");
span.setAttribute("transaction.boundary", "order_service_db");
span.setAttribute("transaction.id", orderId);
// 在Saga协调器中标记全局事务
sagaSpan.setAttribute("transaction.type", "saga_base");
sagaSpan.setAttribute("transaction.boundary", "order_creation_saga");
sagaSpan.setAttribute("saga.step", "inventory_reserve");
常见陷阱： 不要将整个HTTP请求（从网关到多个服务）标记为一个“分布式事务”。正确的做法是：每个服务内的本地数据库操作是一个独立事务，跨服务的协调逻辑（如Saga）是一个业务流程，而不是一个数据库事务。混淆这两者会导致事务边界模糊，回滚逻辑混乱，且无法通过OpenTelemetry准确定位故障点。
4.6 小结：事务边界决策矩阵
根据业务场景选择合适的事务边界模型：
| 场景 | 推荐模型 | 事务边界 | 一致性级别 |
|---|---|---|---|
| 单服务、单表操作 | 本地ACID | 数据库事务 | 强一致 |
| 单服务、多表操作 | 本地ACID | 服务内事务 | 强一致 |
| 跨服务、短流程（2~3步） | Saga 编排 | 每个服务独立 | 最终一致 |
| 跨服务、长流程（多步） | Saga + 事件驱动 | 每个服务独立 | 最终一致 |
| 跨服务、强一致要求（极少） | 2PC（仅限同机房） | 全局协调器 | 强一致 |