上下文传播的挑战：跨服务、跨线程、异步
做分布式追踪这几年，我踩过最多的坑，就是上下文传播。
说白了，就是一个 TraceId 要从 A 服务跑到 B 服务，中间还得跨个线程池、过个消息队列。你想想看，链路一长，哪个环节丢了这个 ID，整个请求就“失联”了。
我个人习惯把上下文传播的挑战分成三大类：跨服务、跨线程、异步。这三者不是孤立的——很多生产问题都是它们交织在一起导致的。
1. 跨服务传播：协议与契约
服务之间怎么传递上下文？最常见的方式是塞进请求头（Header）。
但实际做起来，问题一个接一个：
- 协议不一致：RPC 用 Thrift，HTTP 用 Header，消息队列用属性。你得在每个协议的拦截器里手工提取和注入。
- 中间件截胡：我记得有一次排查，发现某个网关把自定义 Header 给过滤掉了。嗯，网关层面默认只透传标准 HTTP 头。
- 链路长度限制：有些代理对 Header 大小有限制（比如 Nginx 默认 8KB）。上下文里要是带了全链路 Span 列表，直接就被截断了。
核心原则：跨服务传递时，上下文必须通过协议无关的载体内嵌（例如 W3C Trace Context 标准格式），并且在每个网关、代理层显式放行。
| 协议 | 载体 | 典型字段 | 风险点 |
|---|---|---|---|
| HTTP | Header | traceparent | 中间件过滤、大小限制 |
| gRPC | Metadata | grpc-trace-bin | 客户端/服务端拦截器遗漏 |
| Thrift | Transport Header | 自定义字段 | 序列化兼容性 |
| 消息队列 | 消息属性 | 自定义键值对 | 消息重投递时属性丢失 |
2. 跨线程传播：ThreadLocal 的陷阱
Java 里最常见的做法是 ThreadLocal。服务收到请求，把 TraceId 存进当前线程的 ThreadLocal。然后业务代码一调用线程池——完了，线程变了，上下文没了。
我曾经接手过一个支付系统，下单接口偶尔丢 TraceId。查了两天，发现是某处用了 CompletableFuture.supplyAsync() 但没传递上下文。那个异步任务里如果抛异常，日志里 TraceId 为空，根本关联不到原始请求。
解决方案其实不复杂：
- 在提交任务时，将当前上下文快照+显式传给新线程。
- 使用框架提供的上下文传递包装器（如
ThreadPoolTaskExecutor的TaskDecorator）。 - 或者用
InheritableThreadLocal——但要注意它只在创建线程时继承，池化复用线程会有脏数据。
我个人习惯在线程池提交处统一做一次 ContextSnapshot 的 capture 和 wrap，而不是零散地在每个 Runnable 里手动 set。这样即使新来的同事忘了加，也不会丢上下文。
3. 异步传播：回调、事件与重试
异步场景是上下文丢失的重灾区。为什么？因为异步回调的线程往往不是发起请求的线程。
- 回调地狱：一个异步链路上有好几层嵌套回调，每层都要手动传递上下文，漏一层就断链。
- 事件驱动：事件发布时上下文在生产者线程，监听器在消费者线程执行。如果事件对象里没携带 TraceId，消费者就不知道从哪来的。
- 重试与幂等：重试时一般要重新注入原始上下文，但重试逻辑可能在独立线程池里执行，上下文又得重新绑定。
你可能会问：为什么不把所有异步操作都强制同步化？那性能就没了。所以业界主流做法是：在异步框架层自动传播。比如 Spring Cloud Sleuth 会自动为 @Async 方法、HystrixCommand、Reactor 等提供上下文透传。
但注意，自动传播也有盲区：
- 自定义线程池，框架不一定能识别。
- 对 Kotlin 协程、Vert.x 的 EventLoop 支持需要额外配置。
- 异步 Servlet 的
AsyncContext可能越过标准过滤器。
4. 综合挑战与一张图
下面这张图把三种场景的传播路径和断裂点画在一起了。你仔细看，每个断点都可能让你丢上下文。
5. 实战避坑清单
结合我踩过的那些坑，整理了一份清单，供你开发时对照检查：
- 确认中间件版本：Spring Cloud Gateway 2020.0.x 默认不过滤标准 traceparent，但老版本可能不兼容。
- 测试异步场景：用
ThreadPoolExecutor替换默认线程池后，一定要写个集成测试，看 TraceId 能不能跨线程传递。 - 关注语言边界：跨语言调用（比如 Java ⇔ Go），上下文格式必须统一。建议用 W3C traceparent，别自己造协议。
- 事件溯源陷阱：如果事件重放（replay）也需要追踪，那事件本身必须携带原始上下文。我见过一个系统，重放时所有事件都产生新 TraceId，根本对不上号。
- 不要迷信框架：自动传播能解决 80% 场景，但剩下 20% 需要你显式处理，比如自定义
Executor、Reactor的下游算子。
最重要的一条：上下文传播是“一票否决制”——只要一个环节断了，整条链路就废了。所以上线前一定要做全链路压测，在日志里扫描是否有“TraceId为空”的异常记录。
好了，这一章的重点就是这些。跨服务、跨线程、异步——这三座大山，每个都够呛。但你把每座山的“断裂点”摸清楚，该加的拦截器加好，该做的自动化传播配好，上下文就能稳如老狗。