一、现象

有三个应用serviceA,serviceB,serviceC,在确保消费没有错乱的前提下（都只有单个服务提供者），期望其调用关系为

serviceA dubbo消费serviceB 配置为异步消费async="true"，配置如下：

// serviceA 异步消费serviceB 配置如下
<dubbo:reference id="serviceB" interface="cn.ServiceB"
                     version="1.0.0" check="false">
        <dubbo:method name="reRunJob" async="true"/>
    </dubbo:reference>

// serviceB 同步消费serviceC配置如下
<dubbo:reference id="serviceC" interface="cn.ServiceC"
                     version="1.0.0" check="false">
        <dubbo:method name="xxx"/>
    </dubbo:reference>

然而，上面配置后，实际调用关系变为下图

如上所述，由于B->C 由于dubbo异步配置的传递性，导致变为了异步调用，结果返回了null,导致期望的同步调用结果异常，但是B第二次调用C会正常返回

二、寻找问题根源--源码

1. 我们的排查思路

现象是由于dubbo异步调用，然后服务提供者内部又有dubbo嵌套调用，==所以我们需要找出dubbo的内部嵌套调用是否存在异步传递性==,那么既然是传递，就需要上下文环境，进而，我们想到了dubbo中的上下文环境==RpcContext==，我们推测是由此类传递了异步参数

2. 预备知识：RpcContext简介

RpcContext 是一个 ThreadLocal 的临时状态记录器，当接收到 RPC 请求，或发起 RPC 请求时，RpcContext 的状态都会变化。
比如：A调B，B再调C，则B机器上，在B调C之前，==RpcContext记录的是A调B的信息==，在B调C之后，RpcContext记录的是B调C的信息。

我们知道dubbo的方法调用，都是由invoker代理调用的，我们找到AbstractInvoker，查看底层的invoke方法，源码如下：

public Result invoke(Invocation inv) throws RpcException {
        ··· 省略无关代码
        
        // 这里的代码在此处对我们的serviceB-->serviceC时，会取出RpcContext，语句上面的RpcContext知识储备，我们知道，这里的context存的是serviceA->serviceB的上下文，也就是说是异步的，到这里谜团解开
        Map<String, String> context = RpcContext.getContext().getAttachments();
        if (context != null) {
        	invocation.addAttachmentsIfAbsent(context);
        }
        // 注意此处代码，如果提供者方法配置了异步参数
        if (getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false)){
        // 会将异步参数值设置到当前调用对象中	invocation.setAttachment(Constants.ASYNC_KEY, Boolean.TRUE.toString());
        }
        // 最后再将异步参数存入上下文
        RpcUtils.attachInvocationIdIfAsync(getUrl(), invocation);
        
        
        try {
            return doInvoke(invocation);
        } catch (InvocationTargetException e) {     ···
        } catch (RpcException e) {
            ···
        } catch (Throwable e) {
            ···
        }
    }

3. 上面还有个小问题，serviceB第二次调用serviceC,会正常返回，这又是为什么呢？

这里涉及到一个Filter ConsumerContextFilter 源码如下：

@Activate(group = Constants.CONSUMER, order = -10000)
public class ConsumerContextFilter implements Filter {

    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        RpcContext.getContext()
                .setInvoker(invoker)
                .setInvocation(invocation)
                .setLocalAddress(NetUtils.getLocalHost(), 0)
                .setRemoteAddress(invoker.getUrl().getHost(), 
                                  invoker.getUrl().getPort());
        if (invocation instanceof RpcInvocation) {
            ((RpcInvocation)invocation).setInvoker(invoker);
        }
        try {
            return invoker.invoke(invocation);
        } finally {
           // ①注意这里 ，进行了上下文清理
          RpcContext.getContext().clearAttachments();
        }
    }

}

==如上代码，serviceB第一次调用serviceC结束时，在consumer的filter chain中，有一个ConsumerContextFilter，在调用结束后会执行RpcContext.getContext().clearAttachments()方法，清除RpcContext中的信息，也就清除了async标识==,所以，第二次调用serviceC,就正常==同步==调用了，至此，我们的疑问得到解释

解决方法

分析了问题产生的原因后，在不修改dubbo源码的情况，可以有一下几种处理方式。

将serviceB改为同步调用，如果业务上确实需要异步调用，有以下2种处理方式
serviceB的方法无需返回值，可采用oneway的方式（在消费者端配置dubbo:method中return="false"）
有返回值，并且需要异步，最简单的方式为在实现中使用线程池执行业务。
增加一个Provider端的Filter，保证在filter链的结尾，在执行方法前，清除attachment中的async标志。也可达到同样的效果