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