微服务架构下慢请求定位，核心手段是用链路追踪把一次请求经过的所有服务用TraceId串起来，再逐个查看Span耗时，慢点通常就藏在耗时最长的Span里。
为什么微服务架构下慢请求比单体难查
单体应用时代，慢请求排查路径简单：看应用日志、查数据库慢查询、分析线程栈，微服务拆开后，一次下单请求可能经过网关、订单服务、库存服务、支付服务、消息队列,甚至异步任务。
- 跨服务调用没有统一请求ID,日志分散在多个节点。
- 每个服务可能独立部署,时间戳不一致。
- 超时、重试、熔断让请求链路发生分叉。
- 中间件（Redis、Kafka、MySQL）的耗时很难直接归因到具体业务请求。
这些因素叠加，单独看某个服务的日志很难判断整体慢在哪一环,链路追踪解决的就是把分散的调用片段拼成一条完整调用链。
链路追踪怎么定位慢接口：从TraceId到Span耗时
链路追踪的基本单位是Trace和Span，一次完整请求对应一个Trace，调用链上每个独立操作（一个HTTP请求、一次数据库查询、一次RPC调用）对应一个Span。
每个Span记录以下关键信息：
- Span ID 和 Parent Span ID：描述父子关系。
- Trace ID：整条链路唯一标识。
- 开始时间与结束时间：计算Span耗时。
- 标签：记录调用方、被调方、方法名、SQL、错误信息等。
- 状态：成功、失败、超时。
实际定位慢请求时,操作路径如下：
- 从网关或前端拿到慢请求的Trace ID。
- 在链路追踪平台（如SkyWalking、Zipkin、Jaeger）输入Trace ID。
- 查看整条Trace的时间瀑布图。
- 按Span耗时降序排列,找到耗时最长的Span。
- 展开该Span查看标签，确认是数据库、下游接口还是本地计算。
- 如果耗时在数据库Span,查看SQL完整语句和执行计划。
- 如果耗时在下游接口Span，继续进入该服务查看子Span,向下钻取。
一个典型场景：用户支付接口耗时4秒，链路追踪显示，订单服务调用库存服务只花了80毫秒，但订单服务内部有一个数据库查询Span耗时3.5秒，进一步查看标签，发现SQL没有走索引，全表扫描,慢点锁定。
业内专家指出，链路追踪真正有价值的不是画出漂亮拓扑，而是把耗时归因到具体Span甚至具体SQL、具体方法。
微服务链路追踪工具对比：开源方案接入成本高吗
选型时常见的几个开源方案有Zipkin、Jaeger、SkyWalking、Pinpoint，以及统一标准的OpenTelemetry,下面用表格对比关键维度。
| 工具 | 数据采集方式 | 存储后端 | 侵入性 | UI能力 | 国内生产环境适配程度 |
|---|---|---|---|---|---|
| Zipkin | Brave/OpenZipkin | MySQL/ES/Cassandra | 低 | 一般 | 中 |
| Jaeger | OpenTracing SDK | Cassandra/ES | 低 | 较好 | 中 |
| SkyWalking | Java Agent为主 | ES/H2/MySQL | 极低 | 强 | 高 |
| Pinpoint | Java Agent | HBase | 极低 | 强 | 中 |
| OpenTelemetry | SDK/Agent | 可对接多种后端 | 中 | 依赖后端 | 逐渐普及 |
行业共识认为，国内生产环境里SkyWalking的落地门槛相对低，因为Java Agent启动即可采集，代码侵入少，中文社区活跃，Jaeger和Zipkin更偏国际生态，需要自己搭采集端，云厂商的托管版链路追踪（如简米云ARMS）按量计费,接入成本要看QPS和留存时长。
“全链路追踪成本高吗”这个问题没有统一答案，开源自建的最大开销在存储和运维，Elasticsearch集群要预留足够磁盘；托管方案用起来省事但长期会产生费用，团队需要根据自己的请求量、保留天数和运维能力来算账。
生产环境慢SQL定位：从Span里抓出高耗时查询
慢SQL是微服务慢请求中的高频根因，链路追踪能直接暴露哪条SQL慢,不需要翻数据库慢日志逐个比对。
以SkyWalking接入Java应用为例,实际落地步骤如下：
- 下载并启动SkyWalking OAP服务和UI。
- 给每个Java服务加上启动参数：
java -javaagent:/opt/skywalking-agent.jar
-Dskywalking.agent.service_name=order-service
-Dskywalking.collector.backend_service=127.0.0.1:11800
-jar order-service.jar在logback配置里加入TraceId占位符,让业务日志和链路对应：
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - [%X{traceId}] %msg%n</pattern>
-
配置采样率，生产环境如果全量采样会带来较大存储压力，通常先设置为10%到30%,慢请求排查时再临时提高。
-
出现慢请求后，在UI里按服务名和时间过滤,找耗时最高的Trace。
-
进入Trace详情,按Span耗时排序。
-
定位到高耗时数据库Span后,点击查看SQL语句。
-
把SQL拿到数据库执行计划里验证，多数情况下能看到索引失效、数据量倾斜、锁等待等情况。
在微服务链路中，Span耗时不等于真正执行SQL的时间，如果Span耗时高但数据库侧显示SQL执行很快，需要检查连接池等待、序列化、网络传输等环节,这是生产环境排查中容易被忽略的细节。
实际定位慢请求时如何避免误判
链路追踪提供的是调用耗时，不等于根因，看到某个Span耗时高,还要结合其他信号验证。
- 数据库Span耗时长：查看SQL、执行计划、连接池指标。
- RPC Span耗时长：检查下游服务的GC停顿、线程池排队、熔断状态。
- 消息队列Span耗时长：区分是发送耗时、消费等待还是批量拉取延迟。
- 网关Span耗时长：排查过滤器、限流、鉴权、响应体大小。
一个真实可操作的定位顺序是：先看整体Trace耗时分布，再确定最耗时的Span类型，最后钻取到具体标签，不要看到服务A调用服务B耗时高就直接下结论是B的问题,因为A可能本身在调用前做了大对象序列化。
链路追踪还能发现隐藏的串行调用，比如一个循环里调了多次库存服务，界面只看到一次调用耗时不高，但Span叠加后总耗时很可观,这就是为什么需要看Trace的时间瀑布图而不是只看单个接口平均耗时。
微服务架构下慢请求定位，核心就是利用TraceId把调用链串起来，再按Span耗时降序找到瓶颈点，无论工具怎么换,这个思路不变。
Q&A
微服务架构下慢请求定位只靠链路追踪够吗？
不够，链路追踪能定位到慢在哪个Span，但根因可能需要日志、指标和APM数据配合，例如Span显示数据库查询慢，还要看慢SQL日志和执行计划；Span显示RPC慢，可能要查下游服务的GC停顿或线程池指标，链路追踪提供的是关联线索,不是最终结论。
链路追踪采样率设置多少合适？
多数生产环境建议10%到30%，全量采样会成倍增加存储和网络开销，低采样率日常看趋势够用，遇到个别慢请求时，可以临时把采样率调高或在入口强制采样，等定位完再恢复，关键是要把采样后丢弃的请求仍然保留TraceId在业务日志中,方便手动检索。
生产环境接入全链路追踪成本高吗？
开源自建的固定成本是服务器、Elasticsearch存储和运维人力，适合请求量稳定且有基础运维能力的团队，云厂商托管版按请求量和存储时长计费，接入快但长期费用会随量增长，国内生产环境使用SkyWalking自建的比例较高，因为Java Agent无侵入、社区案例多，最终成本取决于保留天数和采样率,保留7天和保留30天差别很大。