一、标记透传的两个核心问题

全链路压测在线上环境运行时，压测流量必须与真实用户流量隔离，这依赖于一个压测标记能够在整条调用链路中完整传递。标记透传需要解决两个独立的问题：跨线程传递（同一服务内部，标记在线程切换时不丢失）和跨服务传递（标记通过网络在上下游服务间流转）。这两个问题的技术栈完全不同，需要分别选型。—## 二、跨线程透传：ThreadLocal 的三级演进### ThreadLocal：线程隔离但无法跨线程ThreadLocal 为每个线程维护独立的变量副本，通过 ThreadLocalMap（key 为 ThreadLocal 实例，value 为存储对象）实现线程间隔离。这解决了线程内变量共享的问题，但父线程设置的值在子线程中无法获取：javaprivate static final ThreadLocal<Integer> flagThreadLocal = new ThreadLocal<>();// 子线程中 flagThreadLocal.get() 返回 null### InheritableThreadLocal：解决父子线程，但线程池场景失效InheritableThreadLocal 在创建子线程时将父线程的变量值复制过去，解决了父子线程传递问题。但线程池会复用线程，复用的线程在创建时已经完成了变量复制，后续提交的任务拿到的是旧线程的变量值，而非当前父线程的值。模拟 10 个并发请求向线程池提交任务时，子线程输出的父线程名称与 index 无法一一对应——这在全链路压测中是致命的，会导致压测标记错乱。### TransmittableThreadLocal（TTL）：线程池场景的完整解决方案阿里开源的 TTL 在提交任务到线程池时，将当前父线程的变量值快照传递给子任务，而不是依赖线程创建时的复制。使用时需要用 TtlRunnable.get() 包装 Runnable：javaprivate static final TransmittableThreadLocal<Integer> INHERITABLE_THREAD_LOCAL = new TransmittableThreadLocal<>();// 提交任务时包装threadPool.submit(TtlRunnable.get(new BusinessThread(parentThreadName)));验证结果：子线程输出的 index 与父线程完全一致，线程池复用场景下变量传递正确。结论：跨线程透传直接选 TTL，跳过前两个方案。—## 三、跨服务透传：五种方案的对比### 方案一：接口参数传递将压测标记作为接口参数追加到每个请求中。实现简单，但对业务侵入性极强——每新增或修改一个接口都需要同步修改参数，维护成本随服务数量线性增长。不推荐。### 方案二：HttpRequest Header 传递自定义 Filter 从请求 Header 中提取压测标记，存入 ThreadLocal，再通过 Feign Client 的 execute() 方法在调用下游服务前将标记写入 Header：javaServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();HttpServletRequest request = requestAttributes.getRequest();String header = request.getHeader("headerKey");优点是对业务透明。但有三个限制：存在父子线程时无法从 RequestContextHolder 获取标记；仅适用于 HTTP 协议，Thrift、Dubbo 等 TCP RPC 框架不适用；消息队列异步场景无法覆盖。适合纯 HTTP 微服务且无异步场景的项目。### 方案三：改造 TraceIdSleuth 的 TraceId 通过 B3 协议在服务间传递（X-B3-TraceId、X-B3-SpanId 等 Header），可以通过修改 TraceId 的格式来携带压测标记——例如正常请求以 1 开头，压测请求以 2 开头：正常：b3: 1000000000000000e457b5a2e4d86bd1-e457b5a2e4d86bd1压测：b3: 2000000000000000e457b5a2e4d86bd1-e457b5a2e4d86bd1实现上通过 Sleuth 2.x 的 ExtraFieldPropagation 或 3.x 的 BaggagePropagation 注入自定义传播工厂。但这个方案有明显缺陷：改造后的 TraceId 与正常 TraceId 格式相似，容易混淆，且存在随机重复的风险；每次 Spring 或 Sleuth 升级都需要重新修改源码；后期维护困难，交接成本高。最终被放弃。### 方案四：字节码增强（Java Agent）通过 -javaagent 参数或运行时 attach，将 SDK 注入目标应用，在框架层完成 TTL 埋点，业务代码完全无感知。可以将 SDK Jar 包打入 Base 镜像，应用启动前自动完成埋点，实现热升级。优点是零业务侵入，支持热升级。缺点是开发门槛高，SDK 引入可能引发包冲突，适合有中台能力的团队统一推进。### 方案五：Sleuth BaggageBaggage 是 Span Context 中的 key-value 存储，随 Trace 一起传递，每个子 Span 自动继承父 Span 的 Baggage。配置方式：yamlspring: sleuth: baggage-keys: baz,bizarrecase # HTTP 调用时加 baggage- 前缀 propagation-keys: foo,upper_case # 透传到远程服务，无前缀 local-keys: local-flag # 仅本地传播，不经过网络原生兼容 RestTemplate、Feign 等 Spring Cloud 组件，实现成本低。但 Baggage 数据量过大会影响性能；底层仍使用 ThreadLocal，跨线程场景需要额外配合 TTL 增强；与 Sleuth 版本强绑定，升级时需重新适配。—## 四、选型决策框架| 维度 | 推荐方案 | 适用条件 ||------|---------|---------|| 跨线程透传 | TransmittableThreadLocal | 所有场景，直接选 || 跨服务（纯 HTTP，无异步） | HttpRequest Header | 技术栈简单，快速落地 || 跨服务（含消息队列/RPC） | Sleuth Baggage | 已有 Sleuth，需覆盖多协议 || 跨服务（零侵入，团队有中台能力） | Java Agent | 多服务统一改造，长期维护 || 跨服务（不推荐） | 改造 TraceId / 接口参数 | 维护成本高，不建议选择 |实际项目中，跨线程和跨服务方案需要组合使用：TTL 解决线程池场景，Sleuth Baggage 或 Header 方案解决服务间传递，两者并不互斥。选型时的核心考量是：项目的协议复杂度（纯 HTTP vs 多协议混合）、团队的基础设施能力（是否有 Agent 托管能力）、以及对业务代码侵入性的容忍程度。