📚 课程目录第1章课程导论

1. 课程导论：为什么需要事务边界与日志协同？

在单体应用时代，调试一个请求的完整路径相对简单：查看日志文件，按时间戳排序，结合线程 ID 即可串联出完整调用链。然而，当应用拆分为数十甚至上百个微服务后，一个用户请求会穿越多个服务、多个线程、多个异步任务，传统的日志排查方式迅速失效。

分布式追踪（Distributed Tracing）与结构化日志（Structured Logging）分别从不同维度试图解决这一问题，但两者各自存在显著的盲区。

痛点	描述	典型后果
1. 业务语义缺失	Trace 仅记录 Span 名称、耗时、状态码，无法表达“用户下单失败是因为库存扣减超时”这类业务逻辑。	排查问题时仍需跳转到日志系统查看上下文。
2. 事务边界模糊	数据库事务、消息队列事务、本地事务在 Trace 中通常表现为一个 Span，但事务的开始、提交、回滚、超时等关键状态无法体现。	无法判断事务是否完整执行，难以定位分布式事务不一致的根因。
3. 采样率与存储成本矛盾	高采样率带来海量 Span 数据，存储成本飙升；低采样率则容易丢失关键故障现场的 Trace。	生产环境通常只能保留 1%~5% 的 Trace，大量异常路径被遗漏。

痛点	描述	典型后果
1. 缺乏调用链关联	日志记录的是单点事件，即使包含 TraceID，也无法自动还原服务间的调用拓扑和时序关系。	需要人工跨服务搜索日志，效率极低。
2. 事务状态不完整	日志通常只记录“开始”和“结束”，事务中间的回滚点、补偿操作、重试次数等关键信息缺失。	事务失败时无法判断是业务异常还是基础设施故障。
3. 格式与规范不统一	不同团队、不同语言、不同框架输出的日志字段名、类型、层级各不相同。	日志聚合分析时需要大量 ETL 清洗，实时告警准确率低。

分布式追踪擅长回答“请求去了哪里、花了多久”，结构化日志擅长回答“每个节点发生了什么、数据是什么”。但两者在事务边界这一关键维度上存在空白：事务的开启、提交、回滚、补偿、超时、死锁等状态，既没有被 Trace 完整捕获，也没有被日志标准化记录。

协同设计的核心目标是将事务边界作为第一等公民纳入可观测体系，让 Trace 与 Log 在事务维度上对齐，从而获得以下能力：

  关键洞察：事务边界是连接 Trace 与 Log 的天然桥梁。没有事务边界的 Trace 只是一张“调用拓扑图”，没有 Trace 关联的 Log 只是一堆“孤立事件”。两者协同后，才能形成真正可诊断、可回溯、可审计的分布式可观测体系。

下图展示了事务边界如何作为 Trace 与 Log 之间的协同层，将原本孤立的两个可观测维度连接起来：

如何定义事务边界：在 OpenTelemetry 中设计统一的 Transaction Span 语义约定，覆盖本地事务、分布式事务、Saga、TCC 等模式。
如何实现事务级日志关联：将事务 ID 自动注入结构化日志，并建立 Trace 与 Log 的双向索引。
如何基于事务状态做智能采样：仅对异常事务、超时事务、补偿事务进行全量采样，正常事务降采样。
如何落地生产实践：提供 Java、Go、Python 等语言的代码示例与最佳实践。