服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

问题背景 在微服务架构中，链路追踪是排查问题的关键手段。通过 TraceID，我们可以将分布式系统中各个服务的日志串联起来，还原完整的请求链路。然而，当业务代码中存在异步调用时，你可能会遇到这样的问题： 2024-01-15 10:00:00.001 [http-nio-8080-exec-1] INFO OrderService - [traceId=abc-123] 创建订单成功 2024-01-15 10:00:00.050 [async-thread-1] INFO PaymentService - [traceId=null] 支付处理中 2024-01-15 10:00:00.100 [async-thread-2] INFO NotifyService - [traceId=null] 发送通知 可以看到，主线程中有 TraceID，但在异步线程中丢失了。这导致我们无法将整个链路的日志关联起来，排查问题时只能看到零散的日志片段。 为什么会丢失？ ThreadLocal 局限：MDC 底层使用 ThreadLocal 存储 TraceID，而 ThreadLocal 的....

公司排查一个异步任务异常，在 ELK 里搜对应的 requestId，搜出来的日志只有主线程的。异步线程里的日志一条都没搜到——因为 MDC 里的 requestId 根本没有传到异步线程里。异步线程打出来的日志，requestId 是空的。一整条调用链在异步这个节点断掉了。 问题很直接：@Async 用一个线程池执行任务，但 MDC 是基于 ThreadLocal 的，ThreadLocal 不会自动从主线程传到子线程。异步线程里 MDC.get("requestId") 返回 null，日志里就少了这条 key。 今天聊聊怎么用 TransmittableThreadLocal（TTL）把主线程的上下文透传到异步线程里。 为什么 ThreadLocal 不行，TTL 就行 ThreadLocal 的一个基本特性：子线程拿不到父线程的值。 主线程里 MDC.put("requestId", "abc123")，然后 @Async 开一个新线程去执行，新线程里 MDC.get("requestId") 是 null。 一个直觉的解法是调用线程池时手动传参数。把 requestId ....

导语 在分布式系统中，任务的执行往往跨越多个服务和组件，如何追踪任务的完整执行链路，了解每一步的执行状态和耗时，是系统可观测性的重要组成部分。本文将介绍如何在SpringBoot应用中实现任务执行的链路追踪和TraceID透传，从任务调度到执行完成，实现全链路的可观测性。通过这种方式，您可以实时监控任务的执行状态，快速定位问题，提高系统的可靠性和可维护性。 一、任务执行链路追踪的概念 1.1 什么是链路追踪 链路追踪（Distributed Tracing）是一种用于监控和观察分布式系统中请求或任务执行过程的技术。它通过为每个请求或任务分配一个唯一的标识符（TraceID），并在整个执行过程中传递这个标识符，从而实现对整个执行链路的追踪。 1.2 任务执行链路的特点 1. 跨服务 任务执行可能涉及多个微服务 不同服务之间需要传递上下文信息 需要追踪任务在不同服务中的执行状态 2. 异步执行 任务可能是异步执行的 执行过程可能涉及消息队列 需要追踪异步操作的完整链路 3. 长时间运行 任务可能运行时间较长 需要实时监控任务的执行状态 需要记录任务的执行历史 1.3 链路追踪的....