dubbo异步调用问题解决方案

q411832953 2020-07-07 06:42:35
场景描述:客户端远程异步调用ServiceA,ServiceA在处理客户端请求的过程中需要远程同步调用ServiceB,ServiceA从ServiceB的响应中取数据时,得到的是null,对就是这个坑。
使用DEBUG模式,分析Dubbo源码得到问题的起因。
分析过程如下:
客户端和服务端通信,配置使用netty进行网络传输,通过NettyHandler进行具体的消息收发操作,所以从此入手进行源码分析。
client到ServiceA的远程方法异步调用,会在RpcContext(RpcContext是一个临时状态记录器,当接收到RPC请求,或发起RPC请求时,RpcContext的状态都会变化。比如:A调B,B再调C,则B机器上,在B调C之前,RpcContext记录的是A调B的信息,在B调C之后,RpcContext记录的是B调C的信息)的attachments(Map结构)属性中添加async=true的键值对,同时也会在RpcInvocation的attachments(Map结构)中添加async=true的键值对。
经过一系列的Filter,程序运行到AbstractInvoker的invoke方法,注意该方法中的如下代码段,
Map<String, String> context = RpcContext.getContext().getAttachments();
if (context != null) {
invocation.addAttachmentsIfAbsent(context);
}
这里会把当前RpcContext中的attachments添加到调用ServiceB的RpcInvocation中,这时候async=true已经添加了,接着执行如下代码段,
if (getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false)){
invocation.setAttachment(Constants.ASYNC_KEY, Boolean.TRUE.toString());
}
上面代码判断调用ServiceB的URL中是否含有async=true,如果有将设置async=true到RpcInvocation的attachments中,这时候是不包含的。
继续跟踪代码,运行到DubboInvoker中,调用doInvoke方法,该方法中有如下的代码段,boolean isAsync = RpcUtils.isAsync(getUrl(), invocation),这个isAsync方法具体声明如下,
public static boolean isAsync(URL url, Invocation inv) {
boolean isAsync ;
//如果Java代码中设置优先.
if (Boolean.TRUE.toString().equals(inv.getAttachment(Constants.ASYNC_KEY))) {
isAsync = true;
} else {
isAsync = url.getMethodParameter(getMethodName(inv), Constants.ASYNC_KEY, false);
}
return isAsync;
}
上面方法首先判断RpcInvocation的attachments中async=true是否成立,如果成立则这是一次异步调用,否则判断请求URL中async=true是否成立,如果成立则是一次异步调用,否则是一次同步调用,根据上面传递的参数,此时isAsync方法返回的是true,ServiceA同步调用ServiceB变成了异步调用,继续看下面的异步调用,代码段如下,
else if (isAsync) {
ResponseFuture future = currentClient.request(inv, timeout) ;
RpcContext.getContext().setFuture(new FutureAdapter<Object>(future));
return new RpcResult();
}
这里直接返回了一个RpcResult对象,没有数据内容,所以到这里,这个案子也就破了,ServiceA想从响应中取目标数据得到的当然是null。再延伸一下,如果ServiceB再同步调用ServiceC,这是可以正常同步调用的,因为ServiceA调用完ServiceB后,ConsumerContextFilter的invoke方法会清除attachements,所以ServiceB可以正常同步调用ServiceC了。

对于上面的问题,解决办法有三个:
1.方法调用两次,所以不推荐
ServiceA调用ServiceB的地方写两次一样的调用,这个方法原理就像ServiceB调用ServiceC一样,即清除attachements,这个方法最简单,但是可能对不了解的人来说,这块业务代码写重复了,会不小心删除掉,而且从写代码的角度来说,这个很鸡肋,所以不推荐。
2.修改Dubbo源码
修改AbstractInvoker第137行,改成每次都对async进行实际赋值,
boolean isAsync = getUrl().getMethodParameter(invocation.getMethodName(), Constants.ASYNC_KEY, false);
invocation.setAttachment(Constants.ASYNC_KEY, String.valueOf(isAsync));
3.自定义Filter
实现com.alibaba.dubbo.rpc.Filter,在RpcContext中清除这个async,

@Activate(group = {Constants.PROVIDER})
public class AsyncFilter implements Filter {
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
RpcContext.getContext().getAttachments().remove(Constants.ASYNC_KEY);
return invoker.invoke(invocation);
}
}
同时在src/main/resources/META-INF/dubbo/下添加com.alibaba.dubbo.rpc.Filter文件,内容文件如下:
asyncFilter=com.abc.filter.AsyncFilter

<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />
调度器 Dispatcher 调度策略
all:所有消息都派发到线程池,包括请求,响应,连接事件,断开事件,心跳等,默认。
direct:所有消息都不派发到线程池,全部在 IO 线程上直接执行。
message:只有请求响应消息派发到线程池,其它连接断开事件,心跳等消息,直接在 IO 线程上执行。
execution:只请求消息派发到线程池,不含响应,响应和其它连接断开事件,心跳等消息,直接在 IO 线程上执行。
connection:在 IO 线程上,将连接断开事件放入队列,有序逐个执行,其它消息派发到线程池。
线程池 ThreadPool
fixed:固定大小线程池,启动时建立线程,不关闭,一直持有,默认,200。
cached:缓存线程池,空闲一分钟自动删除,需要时重建。
limited:可伸缩线程池,但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
eager:优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时,优先创建Worker来处理任务。当任务数量大于maximumPoolSize时,将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列)
...全文
166 1 打赏 收藏 转发到动态 举报
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
q411832953 2020-07-07
  • 打赏
  • 举报
回复
亲自测试有效

81,090

社区成员

发帖
与我相关
我的任务
社区描述
Java Web 开发
社区管理员
  • Web 开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧