Dubbo之RpcContext详解

阅读更多
一、RpcContext简介
    RpcContext 是一个 ThreadLocal 的临时状态记录器,当接收到 RPC 请求,或发起 RPC 请求时,RpcContext 的状态都会变化。
    比如:A调B,B再调C,则B机器上,在B调C之前,RpcContext记录的是A调B的信息,在B调C之后,RpcContext记录的是B调C的信息。

二、RpcContext的使用
    消费端
// 远程调用之前,通过attachment传KV给提供方
RpcContext.getContext().setAttachment("userKey", "userValue");
// 远程调用
xxxService.xxx();
// 本端是否为消费端,这里会返回true
boolean isConsumerSide = RpcContext.getContext().isConsumerSide();
// 获取最后一次调用的提供方IP地址
String serverIP = RpcContext.getContext().getRemoteHost();
// 获取当前服务配置信息,所有配置信息都将转换为URL的参数
String application = RpcContext.getContext().getUrl().getParameter("application");
// 注意:每发起RPC调用,上下文状态会变化
yyyService.yyy();
// 此时 RpcContext 的状态已变化 
RpcContext.getContext();  


    服务端
public class XxxServiceImpl implements XxxService {

    public void xxx() {
        // 通过RpcContext获取用户传参,这里会返回userValue
        String value = RpcContext.getContext().getAttachment("userKey");
        // 本端是否为提供端,这里会返回true
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
        // 获取调用方IP地址
        String clientIP = RpcContext.getContext().getRemoteHost();
        // 获取当前服务配置信息,所有配置信息都将转换为URL的参数
        String application = RpcContext.getContext().getUrl().getParameter("application");
        // 注意:每发起RPC调用,上下文状态会变化
        yyyService.yyy();
        // 此时本端变成消费端,这里会返回false
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
    } 
}


三、RpcContext原理
    消费端在执行Rpc调用之前,经过Filter处理, 会将信息写入RpcContext.见 ConsumerContextFilter:
Dubbo之RpcContext详解_第1张图片

    服务端在执行调用之前,也会经过Filter处理,将信息写入RpcContext. 见 ContextFilter
Dubbo之RpcContext详解_第2张图片

四、Dubbo异步调用
//配置方式

      


//编程方式
Future future = RpcContext.getContext().asyncCall(new Callable(){...});

//访问服务之后获取异步调用的结果,通过Future.
Future future = RpcContext.getContext().getFuture();
T t = future.get();

五、Dubbo异步调用源码解析
    同步调用:ResponseFuture.get()同步等待返回结果并实时返回。
    异步调用:ResponseFuture放入RpcContext,实时返回一个空的RpcResult实例,后序通过RpcContext.getContext().getFuture() .get()获取返回值。

    详情见 DubboInvoker
Dubbo之RpcContext详解_第3张图片

六、Dubbo异步调用的坑
    异步调用依赖传递性
   
  • 问题表现:如果consumer-A异步调用provider-B,而provider-B本身又调用了provider-C。当provider-B调用provider-C时,会变成异步。
  • 问题原因:是否异步调用取决于RpcContext中async的值,其次才是服务本身的配置。当A调用B时,会把async=true传给B的RpcContext;B调用C时,虽然服务本身async=false,但RpcContext中async=true,自然也就成了异步调用。


    异步回调返回null
   
  • 问题表现:consumer-A调用provider-B,而provider-B本身又调用了provider-C。consumer-A调用provider-B返回null。
  • 问题原因:异步调用直接返回空的RpcResult实例,需要后序通过RpcContext.getContext().getFuture() .get()获取返回值。async透传到provider-B端之后,也是异步调用provider-C,但是直接返回空的RpcResult实例给consumer-A。

    解决方案:别让async参数应用到provider端。
    修改ContextFilter源码,重写RpcContext时删除async参数

Dubbo之RpcContext详解_第4张图片

   
  • Dubbo之RpcContext详解_第5张图片
  • 大小: 72.9 KB
  • Dubbo之RpcContext详解_第6张图片
  • 大小: 96.8 KB
  • Dubbo之RpcContext详解_第7张图片
  • 大小: 169.5 KB
  • Dubbo之RpcContext详解_第8张图片
  • 大小: 131.2 KB
  • 查看图片附件

你可能感兴趣的:(RpcContext,dubbo,异步调用,异步调用的坑,隐式传参)