请求ID全链路追踪

请求ID，在分布式系统里也叫Trace ID或Request ID，是贯穿一次用户请求在所有服务节点间流转的唯一标识。很多人以为在网关层生成一个UUID塞进请求头就算完事了，结果真到排查问题时，日志搜不出来、链路串不起来、上下游对不上号。问题的根源不在于“有没有ID”，而在于这个ID在整条调用链路上的生成、传递、继承和存储规则是否统一。下面直接讲落地层面的具体做法，不绕弯子。

请求ID必须在流量入口的第一跳就生成，不能在业务代码里现用现造。通常这个入口是网关、负载均衡器或者前端Web服务器的拦截器。生成时机越早越好，理想状态是请求到达服务进程的第一行代码就拿到ID。如果用了Nginx或Kong这类网关，建议在网关层直接生成并注入Header，后端服务只负责读取，不负责创建。这样做的好处是，即使后端某个服务崩溃，网关日志里仍然保留了请求ID，排查入口问题时有据可查。

生成算法上，不建议用简单的数据库自增ID或纯时间戳。推荐使用符合RFC 4122规范的UUID v4或带时间戳有序性的UUID v7，也可以用Snowflake变种算法生成全局唯一的64位长整型。关键点在于，这个ID必须满足全局唯一、生成性能高、且能携带粗略的时间信息。像Snowflake生成的ID，高位是时间戳，天然支持按时间范围检索日志，比纯随机UUID在排查时方便很多。

请求ID要在几十个微服务之间无损传递，靠的是统一的传递协议。业界有三种主流做法，各有适用场景。第一种是HTTP Header透传，约定一个固定Header名称，比如X-Request-Id或X-Trace-Id，所有服务从请求头读取，向下一跳发送时原样带上。这种方式最简单，适合纯HTTP同步调用场景。第二种是gRPC Metadata传递，在gRPC的Context中携带键值对，利用拦截器自动注入和提取。第三种是消息队列的消息头传递，在Kafka或RabbitMQ的消息Header中嵌入请求ID，消费者取出后继续向后传递。

实际落地时，这三种机制往往同时存在。一个请求可能从HTTP进入，经过gRPC调用内部服务，再发一条MQ消息触发异步处理。要保证ID不丢失，必须在框架层面做统一抽象。做法是定义一个TraceContext对象，封装请求ID和调用链信息，在HTTP拦截器、gRPC拦截器和MQ消费者处理逻辑中，统一从入口提取并写入ThreadLocal或协程上下文。所有业务代码通过工具类静态方法获取当前请求ID，而不是到处手动解析Header。这样无论调用链路多复杂，ID都能无缝流转。

光有请求ID还不够，一次请求在单个服务内部可能并发调用多个下游，或者内部有多个处理阶段。如果所有日志都只打同一个请求ID，排查时根本分不清是哪个下游调用出了问题。所以需要引入Span ID，也就是子调用ID。请求ID标识整条调用链，Span ID标识链路上的每一个独立操作节点。一个服务接收到请求后，除了继承上游的请求ID，还要为自己这次处理生成一个新的Span ID。当它调用下游时，下游又会生成自己的Span ID，同时把当前Span ID作为父Span ID传下去。

生成Span ID同样要求全局唯一，但长度可以比请求ID短，通常用64位随机数或UUID的前半部分就够了。关键是要维护好父子关系。在日志里同时打印请求ID、当前Span ID和父Span ID，就能完整还原调用拓扑。很多团队直接用OpenTelemetry这类标准来实现，底层原理就是这套机制。如果自研，务必在RPC框架和数据库访问层埋点，自动生成Span ID并写入上下文，避免依赖开发人员手动埋点导致遗漏。

有了请求ID和Span ID，如果日志格式不统一，检索效率依然上不去。排查问题时，最常用的操作就是拿一个请求ID搜出所有相关日志，然后按时间排序还原调用过程。这就要求日志必须是结构化的JSON格式，每一行日志都固定包含请求ID和Span ID字段。推荐在日志框架的配置里直接定义全局字段，比如Logback的MDC或Log4j2的ThreadContext，把请求ID和Span ID在请求进入时自动塞进去，所有日志输出自动带上，不用每行日志手动拼接。

日志级别也要规范。入口处收到请求和返回响应时打INFO日志，记录请求方法、URL、状态码和耗时。调用下游前后打DEBUG日志，记录下游服务名、接口名、请求参数和响应结果。异常捕获时打ERROR日志，必须带上完整的异常堆栈和当前请求上下文。这样一套组合下来，拿到一个请求ID，就能从入口到出口完整复盘每一次请求的完整路径，中间哪个环节慢了、哪个环节报错了，一目了然。

全链路追踪最容易断的地方，不是跨服务，而是服务内部的异步线程切换。一个请求进来，主线程开了个异步任务去处理，如果线程池里的工作线程拿不到请求ID，那异步部分的日志就成了孤岛，出了问题上哪都找不到。解决这个问题的核心是上下文传递机制。Java生态里可以用TransmittableThreadLocal，它能解决线程池复用场景下的上下文丢失问题。Go语言里用context.Context，在goroutine创建时显式传入。其他语言也有类似机制，核心思想就一条：任何线程或协程切换点，都必须显式地把TraceContext传递过去。

具体实现上，建议对线程池进行封装，提供一个支持上下文传递的ExecutorService或协程启动器。业务代码提交任务时，框架自动把当前请求的TraceContext快照保存下来，任务执行时自动恢复到新线程的上下文中。这样业务开发人员完全无感知，异步逻辑的日志也能自动带上正确的请求ID和Span ID。定时任务这类没有天然请求上下文的场景，需要在任务启动时生成一个新的请求ID，作为本次任务执行的追踪标识，同样遵循结构化日志规范。

请求ID不能只在应用层流转，数据库、缓存、消息队列这些中间件的访问也需要被追踪。做法是在数据库连接池层面做拦截，执行SQL前生成一个Span ID，记录SQL语句和参数，执行后记录耗时和影响行数。Redis访问同理，在Jedis或Lettuce客户端封装一层，记录命令、Key和耗时。MQ发送和消费更是重点，生产者发送消息时把当前请求ID和Span ID写入消息Header，消费者取出后恢复上下文，并生成新的Span ID作为消费操作标识。

这些埋点如果全靠业务代码手动加，不仅工作量大，而且容易遗漏。正确的做法是在基础设施层统一封装，通过AOP切面或中间件拦截器自动完成。比如MyBatis的Interceptor、RedisTemplate的RedisCallback封装、Kafka的ProducerInterceptor和ConsumerInterceptor。封装好后，所有数据库和缓存操作自动带上追踪信息，排查慢查询或缓存穿透问题时，直接用请求ID就能关联到具体的SQL或Redis命令。

现实场景中，一个业务流程经常跨越多个独立系统，比如从自研系统调用第三方SaaS服务，或者对接合作伙伴的开放平台。第三方系统不会认你生成的请求ID，它们有自己的ID体系。这时候需要建立ID映射关系。在调用第三方接口时，记录下你的请求ID和Span ID，同时把第三方返回的Request ID或业务流水号也记录下来，形成一对多的映射关系。在日志里把双方ID都打出来，后续排查时就能双向关联。

更进一步，可以建立一个轻量级的映射存储，比如用Redis记录请求ID与第三方流水号的对应关系，设置合理的过期时间。当第三方回调或异步通知回来时，根据通知里携带的流水号反查出原始请求ID，把回调处理也串进原始调用链里。这样即使跨越了组织边界，核心链路的追踪依然完整。注意这个映射存储不能成为性能瓶颈，建议异步写入，查询时做好缓存降级。

全链路追踪产生的数据量非常庞大，如果每个请求的完整链路数据都存储，成本会高得难以承受。需要引入采样策略，在保证问题排查能力的前提下控制数据量。常规做法是全部请求都在日志里保留请求ID和关键节点日志，但详细的链路追踪数据只采样存储。采样策略可以分两层：入口层固定比例采样，比如10%的请求记录完整链路；同时保留异常强制采样，任何返回状态码异常或耗时超过阈值的请求，无论是否命中采样比例，都完整记录。

存储方案上，日志和链路数据分开处理。日志走ELK或Loki这类日志系统，按时间索引，保留周期根据磁盘容量设定，通常7到30天。链路追踪数据走Jaeger或Zipkin这类专用存储，支持按请求ID精确检索和调用拓扑展示。两者通过请求ID打通，日常排查看日志，需要分析调用链路时再跳转到追踪系统查看详情。这样既满足了绝大部分排查需求，又不会让存储成本失控。

全链路追踪体系搭建完成后，不能靠人工抽查验证，必须建立自动化验证机制。在测试环境部署一个专门的验证服务，它作为链路起点，发送一个携带特定标记的请求，这个请求会依次经过所有核心服务，每个服务在收到请求后向验证服务回报自己的处理情况和携带的请求ID。验证服务汇总所有回报，检查请求ID是否一致、Span ID父子关系是否正确、是否有服务缺失回报。这套验证可以集成到CI/CD流水线里，每次发布前自动跑一遍，确保追踪体系没有退化。

线上也要有监控告警。统计每分钟内请求ID缺失的请求比例，如果超过阈值就告警。检查日志中请求ID的格式是否符合规范，防止有服务用了自定义ID覆盖了标准ID。这些监控指标可以直接从网关日志和采样链路数据中提取，配置在Prometheus这类监控系统里，配合Grafana面板实时展示追踪覆盖率。只有把追踪体系本身也纳入可观测性范畴，才能保证它在关键时刻真正可用。