链路追踪原理#

核心概念： TraceID(全局唯一) + SpanID(单次调用) + ParentSpanID(父调用)

实现： SkyWalking(字节码增强,无侵入) / Zipkin(后端，配合 Brave 等库埋点) / OpenTelemetry(当前事实标准，OpenTracing 与 OpenCensus 已合并进来并归档；有 Java Agent 零代码埋点) / Spring 生态：Spring Cloud Sleuth 已停止演进，Spring Boot 3 起由 Micrometer Tracing（底层 OTel 或 Brave）接替

数据流： 埋点采集 → 传输(gRPC/HTTP 直报，量大时可选 Kafka 缓冲) → 存储(ES/BanyanDB 等) → 展示

在微服务架构下，一个请求可能经过十几个服务，出了问题很难定位是哪个环节慢或报错，所以需要分布式链路追踪。它的核心概念有三个：TraceID 是全局唯一标识，用来串联一次完整的请求调用链；SpanID 标识每一次具体的服务调用；ParentSpanID 指向上游调用，这样就能还原出完整的调用树。实现方案上，我推荐 SkyWalking，它基于 Java Agent 字节码增强技术，在启动时自动拦截 HTTP、RPC、数据库等调用进行埋点，对业务代码完全零侵入，不需要改一行代码。相比之下 Zipkin 本身是存储和展示后端，埋点要引入 Brave 等库（常用框架有现成的自动埋点，但要加依赖和配置）。现在新项目更常用 OpenTelemetry 做统一采集标准，Spring Boot 3 用 Micrometer Tracing 对接，后端可以是 Jaeger、Zipkin 或 SkyWalking。数据流向上是：埋点采集的 Span 数据通过 gRPC/HTTP 上报（流量大时可经 Kafka 缓冲）到后端，存储在 Elasticsearch 等存储中（SkyWalking 10 起推荐自研的 BanyanDB），然后通过 UI 界面可视化展示调用链和性能指标。生产环境中不可能追踪所有请求，通常采用采样策略，比如只采样 10% 的请求，在性能开销和可观测性之间做平衡。

追问方向：

• “TraceID 怎么透传？”→ HTTP 调用通过请求头传递（现在的标准是 W3C Trace Context 的 traceparent 头，Zipkin 老式是 B3 的 X-B3-TraceId，SkyWalking 用 sw8）、RPC 调用通过隐式上下文传递（如 Dubbo 的 attachment）、MQ 通过消息 header 传递；跨线程不能只靠 InheritableThreadLocal（它只在创建线程时复制，线程池复用线程会串号或丢失），要用 TransmittableThreadLocal、包装 Runnable/Executor（如 OTel 的 Context.wrap）或 Agent 自动增强线程池
• “SkyWalking 为什么侵入性低？”→ SkyWalking 基于 Java Agent + 字节码增强（ByteBuddy），在类加载时自动织入追踪逻辑，业务代码零改动；对比 Zipkin + Brave 需要引入依赖和配置；OpenTelemetry Java Agent 也能做到类似的零代码埋点
• “追踪数据量大怎么处理？”→ 采样策略：按比例采样（如 10%）或按条件采样（只采集慢请求/错误请求）；存储端用 Elasticsearch 做索引并设置 TTL 自动过期，按冷热分离降低成本

易错点：

• ❌ 所有请求都要追踪——应使用采样
• ❌ 链路追踪只能看调用链——还能分析性能瓶颈