1. 问题背景和思考

1.1 问题背景

【资料图】

1.2 问题复现和思考

2. 深度分析

2.1 MTrace与Google Dapper

2.2 @Async的异步过程追溯

2.3. “丢失”TraceId的原因

3. 解决方案

4. 其他方案对比

4.1 Zipkin

4.2 SkyWalking

4.3 EagleEye

5. 总结

1. 问题背景和思考

| 1.1 问题背景

在机器中可以清楚的发现“2022-08-02 19:26:34.952 DXMsgRemoteService ”这一行日志信息并没有携带TraceId，导致调用链路信息戛然而止，无法追踪当时的调用情况。

| 1.2 问题复现和思考

在处理完线上告警后，我们开始分析“丢失”的TraceId到底去了哪里？首先在代码中定位TraceId没有追踪到的部分，发现问题出现在一个@Async注解下的方法，删除无关的业务信息代码，并增加MTrace埋点方法后的复现代码如下：

@SpringBootTest@RunWith(SpringRunner.class)@EnableAsyncpublicclassDemoServiceTestextendsTestCase{@ResourceprivateDemoServicedemoService;@TestpublicvoidtestTestAsy(){Tracer.serverRecv(\"test\");StringmainThreadName=Thread.currentThread().getName();longmainThreadId=Thread.currentThread().getId();System.out.println(\"------Wegotmainthread:\"+mainThreadName+\"-\"+mainThreadId+\"TraceId:\"+Tracer.id()+\"----------\");demoService.testAsy();}}@ComponentpublicclassDemoService{@AsyncpublicvoidtestAsy(){StringasyThreadName=Thread.currentThread().getName();longasyThreadId=Thread.currentThread().getId();System.out.println(\"======Async====\");System.out.println(\"------Wegotasythread:\"+asyThreadName+\"-\"+asyThreadId+\"TraceId:\"+Tracer.id()+\"----------\");}}  

运行这段代码后，我们看看控制台实际的输出结果：

------Wegotmainthread:main-1TraceId:-5292097998940230785----------======Async====------Wegotasythread:SimpleAsyncTaskExecutor-1-630TraceId:null----------  

2. 深度分析

| 2.1 MTrace与Google Dapper

MTrace是美团参考Google Dapper对服务间调用链信息收集和整理的分布式链路追踪系统，目的是帮助开发人员分析系统各项性能和快速排查告警问题。要想了解MTrace是如何设计分布式链路追踪系统的，首先看看Google Dapper是如何在大型分布式环境下实现分布式链路追踪。我们先来看看下图一个完整的分布式请求：

回顾这次完整的请求我们不难发现，要想直观可靠的追踪多项服务的分布式请求，我们最关注的是每组客户端和服务端之间的请求响应以及响应耗时，因此，Google Dapper采取对每一个请求和响应设置标识符和时间戳的方式实现链路追踪，基于这一设计思想的基本追踪树模型如下图所示：

除了最基本的span name、span id和parent id之外，Annotations扮演着重要的角色，Annotations包括、Client Send、Server Recv、Server Send、Client Recv和这些注解，记录了RPC请求中Client发送请求到Server的处理响应时间戳信息，其中foo注解代表可以自定义的业务数据，这些也会一并记录到span中，提供给开发人员记录业务信息；在这当中有64位整数构成的trace id作为全局的唯一标识存储在span中。

至此我们已经了解到，Google Dapper主要是在每个请求中配置span信息来实现对分布式系统的追踪，那么又是用什么方式在分布式请求中植入这些追踪信息呢？

为满足低损耗、应用透明和大范围部署的设计目标，Google Dapper支持应用开发者依赖于少量通用组件库，实现几乎零投入的成本对分布式链路进行追踪，当一个服务线程在链路中调用其他服务之前，会在ThreadLocal中保存本次跟踪的上下文信息，主要包括一些轻量级且易复制的信息（类似spand id和trace id），当服务线程收到响应之后，应用开发者可以通过回调函数进行服务信息日志打印。

MTrace是美团参考Google Dapper的设计思路并结合自身业务进行了改进和完善后的自研产品，具体的实现流程这里就不再赘述了，我们重点看看MTrace做了哪些改进：

| 2.2 @Async的异步过程追溯

从Spring3开始提供了@Async注解，该注解的使用需要注意以下几点：

我们以@EnableAsync为入口开始分析异步过程，除了基本的配置方法外，我们重点关注下配置类AsyncConfigurationSelector的内部逻辑，由于默认条件下我们使用JDK接口代理，这里重点看看ProxyAsyncConfiguration类的代码逻辑：

@Configuration@Role(BeanDefinition.ROLE_INFRASTRUCTURE)publicclassProxyAsyncConfigurationextendsAbstractAsyncConfiguration{@Bean(name=TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)@Role(BeanDefinition.ROLE_INFRASTRUCTURE)publicAsyncAnnotationBeanPostProcessorasyncAdvisor(){Assert.notNull(this.enableAsync,\"@EnableAsyncannotationmetadatawasnotinjected\");//新建一个异步注解bean后置处理器AsyncAnnotationBeanPostProcessorbpp=newAsyncAnnotationBeanPostProcessor();//如果@EnableAsync注解中有自定义annotation配置则进行设置ClasscustomAsyncAnnotation=this.enableAsync.getClass(\"annotation\");if(customAsyncAnnotation!=AnnotationUtils.getDefaultValue(EnableAsync.class,\"annotation\")){bpp.setAsyncAnnotationType(customAsyncAnnotation);}if(this.executor!=null){//设置线程处理器bpp.setExecutor(this.executor);}if(this.exceptionHandler!=null){//设置异常处理器bpp.setExceptionHandler(this.exceptionHandler);}//设置是否需要创建CGLIB子类代理，默认为falsebpp.setProxyTargetClass(this.enableAsync.getBoolean(\"proxyTargetClass\"));//设置异步注解bean处理器应该遵循的执行顺序，默认最低的优先级bpp.setOrder(this.enableAsync.getNumber(\"order\"));returnbpp;}}  

ProxyAsyncConfiguration继承了父类AbstractAsyncConfiguration的方法，重点定义了一个AsyncAnnotationBeanPostProcessor的异步注解bean后置处理器。看到这里我们可以知道，@Async主要是通过后置处理器生成一个代理对象来实现异步的执行逻辑，接下来我们重点关注AsyncAnnotationBeanPostProcessor是如何实现异步的：

publicObjectinvoke(finalMethodInvocationinvocation)throwsThrowable{ClasstargetClass=(invocation.getThis()!=null?AopUtils.getTargetClass(invocation.getThis()):null);MethodspecificMethod=ClassUtils.getMostSpecificMethod(invocation.getMethod(),targetClass);finalMethoduserDeclaredMethod=BridgeMethodResolver.findBridgedMethod(specificMethod);//首先获取到一个线程池AsyncTaskExecutorexecutor=determineAsyncExecutor(userDeclaredMethod);if(executor==null){thrownewIllegalStateException(\"NoexecutorspecifiedandnodefaultexecutorsetonAsyncExecutionInterceptoreither\");}//封装Callable对象到线程池执行Callable