我发现一个关于Dubbo服务调用的Bug

理论知识

1.服务方未启动。

成都创新互联公司专注于康巴什企业网站建设,自适应网站建设,商城网站建设。康巴什网站建设公司,为康巴什等地区提供建站服务。全流程按需求定制开发，专业设计，全程项目跟踪，成都创新互联公司专业和态度为您提供的服务

2.代码内客户端和服务端的group、version不匹配。

3.有dubbo tag路由过滤，标签不匹配。

4.动态配置过滤，没有匹配的服务(比如disable等)。

但这次遇到一个非以上问题，因此研究了一番，发现了dubbo在实现上有一些瑕疵。

背景

在做JT808协议指令数据上行指令，指令通过808采集平台(netty长连接)，解析后，通过dubbo调用服务，做指令的业务逻辑处理，奇怪是服务存在，但是却报错No provider available for the service com.xxx.ioc.api.service.JTService，错误截图如下：

我觉得很奇怪，服务明明是启动的，也没有动态配置，为什么服务竟然会很奇怪的找不到呢?然后debug下看了代码，发现是dubbo编码阶段报错。

io.netty.handler.codec.EncoderException: java.lang.RuntimeException: Serialized class com.xxx.ioc.codec.util.KeyValuePair must implement java.io.Serializable Java field: private com.xxx.ioc.codec.util.KeyValuePair com.xxx.ioc.protocol.t808.T0900.message.

原来是参数T009的内部类KeyValuePair未实现序列化导致，但是如果是未实现序列化，应该报错Serialized class xxx must implement java.io.Serializable的错误，但是为什么收到的错误却是No provider available for the service xxx，带着这个问题，分析一波。

分析过程

调用链路根据之前自己分析的dubbo transport层记录，dubbo客户端调用时序图如下(可以参考链接的泳道图)：

dubbo客户端的调用的基本流程说明如下：

客户端经netty pipeline的TailContext处理，业务线程切换到reactor IO线程，业务线程在DefaultFuture.get()阻塞等待响应。
dubbo的编码/解码是在reactor IO线程处理，编码抛出异常，消息不会发送给服务方，此时异常(错误码BAD_REQUEST)被被封装为Response，继而唤醒业务线程在DefaultFuture.get()阻塞等待。

这里有个疑问，编码失败，那么是如何返回响应消息的呢?后面下篇文章分析)，在执行com.alibaba.dubbo.remoting.exchange.support.DefaultFuture#returnFromResponse，把异常信息封装为RemotingException进行抛出，代码如下：

private Object returnFromResponse() throws RemotingException {
    Response res = response;
    if (res == null) {
        throw new IllegalStateException("response cannot be null");
    }
    if (res.getStatus() == Response.OK) {
        return res.getResult();
    }
    if (res.getStatus() == Response.CLIENT_TIMEOUT || res.getStatus() == Response.SERVER_TIMEOUT) {
        throw new TimeoutException(res.getStatus() == Response.SERVER_TIMEOUT, channel, res.getErrorMessage());
    }
    throw new RemotingException(channel, res.getErrorMessage());//序列化异常(错误码BAD_REQUEST)被封装为RemotingException向上抛出
}

重点关注一下调用链中的异常处理：

在com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker#doInvoke内异常被catch，异常信息被封装为RpcException(异常code=NETWORK_EXCEPTION)向上抛。
接着在com.alibaba.dubbo.rpc.protocol.AbstractInvoker#invoke内异常RpcException被catch，由于异常code=NETWORK_EXCEPTION，非业务异常代码，因此异常继续向上抛。
最后异常RpcException在com.alibaba.dubbo.rpc.cluster.support.FailoverClusterInvoker#doInvoke内被catch，由于是failover失效转移策略默认重试2次，因此接着尝试去调用调用其它节点，如果服务的节点数少于重试的次数+1(即3次)，则没有匹配的服务节点，因此在com.alibaba.dubbo.rpc.cluster.support.AbstractClusterInvoker#checkInvokers操作内，会报错No provider available for the service xxx.

详细的代码调用截图如下所示：

因此就淹没了序列化异常，导致真正的异常失真。这也是dubbo错误提示的一点小问题，如果要修复，解决方法也简单：FailoverClusterInvoker新增如下方法：

private void checkInvokers(List> invokers, Invocation invocation, RpcException le) {
    if (invokers == null || invokers.isEmpty()) {
        if (le != null) {
            throw le;
        }
        checkInvokers(invokers, invocation);//请求父类
    }
}

同时修改方法doInvoke如下：

当前名称：我发现一个关于Dubbo服务调用的Bug
浏览路径：http://www.shufengxianlan.com/qtweb/news41/481991.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容