dubbo调用问题之序列化

问题描述

dubbo的版本是2.5.3，接口调用后，provider方接收不到请求，超时后报错：Waiting server-side response timeout by scan timer.详细日志如下：

Failed to invoke the method getBalanceCheckOriginalList in the service com.bosssoft.thirdpay.bkengine.domain.service.adapt.IBalanceSearchAdaptService. Tried 1 times of the providers [192.168.63.16:20894] (1/1) from the registry 127.0.0.1:2182 on the consumer 192.168.63.16 using the dubbo version 2.5.3. Last error is: Invoke remote method timeout. method: getBalanceCheckOriginalList, provider: dubbo://192.168.63.16:20894/com.bosssoft.thirdpay.bkengine.domain.service.adapt.IBalanceSearchAdaptService?anyhost=true&application=zxepay-domain-web&check=false&default.check=false&default.retries=0&default.timeout=15000&dubbo=2.5.3&interface=com.bosssoft.thirdpay.bkengine.domain.service.adapt.IBalanceSearchAdaptService&methods=getBalanceCheckOriginalList&pid=14396&revision=0.1.0-SNAPSHOT&serialization=java&side=consumer&timestamp=1553599591068, cause: Waiting server-side response timeout. start time: 2019-03-26 19:28:03.089, end time: 2019-03-26 19:28:18.121, client elapsed: 25 ms, server elapsed: 15004 ms, timeout: 15000 ms, request: Request [id=0, version=2.0.0, twoway=true, event=false, broken=false, data=RpcInvocation[methodName=getBalanceCheckOriginalList, parameterTypes=[class com.bosssoft.thirdpay.bkengine.domain.model.check.CheckRequestModel],arguments=[com.bosssoft.thirdpay.bkengine.domain.model.check.CheckRequestModel@1170222a], attachments={path=com.bosssoft.thirdpay.bkengine.domain.service.adapt.IBalanceSearchAdaptService, interface=com.bosssoft.thirdpay.bkengine.domain.service.adapt.IBalanceSearchAdaptService,timeout=15000, version=0.0.0}]], channel: /192.168.63.16:54137 -> /192.168.63.16:20894

分析

通过dubbo admin查看providers和consumers，可以找到服务，双方状态正常，dubbo版本也一致。 其实如果接口的provider方异常，调用方直接会收到类似于No provider available 或Forbid consumer access service from registry use dubbo version 2.5.3, Please check registry access list (whitelist/blacklist)的错误提示。
然后，查看接口请求参数，发现其实现了java序列化接口，和错误日志中的序列化方式一致。

后来测试时发现，竟然存在部分请求成功，着重分析后发现请求对象数据存在差异，请求对象的类定义中部分自定义域没有实现序列化接口。之前调用成功的请求中，其请求参数中未实现序列化的字段值为null。后来测试当整个请求参数不实现序列化时，发现接收方也可以收到请求。

结论

跨服务调用时，传参必须实现序列化，其内部引用的对象也必须序列化。

常见问题总结

1.方法的参数没有实现序列化，或其内部引用的对象没有实现序列化。
2.方法返回值没有序列化。（根据错误日志就能看明确发现）
3.调用双方形参版本不一致。（根据错误日志就能看明确发现）
4.注册中心配置错误导致的异常。（根据错误日志或dubbo admin可以明确发现）
5.网络异常导致的超时。