Dubbo常见问题

谁践踏了优雅 2022-06-11 04:46 198阅读 0赞

开发过程中，Dubbo常见的问题记录。

--------------------

1、常见序列化问题

java.io.InvalidClassException: com.danny.commons.pay_real_time.bean.PRTTradeReqTO; local class incompatible: stream classdesc serialVersionUID = 8302474502096138497, local class serialVersionUID = -3714837712158046691

增删改实体（dubbo入参、返回值）字段，dubbo provider和dubbo consumer双方都需要更新jar，保证双方jar版本一直，否则会报序列化问题。  
最好保证dubbo provider和dubbo consumer加载的.class相同，否则也可能报错。

2、如果A服务依赖B服务，改完B服务中的model，除了重新部署B服务，也要重新部署A服务，否则调用是会报错：  
关键字：Fail to decode request

"exceptionMessage":"com.alibaba.dubbo.rpc.RpcException: 
    Failed to invoke the method getCardTradePackageResult in the service com.danny.service.creditdata. CardTradeDataService. Tried 1 times of the providers [172.30.21.45:4091] (1/1) from the registry zookeeper01.
    lxfintech.com.config:2181 on the consumer 172.30.21.45 using the dubbo version 2.4.10. Last error is: 
    Failed to invoke remote method: getCardTradePackageResult, 
    provider: dubbo://172.30.21.45:4091/com.danny.service.creditdata.CardTradeDataService?
    accepts=1000&anyhost=true&application=com.lxjr.bigdata.core-core-app&buffer=8192&charset=UTF-8&
    check=false&client=netty&default.retries=0&default.timeout=20000&dubbo=2.4.10&
    interface=com.danny.service.creditdata.CardTradeDataService&iothreads=9&
    methods=getCardTradePackageResult&payload=88388608&pid=13125&revision=1.0.0-20170712.065521-291&
    serialization=java&server=netty&side=consumer&timeout=60000×tamp=1499854137330&version=1.0.0-TEST, 
    cause: Fail to decode request due to: RpcInvocation [methodName=getCardTradePackageResult, 
    parameterTypes=[class com.danny.model.parameter.creditdata.cardtrade.CardTradeParameter],
     arguments=null, attachments={ dubbo=2.4.10, input=1698, 
     path=com.danny.service.creditdata.CardTradeDataService, version=1.0.0-TEST}]

总结：只要是decode问题，基本上都是序列化问题，序列化出错

3、dubbo响应超时  
关键字：Waiting server-side response timeout  
消费者调用异常如下：

cause: Waiting server-side response timeout. start time: 2017-07-28 16:38:36.430, end time: 2017-07-28 16:40:36.457, client elapsed: 16 ms, server elapsed: 120010 ms, timeout: 120000 ms,

在dubbo的provider和consumer的配置文件中，如果都配置了timeout的超时时间，dubbo默认以consumer中配置的时间为准

4、DUBBO Thread pool is EXHAUSTED!  
并发测试，500并发下单  
表现：消费者调用生产者超时，生产者端根本没接收到请求。查看dubbo admin 发现服务正常。  
解决：查看服务器(比如jetty)日志，报错：\[DUBBO\] Thread pool is EXHAUSTED。  
active: 500, core: 500, max: 500可以看出线程不够用了，这是找出正在等待的线程，查看原因……

om.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport -  [DUBBO] Thread pool is EXHAUSTED! 
    Thread Name: DubboServerHandler-10.0.0.77:20703, Pool Size: 500 (active: 500, core: 500, max: 500, largest: 500), 
    Task: 5897697 (completed: 5897197), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), 
    in dubbo://10.0.0.77:20703!, dubbo version: 2.5.3, current host: 127.0.0.1 
    16-10-17 00:00:00.033 [New I/O server worker #1-6] WARN  org.jboss.netty.channel.DefaultChannelPipeline -  
    [DUBBO] An exception was thrown by a user handler while handling an exception event ([id: 0x3c650867, 
    /10.0.0.83:53184 => /10.0.0.77:20703] EXCEPTION: com.alibaba.dubbo.remoting.ExecutionException: 
    class com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler error when process received event .), 
    dubbo version: 2.5.3, current host: 127.0.0.1
    com.alibaba.dubbo.remoting.ExecutionException: class com.alibaba.dubbo.remoting.transport.dispatcher.all.AllChannelHandler error when process caught event .

5、com.alibaba.dubbo.remoting.RemotingException: message can not send, because channel is closed  
可能是网络原因，consumer与provider网络不通（在consumer telnet 10.5.118.127:20010 不通）  
其他原因：provider返回的时候，发现调用provider的线程已经关闭了，可能是consumer 设置timeout时间太短

com.alibaba.dubbo.remoting.RemotingException: message can not send, because channel is closed . url:dubbo://10.5.118.127:20010/com.happycommunity.business.api.user.UserBusinessService?anyhost=true&application=happycommunity-gateway&check=false&codec=dubbo&dubbo=2.6.2&generic=false&heartbeat=60000&interface=com.happycommunity.business.api.user.UserBusinessService&methods=login,register&pid=51701&revision=1.0-SNAPSHOT&side=consumer&timeout=30000&timestamp=1544433498918&version=1.0.0

6、Dubbo传输数据过大的问题  
当dubbo服务提供层向消费层传输大数据容量的对象时，会受到Dubbo的限制，报类似如下异常

cause: java.io.IOException: Data length too large: 9191772, max payload: 8388608, channel: NettyChannel [channel=[id: 0x2b9e3863, /10.10.16.218:57000 => /10.10.13.37:40784]]\njava.io.IOException: Data length too large: 9191772, max payload: 8388608, channel: NettyChannel [channel=[id: 0x2b9e3863, /10.10.16.218:57000 => /10.10.13.37:40784]]\n\tat com.alibaba.dubbo.remoting.transport.AbstractCodec.checkPayload(AbstractCodec.java:49)\n\tat com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.encodeResponse(ExchangeCodec.java:285)\n\tat com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.encode(ExchangeCodec.java:77)\n\tat com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.encode(DubboCountCodec.java:39)\n\tat com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalEncoder.encode(NettyCodecAdapter.java:81)

常见场景：Excel导出、上传文件。  
原因：因为dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。  
Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务。适用场景：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。  
因此比较高效的做法是带上传下载文件的服务使用hessian协议，去普通的服务使用dubbo协议。