分布式链路追踪的原理是什么？
简化版
分布式链路追踪的原理是：在请求入口生成 TraceId，每经过一个服务或关键操作就创建 Span，并把 Trace 上下文通过 HTTP Header、RPC Metadata、消息头等方式传给下游。各服务把 Span 数据上报到追踪后端，后端按 TraceId 和父子关系聚合成完整调用链。
它解决的是跨服务请求无法定位路径和耗时的问题，让工程师能看到一次请求经过哪些服务、每段耗时多少、错误发生在哪一段。
详细版
链路追踪通常包含埋点、上下文传播、数据采集、数据上报、后端存储和查询展示几个环节。入口服务创建根 Span，下游服务收到 Trace 上下文后创建子 Span。每个 Span 记录开始结束时间、服务名、操作名、状态、标签和异常信息。
上下文传播是关键。如果 TraceId 没有传到下游，下游创建的 Span 就无法和上游关联，调用链会断。不同协议有不同传播方式，例如 HTTP Header、gRPC Metadata、MQ Message Header。
采集到的 Span 会通过 SDK、Agent 或 Collector 上报到 Jaeger、Zipkin、SkyWalking、Tempo 等系统。追踪系统再把 Span 组装成调用树和时间线，用于定位慢调用、错误链路和依赖关系。
完整版教学
一、链路追踪要解决什么问题
分布式系统中，一次请求跨多个服务。用户看到的是一个接口慢或失败，但服务端可能涉及多个进程。没有链路追踪时，只能分别登录每个服务查日志，靠时间和关键字猜测调用关系。
链路追踪让每一次请求都有一条可视化路径。它回答三个关键问题：请求经过了哪些服务，每段耗时多少，错误发生在哪里。
二、入口生成 Trace 上下文
请求进入系统时，入口组件通常创建 TraceId 和根 Span。入口可能是网关、BFF、RPC 服务端或消息消费者。
根 Span 表示整次入口处理，它记录请求路径、方法、状态码、开始结束时间等信息。之后所有下游 Span 都属于同一个 TraceId。
如果上游已经带了 TraceId，比如外部网关或前端监控传入，服务可以继续使用该 TraceId，形成更完整的端到端链路。
三、每个关键操作创建 Span
服务处理请求时，会在关键边界创建 Span：服务入口、RPC 调用、HTTP 调用、数据库访问、缓存访问、消息发送等。
例如订单服务处理一次下单，可能创建：订单接口 Span、调用库存 Span、写数据库 Span、发送订单消息 Span。每个 Span 记录自己的耗时和状态。
这些 Span 不只是为了画图，它们让排查人员知道慢在哪里。如果总耗时 800ms，其中库存调用 600ms，瓶颈就很清楚。
四、上下文传播是链路不断的关键
TraceId、SpanId、采样标记等信息需要传给下游。HTTP 可以放在 Header，gRPC 可以放在 Metadata，消息队列可以放在 Message Header。
如果某个服务没有继续传播上下文，下游 Span 就会变成新的 Trace，原链路中断。排查时会看到调用树缺了一截。
因此链路追踪不仅是采集 Span，还要保证跨协议传播一致。OpenTelemetry 提供了统一的上下文传播规范和 SDK，降低了多语言、多框架接入成本。
五、Span 数据如何上报和存储
服务产生 Span 后，可以由 SDK 直接上报，也可以先发送给 Collector。Collector 负责接收、处理、采样、转换和转发数据，再写入追踪后端。
使用 Collector 的好处是业务进程和后端解耦。后端换成 Jaeger、Tempo 或其他系统时，业务代码不必大改；采样和过滤策略也可以集中配置。
追踪后端根据 TraceId 聚合 Span，根据 ParentSpanId 构建调用树，并提供查询页面。
六、链路追踪的成本和采样
全量追踪很有价值，但成本也高。高 QPS 系统如果每个请求都记录大量 Span，会增加 CPU、网络和存储压力。
所以追踪系统通常使用采样。常见策略包括固定比例采样、错误优先采样、慢请求采样、按接口或租户采样。关键是不能为了省成本把最有价值的异常链路丢掉。
采样策略设计不好，会导致排查故障时正好查不到问题请求。
七、面试回答建议
回答时按流程讲：入口生成 TraceId 和根 Span；服务内部创建 Span；Trace 上下文通过 Header 或 Metadata 传播；Span 上报到 Collector 或后端；后端按 TraceId 和父子关系组装调用链。
再补充采样、上下文传播断链和日志关联，就能体现工程完整性。
八、常见追问和落地边界
面试官可能追问自动埋点和手动埋点的区别。自动埋点适合覆盖框架层通用边界，比如 HTTP、RPC、JDBC、Redis、Kafka；手动埋点适合补充业务关键步骤，比如库存预占、风控决策、优惠计算。真实系统通常两者结合。
还有一个落地问题是时钟偏差。分布式链路跨多台机器，如果机器时间不同步，Trace 时间线可能看起来错乱。因此生产环境要依赖 NTP 等机制保持时间同步，追踪系统也要能容忍少量偏差。
九、常见误区与追问
这道题要紧扣「分布式链路追踪原理」本身回答，不能把它混成泛泛的可观测性套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖日志、指标、追踪、上下文传播、采样、告警和排障闭环。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 链路追踪通过 Trace 串联一次请求的所有 Span，记录服务调用、耗时、错误和父子关系 | 不要停在名词解释 |
| 流程机制 | 入口创建 Trace -> 每次调用创建 Span -> 传播上下文 -> 记录耗时和状态 -> 采样上报后端 -> 查询拓扑和瓶颈 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 一次下单请求可能包含网关 20ms、订单 80ms、库存 120ms、支付 200ms，Trace 能定位慢点在支付 | 可观测性不能替代稳定性设计，它用额外采集、存储和分析成本换更快定位问题 |
分布式链路追踪原理 面试拆解：
1. 入口创建 Trace
2. 每次调用创建 Span
3. 传播上下文
4. 记录耗时和状态
5. 采样上报后端
6. 查询拓扑和瓶颈记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「分布式链路追踪原理」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：链路追踪就是打印日志。 追踪有父子关系、时间线和跨服务上下文，日志只是事件文本。
- 误区：所有请求都必须全量采样。 高流量系统全量采样成本高，通常按比例或规则采样。
- 误区：有 Trace 就一定能定位根因。 还要结合日志、指标、依赖状态和业务上下文。
- 追问：Trace 和 Span 区别？ Trace 表示一次完整请求，Span 表示其中一个操作或调用片段。
- 追问：如何定位慢调用？ 看 Trace 时间线中耗时最长或等待最多的 Span。
- 追问：链路断裂常见原因？ 上下文未传递、异步丢失、采样不一致或代理未接入。
十、加强记忆
链路追踪可以记成“给每次请求发一张通行证”。请求走到哪里，哪里盖章记录耗时和状态；最后把所有章按通行证编号收集起来，就得到完整路线图。
TraceId 是通行证编号，Span 是每个检查点的盖章记录。