1.首先，需要明确TID的作用：
1.1分布式事务链路追踪
TID 作为全局唯一标识符，在分布式系统架构中实现端到端的请求追踪。当业务请求在微服务间流转时，TID 保持恒定不变，确保整个调用链路的完整性与可追溯性。
1.2 问题诊断与根因分析
在复杂分布式环境中，TID 为故障排查提供关键上下文信息。通过 TID 可快速关联跨服务的日志、指标和异常信息，精准定位性能瓶颈或故障点，显著提升系统可观测性。
2.TID是怎么获取到的呢？
TID是通过skywalking的agent探针生成的。
skywalking的架构图如下：
- 上部分 Agent ：负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是，SkyWalking Agent 收集 SkyWalking Tracing 数据，传递给服务器。
- 下部分 SkyWalking OAP ：负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core) ，存储到外部存储器( Storage )，最终提供查询( Query )功能。
- 右部分 Storage ：Tracing 数据存储。目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器。而我们目前采用的是 ES ，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主。
- 左部分 SkyWalking UI ：负责提供控台，查看链路等等。
关于TID我们只需要着重关注Agent和SkyWalking OAP部分即可。
２.1 Trace ID 来源
- 生成源头：Trace ID 由 SkyWalking Agent 自动生成
- 传播机制：通过 HTTP 头部 tid 在服务间传递
- 链路追踪：同一个请求在所有微服务中使用相同的 Trace ID
客户端请求链路的流程图如下：
客户端 SkyWalking Agent TraceIdFilter 业务处理 日志记录 下游服务 发送请求 检测请求头 是否存在 Trace ID 提取现有 Trace ID 生成新 Trace ID alt [存在 Trace ID] [不存在 Trace ID] 传递请求上下文 设置响应头 tid=${traceId} 继续过滤器链 处理业务逻辑 记录日志 携带 Trace ID 调用下游服务 通过 HTTP Header/RPC Context 传播 Trace ID 接收并处理请求 继续传播 Trace ID 客户端 SkyWalking Agent TraceIdFilter 业务处理 日志记录 下游服务
２.２SkyWalking 生效机制
２.２.1 自动注入
- Java Agent：通过 JVM 参数加载 SkyWalking Agent
- 字节码增强：在运行时修改类字节码，注入追踪逻辑
- 上下文传播：自动管理 Trace Context 的创建和传递
２.２.2 链路追踪流程
- 请求入口：Agent 检测到 HTTP 请求，创建或提取 Trace Context
- ID 生成：生成全局唯一的 Trace ID 和本地的 Span ID
- 上下文传递：通过 ThreadLocal 和 HTTP 头部传递上下文
- 日志集成：MDC(Mapped Diagnostic Context) 自动注入 Trace ID
- 数据上报：追踪数据异步上报到 SkyWalking OAP Server