链路追踪原理#

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

实现： SkyWalking(字节码增强,无侵入) / Zipkin(SDK埋点) / Sleuth(Spring Cloud)

数据流： 埋点采集 → 传输(Kafka) → 存储(ES) → 展示

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

追问方向：

• “TraceID 怎么透传？”→ HTTP 调用通过请求头传递（如 X-B3-TraceId）、RPC 调用通过隐式上下文传递（如 Dubbo 的 attachment）、MQ 通过消息 header 传递；跨线程需用 InheritableThreadLocal 或手动传递
• “SkyWalking 为什么侵入性低？”→ SkyWalking 基于 Java Agent + 字节码增强（ByteBuddy），在类加载时自动织入追踪逻辑，业务代码零改动；对比 Zipkin 需要手动埋点，侵入性更高
• “追踪数据量大怎么处理？”→ 采样策略：按比例采样（如 10%）或按条件采样（只采集慢请求/错误请求）；存储端用 Elasticsearch 做索引并设置 TTL 自动过期，按冷热分离降低成本

易错点：

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