本文目录导读：
全链路追踪在微服务架构中已经是一个标配组件，它的核心作用是解决“在分布式系统中，一个请求经过多个服务后，如果出错了或变慢了，到底是哪个环节出了问题” 这个问题。
下面我从核心原理、具体技术实现、落地步骤以及实际使用场景四个方面,帮你梳理它在微服务中到底怎么用。
核心原理：理解几个关键概念
在使用之前，需要理解全链路追踪的基础模型，通常基于 Google Dapper 论文,包含三个核心概念：
- Trace ID（追踪ID）：一个全局唯一的ID，当一个请求进入系统时，在入口处（如网关）生成，它会透传到所有下游服务,串联起整个请求路径。
- Span ID（跨度ID）：一次远程调用（比如A调用B）就是一个Span，每个Span有自己的ID，并且记录了父Span的ID（Parent Span ID）,从而形成层级结构。
- Annotation（注解/事件）：记录关键时间点，如：
CS（Client Send，客户端发送）CR（Client Receive，客户端接收）SS（Server Send，服务端发送）SR（Server Receive，服务端接收）
一个简单的流转流程： 用户请求 -> 网关（生成 Trace ID，记录 Span1） -> 服务A（记录 Span2，Parent=Span1） -> 服务B（记录 Span3，Parent=Span2） -> 数据库（记录 Span4，Parent=Span3） 这四个Span通过相同的Trace ID关联起来,形成一个树状调用拓扑图。
主流技术方案
在微服务中，最常用的方案是基于开源标准来实现,主要有两套体系：
| 特性 | SkyWalking | Jaeger / Zipkin |
|---|---|---|
| 侵入性 | 无侵入（基于Java Agent字节码增强） | 低侵入（需要引入SDK进行埋点） |
| 协议标准 | 自研协议，也支持OpenTelemetry | 原生支持 OpenTracing，后迁移至 OpenTelemetry |
| 适合场景 | Java技术栈为主的团队，希望零代码改造 | 多语言、异构系统，希望灵活定制 |
| 功能侧重 | 追踪 + 性能监控（APM） + 告警一体的全栈方案 | 专注链路追踪和数据展示，常与 Prometheus、Grafana 配合 |
| 存储 | 支持 Elasticsearch、MySQL、TiDB 等 | 通常使用 Elasticsearch、Cassandra |
当前趋势：OpenTelemetry 正在成为统一标准，它合并了 OpenTracing 和 OpenCensus，推荐新项目直接使用 OpenTelemetry，然后可以选择将数据导出到 Jaeger、SkyWalking 或 Prometheus。
具体使用步骤（以 SkyWalking 为例）
SkyWalking 的优点是对业务代码几乎无侵入,使用起来比较简单。
第一步：部署后端服务
- 下载 SkyWalking 服务器（OAP Server + UI）。
- 配置存储（推荐 Elasticsearch）。
- 启动 OAP 和 UI。
webapp目录下启动 UI，默认端口是 8080。bin目录下startup.sh启动后端 OAP。
第二步：Java 服务接入（无需改代码）
在启动你的微服务（Spring Boot）时，在 JVM 参数中加入 Agent：
-javaagent:/path/to/skywalking-agent/skywalking-agent.jar -DSW_AGENT_NAME=your-service-name # 设置服务名 -DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 # OAP地址
生效后：你的服务所有 HTTP 请求、gRPC 调用、数据库操作（JDBC、Redis、MQ）都会自动被 SkyWalking 采集到。
第三步：在 UI 上查看数据
- 拓扑图：一眼看清服务之间的调用关系、流量大小、响应时间。
- 链路追踪：点击一个慢请求，可以看到完整的调用链，某一段耗时特别高（比如数据库查询 5s 或 Redis 超时）。
- 报警：配置规则，当接口 P99 延迟 > 500ms 时，发送钉钉/邮件通知”。
实际使用中的核心价值（怎么用）
有了全链路追踪后，不只是看个漂亮的拓扑图,更重要的是解决下面这些实际问题：
快速定位异常服务
- 场景：用户反馈“点击下单按钮，页面一直转圈”。
- 处理：在追踪系统中搜索该用户的 Trace ID，发现请求卡在了“订单服务 -> 库存服务”这一步，而且库存服务返回了 500 错误，迅速锁定是库存服务 Pod 挂了。
分析性能瓶颈
- 场景：接口平时 100ms，现在突然 3s。
- 处理：查看调用链详情，发现耗时最长的 Span 是 MySQL 查询，点进去能看到 SQL 语句，发现没有走索引，直接发给 DBA 优化索引即可。
依赖治理（梳理服务调用关系）
- 场景：技术团队新来了人，不清楚“下单”这个请求到底调用了哪些服务。
- 处理：在拓扑图上找到“下单接口”，点击查看依赖链路，能明确知道它调用了用户、商品、库存、优惠券、支付等 8 个服务，这对重构或拆分服务非常有帮助。
跨服务的错误排查
- 场景：代码里用 try-catch 吃掉异常，状态码返回 200,但业务不对。
- 处理：在追踪系统里按错误日志搜索，很多追踪系统（如 SkyWalking）会采集跨进程的异常堆栈，即使服务间 RPC 传了通用状态码，也能从追踪上下文看到“服务B抛出 NullPointerException”。
流量与依赖分析
- 场景：线上告警说 Redis 连接数满了。
- 处理：在拓扑图中查看哪个服务对 Redis 调用量最大，发现是一个“日志清洗服务”突然发版，导致其并发量暴增，把 Redis 连接池打满了。
高级用法与注意事项
- 采样策略：全量采样会极大影响性能（I/O 和存储），生产环境建议用自适应采样或百分比采样（如 1% 的记录全量 Span，或者只采样请求时间超过 100ms 的）。
- 上下文传递：如果你使用异步线程池（
@Async）或者 消息队列，需要手动传递 Trace ID，例如在 MQ 消息的 Header 中挂载sw8（SkyWalking）或uber-trace-id（Jaeger）。 - 不限于 HTTP：不仅要追踪 HTTP 请求，还要追踪 gRPC、MQ（Kafka/RabbitMQ）、RPC（Dubbo/Thrift）、数据库、缓存 的调用。
- 与日志系统打通：这是最实用的技巧之一，在打印日志时，将 Trace ID 输出到日志中（如
logback的 MDC 机制）。- 效果：你在 Kibana 搜索日志，看到一条报错日志，可以直接拿着这条日志里的 Trace ID，去链路追踪系统里看这个请求完整经过了哪些服务、数据库语句是什么。
在微服务中使用全链路追踪，核心就是一句话：“一键追踪一个请求的完整生命周期”。
- 小团队（1-5人）：可以选 SkyWalking，十分钟就能搭起来，零代码侵入,省心。
- 大团队（需要定制化或非Java服务多）：可以使用 OpenTelemetry + Jaeger，灵活性更高,但需要一定的定制开发成本。
实际落地的第一步：不用管业务逻辑，先把 Agent 挂上去，部署好后端，从拓扑图看起。 有了可视化依赖图后，你会发现微服务里那些“看不见的线”瞬间清晰了。
