3. 事务边界概念：什么是事务边界，在分布式系统中的表现，事务边界与 Span 的关系
3.1 事务边界的定义
事务边界（Transaction Boundary）是分布式可观测性中最核心但最容易被误解的概念之一。它定义了一个完整业务操作从开始到结束的时空范围，在这个范围内，所有相关的操作要么全部成功，要么全部失败（从业务语义角度）。
在单体应用中，事务边界通常与数据库事务的生命周期重合：BEGIN TRANSACTION 到 COMMIT 或 ROLLBACK。但在分布式系统中，事务边界跨越了进程、服务、数据库、消息队列等多个组件，不再由单一的技术边界决定。
核心定义：事务边界 = 业务操作完整性范围。它标记了“一个业务操作从哪里开始，到哪里结束”，以及“哪些操作属于同一个业务单元”。
3.2 分布式系统中的事务边界表现
在分布式系统中，事务边界呈现出多种形态，下表总结了最常见的几种表现及其特征：
| 事务边界类型 | 典型场景 | 边界判定依据 | 常见问题 |
|---|---|---|---|
| 本地事务边界 | 单体服务内数据库操作 | 数据库连接会话 | 连接池耗尽、长事务锁 |
| 分布式事务边界 | 跨服务订单创建（订单+库存+支付） | 全局事务ID（如 XID） | 最终一致性延迟、补偿失败 |
| 消息事务边界 | 发送消息 + 更新数据库 | 消息确认 + 本地事务提交 | 消息丢失、重复消费 |
| 异步回调边界 | 支付回调、Webhook 处理 | 回调超时 + 重试次数 | 回调丢失、幂等性失效 |
| 用户感知边界 | 用户点击下单到看到结果 | 用户等待时间 + 前端超时 | 前端超时但后端仍在处理 |
常见误区：很多团队将“数据库事务”等同于“业务事务边界”。在分布式系统中，一个业务事务可能包含多个数据库事务，也可能一个数据库事务都不包含（如纯缓存操作）。事务边界是业务语义的，不是技术语义的。
3.3 事务边界与 Span 的关系
在 OpenTelemetry 中，Span 是事务边界的可观测性载体。每个 Span 代表一个操作单元，而事务边界则通过 Span 的层级结构和上下文传播来体现。
它们之间的关系可以用以下三点概括：
- 根 Span 定义事务边界起点和终点：一个事务的根 Span 的
StartTime和EndTime精确标记了事务边界的开始和结束。 - 子 Span 填充事务边界内部细节：事务内部的每个步骤（数据库查询、RPC 调用、消息发送）都对应一个子 Span，它们共同构成事务边界的内部结构。
- 上下文传播维持事务边界连续性：通过
TraceId和SpanId的传播，即使事务跨越多个服务，也能将分散的 Span 关联到同一个事务边界内。
下图展示了事务边界与 Span 的映射关系：
3.4 事务边界在 Span 中的关键属性
为了在 OpenTelemetry 中正确表达事务边界，Span 需要携带以下关键属性：
| 属性 | 作用 | 示例值 |
|---|---|---|
transaction.id |
业务事务唯一标识 | txn-20240315-001 |
transaction.type |
事务类型（本地/分布式/消息） | distributed |
transaction.status |
事务最终状态 | committed / rolled_back |
transaction.duration |
事务耗时（毫秒） | 1250 |
transaction.participants |
参与的服务/资源列表 | order, inventory, payment |
最佳实践：在根 Span 上设置
transaction.* 属性，在子 Span 上设置 transaction.step.* 属性（如 transaction.step.name、transaction.step.sequence）。这样可以在不破坏 Span 层级结构的前提下，清晰表达事务边界内的步骤顺序。
3.5 事务边界丢失的典型场景
在实际系统中，事务边界经常因为以下原因而丢失或模糊：
- 异步处理链断裂：消息队列消费时未传递 TraceId，导致生产者与消费者之间的 Span 无法关联到同一个事务边界。
- 线程池切换：任务提交到线程池后，新线程未继承父线程的上下文，导致事务边界在跨线程时断裂。
- 定时任务/批处理：定时任务通常没有上游调用链，需要手动创建根 Span 并定义事务边界。
- 网关超时与后端继续处理：前端超时断开连接，但后端仍在执行，此时事务边界在前端视角已结束，在后端视角仍在继续。
下图展示了事务边界丢失的典型场景：
3.6 事务边界设计原则
在 OpenTelemetry 中设计事务边界时，应遵循以下原则：
- 业务驱动原则：事务边界由业务语义决定，而非技术实现。一个用户下单操作，即使涉及 10 个微服务，也属于同一个事务边界。
- 显式声明原则：在根 Span 上显式声明事务边界属性（如
transaction.id），避免依赖隐式推断。 - 上下文穿透原则：确保 TraceId 和 SpanId 能够穿透所有中间件（消息队列、缓存、异步框架），维持事务边界的连续性。
- 超时兜底原则：为事务边界设置合理的超时时间，超时后即使后端仍在处理，也应标记事务边界为“超时”状态。
总结：事务边界是分布式可观测性的“骨架”，Span 是“血肉”。没有清晰的事务边界，Span 只是一堆孤立的操作记录；有了事务边界，Span 才能还原出完整的业务故事。在 OpenTelemetry 实践中，先定义事务边界，再设计 Span 结构，是构建高质量可观测性系统的关键步骤。