分布式链路追踪是什么？TraceId、SpanId 有什么作用？
简化版
分布式链路追踪用于跟踪一次请求在多个服务之间的完整调用路径，帮助定位慢接口、错误来源和依赖瓶颈。TraceId 标识一次完整请求链路，Span 表示链路中的一次调用或一个操作，SpanId 标识当前操作，ParentSpanId 表示父子关系。通过在 HTTP/RPC/MQ 中透传上下文，就能把网关、服务、数据库、缓存等调用串成一条 Trace。
详细版
微服务系统一次请求可能经过网关、用户服务、订单服务、库存服务、支付服务。如果只看单个服务日志，很难知道整体耗时花在哪里。链路追踪会在入口生成 TraceId，并在每次内部调用时创建 Span，记录服务名、操作名、开始时间、耗时、状态、标签和日志事件。
TraceId 负责把同一次请求的所有 Span 关联起来，SpanId 和 ParentSpanId 负责描述调用树。采集后的数据可以展示拓扑、关键路径、慢调用和错误节点。
工程上要关注采样率、上下文透传、异步任务和 MQ 场景、日志关联、性能开销以及敏感字段脱敏。链路追踪通常和指标、日志一起构成可观测性体系。
完整版教学
一、为什么需要链路追踪
单体应用里，一个请求大多在一个进程内完成，查日志相对容易。微服务拆分后，一次请求可能跨越十几个服务，每个服务都有自己的日志、线程池和机器。如果用户反馈下单慢，只看订单服务日志可能看不出是库存慢、支付慢还是优惠券慢。
链路追踪解决的是“请求到底走过哪里、每一步耗时多少、在哪一步失败”。它把分散在多个服务里的调用片段串起来，让工程师能从全局视角看问题。
二、Trace 和 Span 的关系
Trace 表示一次完整请求链路。比如用户点击提交订单，从网关进入，到订单、库存、支付、消息队列，这整条路径就是一个 Trace。TraceId 是这条链路的唯一标识。
Span 表示链路中的一个操作，可以是一次 HTTP 调用、一次 RPC 调用、一次数据库查询、一次缓存访问或一次消息消费。SpanId 标识当前操作，ParentSpanId 指向父操作。多个 Span 通过父子关系组成调用树，就能看出谁调用了谁。
三、上下文如何透传
链路追踪能串起来，关键是上下文透传。入口服务生成 TraceId，调用下游时把 TraceId、当前 SpanId、采样标记等放进 HTTP Header、RPC Metadata 或消息属性。下游收到后继续创建子 Span，并把同一个 TraceId 传给更下游。
异步和 MQ 场景更容易断链。生产者发送消息时要把追踪上下文写入消息 header，消费者处理时从 header 恢复上下文。线程池异步任务也要传递上下文，否则日志里 TraceId 会丢失。
四、链路追踪能定位哪些问题
第一是慢调用。Trace 可以展示每个 Span 的耗时，快速发现时间花在数据库、远程服务还是缓存。第二是错误传播。某个下游返回错误，上游跟着失败，Trace 能看到第一个异常点。第三是依赖拓扑。通过大量 Trace，可以分析服务之间的调用关系和依赖强度。
链路追踪还可以帮助容量治理。比如发现某个接口每次请求都会调用某依赖 20 次，就可能存在 N+1 查询或循环 RPC 问题。没有 Trace，这类问题只看单点指标很难发现。
五、采样和性能开销
链路追踪会带来额外开销，包括生成 Span、上下文传递、数据上报、存储和查询。如果全量采集高流量接口，成本可能很高。因此通常会使用采样。采样可以是固定比例、按错误全采、按慢请求全采、按业务关键接口提高采样率。
采样要注意一致性。同一条 Trace 要么尽量完整采集，要么会变成断裂片段。很多系统会在入口决定是否采样，并把采样标记沿链路透传。
六、面试追问与工程边界
常见追问是链路追踪和日志、指标的区别。指标适合看整体趋势，如 QPS、错误率、P99；日志适合看具体事件和业务字段；Trace 适合看一次请求的跨服务路径。三者互补，不是谁替代谁。
另一个追问是 TraceId 是否等于请求 ID。很多场景可以共用，但严格说 TraceId 是可观测性链路标识，请求 ID 可能是业务请求标识。日志里最好同时打印 TraceId 和业务单号，排查时既能按链路查，也能按订单查。
七、落地设计清单
链路追踪要落地，首先要统一上下文格式。HTTP Header、RPC Metadata、MQ Header、异步线程上下文都要能传递 TraceId、SpanId、采样标记。只在 HTTP 入口生成 TraceId 还不够，如果线程池、消息队列、定时任务没有透传，链路会在最需要排查的地方断掉。
其次要和日志打通。每条关键日志都应该打印 TraceId，最好同时打印业务单号、用户 ID 或订单号。这样排查时可以从报警指标进入 Trace，从 Trace 跳到日志，再从日志定位业务数据。Trace 还应该记录关键标签，如接口名、下游服务、错误码、租户、机房、版本号，但要避免记录手机号、身份证、Token 等敏感数据。
八、常见误区和性能边界
第一个误区是全量采集所有 Trace。小系统可以全量，大流量系统全量采集会带来存储和查询压力。更合理的是基于采样：正常请求低比例采样，错误请求和慢请求提高采样，核心链路单独加大采样。采样策略要沿链路透传，否则一个 Trace 只采到一半，价值会下降。
第二个误区是只看 Trace 不看指标。Trace 适合分析单次请求路径，但整体容量、错误率和延迟趋势要靠指标；具体业务字段和异常堆栈要靠日志。可观测性不是三选一，而是指标发现异常，Trace 缩小范围，日志定位细节。面试中能讲出这个组合，会比只背 TraceId 和 SpanId 更完整。
九、常见误区与追问
这道题不能只背概念，要把「分布式链路追踪」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 链路追踪用 TraceId 串起一次请求跨服务的所有 Span，帮助定位慢点和错误传播路径 | 不要停在名词解释 |
| 流程机制 | 入口生成 TraceId -> 每次跨服务传递上下文 -> 服务内创建 Span -> 记录耗时错误标签 -> 上报采样数据 -> 查询链路拓扑定位问题 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 一次下单请求经过网关、订单、库存、支付 4 个服务，应共享同一个 TraceId，每段调用生成 Span | 治理组件是为了控制故障半径，不是让下游无限扛流量 |
分布式链路追踪 面试拆解：
1. 入口生成 TraceId
2. 每次跨服务传递上下文
3. 服务内创建 Span
4. 记录耗时错误标签
5. 上报采样数据
6. 查询链路拓扑定位问题记忆钩子：先定位治理目标，再拆限流、熔断、降级、重试、追踪、灰度和幂等边界；回答时要紧扣「分布式链路追踪」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：日志里有 requestId 就等于链路追踪。 追踪还包含 Span 层级、耗时、依赖关系和采样上报。
- 误区：TraceId 每个服务重新生成。 同一次请求必须传递同一个 TraceId，否则链路断裂。
- 误区：全量采样永远最好。 高 QPS 下全量采样成本高，通常按比例、错误优先或动态采样。
- 追问：TraceId 和 SpanId 区别是什么？ TraceId 标识整条链路，SpanId 标识链路中的一次操作。
- 追问：如何跨线程传递 TraceId？ 使用上下文包装、线程池装饰器或框架集成，避免 ThreadLocal 丢失。
- 追问：OpenTelemetry 解决什么？ 提供统一的 Trace、Metric、Log 采集语义和跨厂商标准。
十、加强记忆
链路追踪就是“给一次请求画路线图”。TraceId 串起整条请求，Span 表示每一步操作，ParentSpanId 表示父子关系。上下文要在 HTTP、RPC、MQ、线程池中透传。它和指标、日志一起构成可观测性：指标看趋势，日志看细节，Trace 看路径。