链路上下文传播的核心就是把同一个请求的Trace ID和Span ID在服务之间无损传递，让分散在各个进程里的日志、耗时和异常都能按同一条调用链拼起来。
链路追踪怎么实现跨服务调用串联
跨服务调用串不起来,最常见的原因不是追踪平台不好用，而是上下文传播在中间某个环节断了，链路追踪里每个请求都像一条快递单号，物流信息分散在不同服务各自的日志里，上下文传播负责把这个单号从揽收到派送一路贴下去。
一次请求进入网关时,追踪SDK会生成一个全局唯一的Trace ID，进入订单服务时，SDK再生成一个Span ID，并记录Parent Span ID为空，订单服务调用库存服务时，把Trace ID和当前Span ID放进HTTP Header，库存服务收到后，以收到的Span ID作为Parent Span ID，生成自己的Span ID，这样就形成了一条父子链：网关Span → 订单Span → 库存Span → 支付Span。
- 常见传递字段：W3C标准的
traceparent、tracestate；Zipkin B3系列的X-B3-TraceId、X-B3-SpanId、X-B3-ParentSpanId；Jaeger原生使用的uber-trace-id。 - 传递载体：HTTP请求头、gRPC Metadata、AMQP消息头、Kafka Record Header。
- 日志配合：每行日志都需要打印Trace ID，否则即使链路数据串起来了，排障还是要单独去翻日志。
搞清楚这个概念后再看代码,服务间调用通常不用自己写传递逻辑，主流的微服务框架和追踪库已经封装好了拦截器，以Spring Cloud为例，只要在过滤器里注册一次，后续RestTemplate和Feign调用就会自动注入和提取，问题多发生在异步线程、定时任务和消息消费这三类场景里，因为这些地方不经过同步HTTP拦截器，上下文容易丢。
微服务链路上下文传播方案对比：SDK埋点还是Agent无侵入
三种常见方案,没有绝对优劣，按团队情况选。
SDK埋点
直接在业务代码里创建Span、激活、结束，控制粒度最细，可以给某个本地方法单独埋点，
Span span = tracer.buildSpan("calculateDiscount").start();
try (Scope scope = tracer.activateSpan(span)) {
// 业务逻辑
} finally {
span.finish();
}
缺点是每个方法都要写重复代码,业务侵入明显，业内专家指出，手动埋点适合核心交易链路，不适合大面积推广，团队需要有人专门维护埋点规范，否则不同人写法不一，Span命名乱七八糟，后面看链路反而更累。
Java Agent自动注入
针对Java服务,通过 -javaagent 参数在启动时加载OpenTelemetry Java Agent，Agent用字节码增强技术给Spring MVC、Dubbo、OkHttp、Kafka Client等主流框架自动加拦截器，业务代码零改动，接入成本低，适合快速验证，缺点是对冷门组件或深度自定义的RPC协议支持有限，需要额外开发插件。
Service Mesh Sidecar注入
在Pod里注入Envoy或类似Sidecar,由代理统一收发流量，Sidecar在七层解析协议，自动注入和提取追踪头，对业务进程完全透明，多语言支持也好，代价是需要维护Sidecar自身，资源开销和升级复杂度都不小，行业共识认为，Service Mesh适合已经建设容器平台和治理体系的企业，小团队起步阶段不必为了链路追踪专门上网格。
| 对比维度 | SDK埋点 | Java Agent | Service Mesh |
|---|---|---|---|
| 接入成本 | 高 | 低 | 中 |
| 代码侵入 | 强 | 无 | 无 |
| 多语言支持 | 看SDK覆盖 | 仅Java为主 | 好 |
| 自定义链路粒度 | 细 | 中 | 粗 |
| 维护复杂度 | 中 | 低 | 高 |
多数情况下,Java微服务团队用Agent方案可以解决大部分串联需求。
分布式链路追踪成本高吗？按需控制落地开销
成本不是只有软件授权费,主要包含三块：存储成本、网络开销、人力维护。
- 存储成本：链路数据一般存Elasticsearch、ClickHouse或Cassandra，数据量由请求量、采样率、Span数量和保留周期决定，开全量采样时，日活请求百万级以上的系统会产生相当可观的写放大，控制手段很直接：普通请求采样1%到10%，错误请求和慢请求100%保留。
- 网络开销：每次RPC多传几十字节到几百字节的追踪头，对服务间调用带宽影响很小，高频消息队列场景要注意，如果每个消息都带追踪信息，Kafka集群的存储和传输压力会叠加，可以对消息链路单独设置采样规则。
- 人力成本：Agent方案接入快，但排查追踪系统本身的问题仍需要有人负责，开源系统如Jaeger、Zipkin、SkyWalking都可以免费部署，但生产环境需要关注采集器高可用和存储膨胀。
上海地区不少企业出于数据合规要求倾向私有化部署,可以在内网用Docker Compose快速拉起Jaeger加Elasticsearch试跑，价格敏感的中小团队可以先只给订单、支付等核心链路接入，验证串联效果后再逐步推开。
Java微服务在上海地区落地链路追踪的实操步骤
用Java微服务为例,选型OpenTelemetry标准和Collector架构，假设服务是Spring Boot，注册中心用Nacos，调用链含网关、订单、库存、支付四个服务。
- 在每个服务的启动脚本或Dockerfile里下载
opentelemetry-javaagent.jar，统一放到/opt/otel/目录。 - 修改 JVM 参数：
-javaagent:/opt/otel/opentelemetry-javaagent.jar
-Dotel.traces.exporter=otlp
-Dotel.exporter.otlp.endpoint=http://otel-collector:4317
-Dotel.service.name=order-service
-Dotel.propagators=tracecontext,baggage
-Dotel.metrics.exporter=none- 网关服务作为第一个入口,需要在入口过滤器里确认Trace ID是否生成，没有Trace ID的请求可以认为是外部流量，SDK会自动创建；内部请求应已携带
traceparent。 - 日志框架增加追踪字段,以Logback为例：
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%traceId] [%spanId] %-5level %logger{36} - %msg%n</pattern>
- 启动OpenTelemetry Collector，配置导出到Jaeger或Zipkin，内网环境可以用
docker compose up -d
- 发一笔包含创建订单、扣库存、创建支付单的真实请求，在Jaeger UI里查看调用链时间线，如果三个服务都出现在同一棵调用树里，说明链路上下文传播已经打通。
串不起来的典型故障排查
- 现象：链路上只有网关和订单服务，库存服务单独一条链，原因通常是库存服务没有读取W3C
traceparent，而是读B3头，统一传播器配置为tracecontext,baggage，并让所有服务保持一致。 - 现象：日志里有Trace ID，但链路平台查不到，原因可能是采样策略导致数据被丢弃，或Collector导出失败，可以先在服务本地开启
otel.logs.exporter=logging打印导出日志。 - 现象：消息队列消费的消息没有Trace ID，需要检查MQ客户端是否传递自定义头，Kafka可配置
header.mode，RabbitMQ需要显式把追踪头写入消息属性。
先把传播协议统一,再把Trace ID打满日志，最后才考虑采样和存储优化，顺序反了，跨服务调用就会时通时断，排查更耗时。
Q&A
链路追踪怎么实现跨服务调用串联？
靠的是统一生成Trace ID，并在每次RPC调用时把Trace ID和当前Span ID通过请求头或消息头传给下游，下游认领后继续创建自己的Span，形成父子关系，所有服务都用同一套传播器配置，链路才能不断。
微服务链路上下文传播方案对比里，中小企业选哪种？
Java技术栈、服务数量在几十个以内，优先选Java Agent自动注入，接入成本最低，已经上了Kubernetes且服务多语言混合的团队，可以考虑Service Mesh，但要接受运维复杂度，SDK手动埋点只适合对链路细节要求极高的核心服务。
分布式链路追踪成本高吗？
对中小规模系统来说,开源方案加上按需采样，成本多数情况下可以接受，只有全量采集、长期保留或超大集群时，存储开销会明显上升，控制成本的关键是核心链路全量、普通链路采样、数据保留周期分级。