一次「找回」TraceId的问题分析与过程思考

正文

请到「今天看啥」查看全文

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

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

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

• 在美团的各个中间件中埋点，来采集发生调用的调用时长和调用结果等信息，埋点的上下文主要包括传递信息、调用信息、机器相关信息和自定义信息，各个调用链路之间有一个全局且唯一的变量TraceId来记录一次完整的调用情况和追踪数据。
• 在网络间的数据传递中，MTrace主要传递使用UUID异或生成的TraceId和表示层级和前后关系的SpanId，支持批量压缩上报、TraceId做聚合和SpanId构建形态。
• 目前，产品已经覆盖到RPC服务、HTTP服务、MySQL、Cache缓存和MQ，基本实现了全覆盖。
• MTrace支持跨线程传递和代理来优化埋点方式，减轻开发人员的使用成本。

| 2.2 @Async的异步过程追溯

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

1. 需要在配置类上增加@EnableAsync注解；
2. @Async注解可以标记一个异步执行的方法，也可以用来标记一个类表明该类的所有方法都是异步执行；
3. 可以在@Async中自定义执行器。

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

@Configuration
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class ProxyAsyncConfiguration extends AbstractAsyncConfiguration {
 @Bean(name = TaskManagementConfigUtils.ASYNC_ANNOTATION_PROCESSOR_BEAN_NAME)
  @Role(BeanDefinition.ROLE_INFRASTRUCTURE)
  public AsyncAnnotationBeanPostProcessor asyncAdvisor() {
  Assert.notNull(this.enableAsync, "@EnableAsync annotation metadata was not injected");
  //新建一个异步注解bean后置处理器
  AsyncAnnotationBeanPostProcessor bpp = new AsyncAnnotationBeanPostProcessor();
  //如果@EnableAsync注解中有自定义annotation配置则进行设置
  Class extends Annotation> customAsyncAnnotation = 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子类代理，默认为false
  bpp.setProxyTargetClass(this.enableAsync.getBoolean("proxyTargetClass"));
  //设置异步注解bean处理器应该遵循的执行顺序，默认最低的优先级
  bpp.setOrder(this.enableAsync.getNumber("order"));
  return bpp;
 }
}

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

从类图中我们可以直观地看到AsyncAnnotationBeanPostProcessor同时实现了BeanFactoryAware的接口，因此我们进入setBeanFactory()方法，可以看到对AsyncAnnotationAdvisor异步注解切面进行了构造，再接着进入AsyncAnnotationAdvisor的buildAdvice()方法中可以看AsyncExecutionInterceptor类，再看类图发现AsyncExecutionInterceptor实现了MethodInterceptor接口，而MethodInterceptor是AOP中切入点的处理器，对于interceptor类型的对象，处理器中最终被调用的是invoke方法，所以我们重点看看invoke的代码逻辑：

public Object invoke(final MethodInvocation invocation) throws Throwable {
 Class> targetClass = (invocation.getThis() != null ? AopUtils.getTargetClass(invocation.getThis()) : null);
 Method specificMethod = ClassUtils.getMostSpecificMethod(invocation.getMethod(), targetClass);
 final Method userDeclaredMethod = BridgeMethodResolver.findBridgedMethod(specificMethod);
  //首先获取到一个线程池
 AsyncTaskExecutor executor = determineAsyncExecutor(userDeclaredMethod);
 if (executor == null) {
  throw new IllegalStateException("No executor specified and no default executor set on AsyncExecutionInterceptor either");
 }
  //封装Callable对象到线程池执行
 Callable

我们再接着看看@Async用了什么线程池，重点关注determineAsyncExecutor方法中getExecutorQualifier指定获取的默认线程池是哪一个：

@Override
@Nullable
protected Executor getDefaultExecutor(@Nullable BeanFactory beanFactory) {
 Executor defaultExecutor = super.getDefaultExecutor(beanFactory);   
 return (defaultExecutor != null ? defaultExecutor : new SimpleAsyncTaskExecutor()); //其中默认线程池是SimpleAsyncTaskExecutor
}

至此，我们了解到在未指定线程池的情况下调用被标记为@Async的方法时，Spring会自动创建SimpleAsyncTaskExecutor线程池来执行该方法，从而完成异步执行过程。

| 2.3. “丢失”TraceId的原因

回顾我们之前对MTrace的学习和了解，TraceId等信息是在ThreadLocal中进行传递和保存，那么当异步方法切换线程的时候，就会出现下图中上下文信息传递丢失的问题：

下面我们探究一下ThreadLocal有哪些跨线程传递方案？MTrace又提供哪些跨线程传递方案？SimpleAsyncTaskExecutor又有什么不一样？逐步找到“丢失”TraceId的原因。

2.3.1 InheritableThreadLocal、TransmittableThreadLocal和TransmissibleThreadLocal

在前面的分析中，我们发现跨线程场景下上下文信息是保存在ThreadLocal中发生丢失，那么我们接下来看看ThreadLocal的特点及其延伸出来的类，是否可以解决这一问题：

• ThreadLocal主要是为每个ThreadLocal对象创建一个ThreadLocalMap来保存对象和线程中的值的映射关系。当创建一个ThreadLocal对象时会调用get()或set()方法，在当前线程的中查找这个ThreadLocal对象对应的Entry对象，如果存在，就获取或设置Entry中的值；否则，在ThreadLocalMap中创建一个新的Entry对象。ThreadLocal类的实例被多个线程共享，每个线程都拥有自己的ThreadLocalMap对象，存储着自己线程中的所有ThreadLocal对象的键值对。ThreadLocal的实现比较简单，但需要注意的是，如果使用不当，可能会出现内存泄漏问题，因为ThreadLocalMap中的Entry对象并不会自动删除。
• InheritableThreadLocal的实现方式和ThreadLocal类似，但不同之处在于，当一个线程创建子线程时会调用init()方法：

private void init(ThreadGroup g, Runnable target, String name,long stackSize, AccessControlContext acc,Boolean inheritThreadLocals) {
 if (inheritThreadLocals && parent.inheritableThreadLocals != null)
  //拷贝父线程的变量
 this.inheritableThreadLocals =ThreadLocal.createInheritedMap(parent.inheritableThreadLocals); 
 this.stackSize = stackSize;
 tid = nextThreadID();
}

这意味着子线程可以访问父线程中的InheritableThreadLocal实例，而且在子线程中调用set()方法时，会在子线程自己的inheritableThreadLocals字段中创建一个新的Entry对象，而不会影响父线程中的Entry对象。同时，根据源码我们也可以看到Thread的init()方法是在线程构造方法中拷贝的，在线程复用的线程池中是没有办法使用的。

• TransmittableThreadLocal是阿里巴巴提供的解决跨线程传递上下文的InheritableThreadLocal子类，引入了holder来保存需要在线程间进行传递的变量，大致流程我们可以参考下面给出的时序图分析：

请到「今天看啥」查看全文