Trace ID 在跨服务链路中如何传播？
简化版
Trace ID 通过标准传播头随 HTTP/RPC 请求传递，消息系统则写入 header；接收方提取父上下文并创建新 span，再把新上下文注入下游。跨信任边界要校验和限制 baggage，不能把业务秘密放入传播字段。
详细版
优先使用 W3C Trace Context 的 traceparent/tracestate，由框架自动注入与提取；线程池、异步任务和回调需要显式保存并恢复 context。消息一对多或延迟消费可用 span link 表达因果，重试创建新 span 并保留 attempt。
无合法父上下文时创建新 Trace；日志自动写 traceId/spanId。监控无父 span、传播失败、非法 header 和链路完整率，防止日志框架手工生成另一个 correlationId 与 Trace 脱节。
完整版教学
一、Trace 与 Span 标识
同一 Trace 的 span 共享 traceId，每个 span 有独立 spanId，并引用 parentSpanId 或 link。traceId 标识整条因果链，不能拿一个固定 ID 跨多次业务复用。
记忆钩子：提取父上下文，创建当前 span，注入新上下文，再调用下游。
二、HTTP 传播
traceparent: 00-<32hex trace-id>-<16hex parent-id>-01服务端校验格式和长度，创建 server span；客户端发送前创建 client span 并注入其上下文。不得把收到的 parent spanId 直接当自己的 spanId。
三、线程与异步边界
ThreadLocal 在线程池切换后不会自动正确传播，且可能残留上一个请求。任务提交时捕获 context，执行时 attach，finally 中 detach；优先使用框架 instrumentation。
若异步工作在原请求结束很久后执行，使用 link 往往比制造持续数小时的父子 span 更准确。
四、消息传播
生产者将 context 写入消息 header，消费者提取后创建 consume/process span。多个消费者组各自创建 span 并 link 同一生产 span，表达一对多而不共享可变 span。
| 场景 | 建议关系 | 原因 |
|---|---|---|
| 同步 RPC | parent-child | 调用时序直接 |
| 短异步队列 | parent/link | 按工具语义 |
| 批量消费 | 多个 links | 一批含多个来源 |
| 重放 | link original | 区分新执行 |
五、Baggage 的风险
Baggage 会沿链路复制，大小和基数会放大网络与存储；只放必要的路由上下文，不放 token、邮箱和订单详情。跨组织入口按允许清单过滤，防止外部伪造调试或采样标志。
业务参数应走正常请求体，不能把 baggage 当分布式数据库。
六、采样与日志关联
即使 Trace 未采样，也可传播合法上下文以保持下游一致决策；但后端未必存到 Trace。日志关联组件从当前 context 注入 traceId/spanId，避免业务代码到处手写。
监控 propagation success、orphan span、invalid context 和 sampled ratio；用合成请求跨多服务验证完整链路。
异步任务持久化上下文时还要保存创建时间与原始操作标识，避免数天后仅凭 traceId 无法区分重放和首次执行。
传播库升级应做跨语言兼容测试，尤其检查大小写、header 编码和代理是否会过滤标准字段。
Trace ID 不应作为授权依据；攻击者知道或伪造 ID 不能获得查看对应 Trace 的权限。
七、常见误区与追问
- 误区：每个服务重新生成 Trace ID 更安全。 会切断端到端关联。
- 误区：只传 Trace ID 就够了。 还需当前 parent span 和采样信息。
- 误区：ThreadLocal 在线程池天然安全。 需要显式传播与清理。
- 误区：Baggage 可以放任意业务字段。 会泄密并放大成本。
- 追问：非法 traceparent 怎么办？ 丢弃并创建新 Trace，同时记录安全计数。
- 追问：批量消息如何建模？ 一个处理 span 链接多个消息上下文。
- 追问：重试是否复用 span？ 新建 attempt span，关联原操作并记录次数。
八、加强记忆
传播流程是“extract—start—inject—end”，同步用父子关系，异步一对多和重放用 link 表达。标准头由框架处理，线程池显式附着与清理，baggage 受信任边界和大小约束；再用孤儿 span 与合成链路持续验证完整性。