
概述
由于分布式系统节点众多,排查错误日志要涉及到多个节点,如果在多个节点中没有唯一的请求id来把各个节点的请求日志串联起来,那么查询起来就会耗时耗力,因此Spring Sleuth出现了(Spring Sleuth基于Google dapper论文实现,详细了解可以查看此论文),Sleuth会在接收请求的入口通过Filter生成唯一的标识TraceId,这个TraceId会一直跟随请求路径传递到各个节点,只要有日志输出就会把TraceId的值打印出来,如下图(正常还会生成SpanId,为了便于理解没展现)

假如线上发生问题,要排查日志,那么根据这个TraceId,就能够快速查询到各个节点对应的请求日志,但是唯一的遗憾是异步执行会丢失TraceId,因此这里介绍异步跨线程下如何保证TraceId不丢失的问题
我们在官方文档中找到了异步传递Traceid说明,如下图

大致意思Sleuth默认支持@Async传递TraceId,并且支持spring.sleuth.async.enabled进行控制,同时提供了
LazyTraceExecutorTraceableExecutorServiceTraceableScheduledExecutorService
线程包装类,来支持跨线程传递TraceId,其中TraceableScheduledExecutorService是ScheduledExecutorService类的实现,用于实现定时任务触发,个人觉得这种需求不是特别多,所以只介绍常用的一些配置,比如@Async配置、线程池配置、EventBus配置,具体查看后续章节
Asnc配置
默认Sleuth是支持@Async注解异步传递TraceId的,但是如果自定义线程池,配置不对的情况可能就会导致失效,因为Spring在这快有个bug,详细了解请查看以下链接:
所以正确配置方法有如下3种
配置方法
方式1(推荐)
这里用到了Sleuth的LazyTraceExecutor包装了线程池,这样可以保证trace对象传到下一个线程中
@Configuration
@EnableAsync
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class SpringAsyncConfig extends AsyncConfigurerSupport {
@Autowired
private BeanFactory beanFactory;
@Override
public Exec

本文介绍了在Spring Cloud中如何确保在异步跨线程操作中不丢失TraceId,通过Spring Sleuth提供的配置和包装类,如LazyTraceExecutor,确保日志链路追踪的连续性。详细讲解了Asnc配置、线程池配置和EventBus配置的方法,并通过测试案例验证了TraceId在异步场景下的传递效果。
3441

被折叠的 条评论
为什么被折叠?



