Dubbo项目中No provider available for the service xxx from registry xxx on the consumer问题的解决思路
Dubbo项目中No provider available for the service xxx from registry xxx on the consumer问题的解决思路
项目场景：
最近在与电信做交维的时候, 由于一些原因, 项目挂了. 然后甲方爸爸让我们这边负责追查问题并且解决 (ps: 好想做回甲方爸爸~~)
问题描述：
遇事不决, 重启大法好. 首先先祭出公司祖传的运维文档, 然后把项目重新启动...一顿操作下去, 发现我们的这个基于Dubbo+SSM的项目还是嗝屁了...启动依然报错,consumer项目日志如下(草! 一种植物)
Caused by: com.alibaba.dubbo.rpc.RpcException: Failed to invoke the method saveProject in the service
com.clife.ctcc.iot.service.h5.interfaces.h5edit.AppUiDesignService. No provider available for the service
com.clife.ctcc.iot.service.h5.interfaces.h5edit.AppUiDesignService from registry zk.open.clife.com:2181 on the consumer 192.168.232.xx using
the dubbo version 2.5.3. Please check if the providers have been started and registered.
at com.alibaba.dubbo.rpc.cluster.support.AbstractClusterInvoker.checkInvokers(AbstractClusterInvoker.java:246) ~[dubbo-2.5.3.jar:2.5.3]
at com.alibaba.dubbo.rpc.cluster.support.FailoverClusterInvoker.doInvoke(FailoverClusterInvoker.java:55) ~[dubbo-2.5.3.jar:2.5.3]
at com.alibaba.dubbo.rpc.cluster.support.AbstractClusterInvoker.invoke(AbstractClusterInvoker.java:227) ~[dubbo-2.5.3.jar:2.5.3]
at com.alibaba.dubbo.rpc.cluster.support.wrapper.MockClusterInvoker.invoke(MockClusterInvoker.java:72) ~[dubbo-2.5.3.jar:2.5.3]
at com.alibaba.dubbo.rpc.proxy.InvokerInvocationHandler.invoke(InvokerInvocationHandler.java:52) ~[dubbo-2.5.3.jar:2.5.3]
at com.alibaba.dubbo.common.bytecode.proxy1.saveProject(proxy1.java) ~[na:2.5.3]
at com.clife.ctcc.iot.api.h5.controller.web.H5EditController.saveProject(H5EditController.java:337) ~[H5EditController.class:na]
... 45 common frames omitted原因分析：
前提: 确认配置文件没有改动(已确认), 配置文件的改动很容易就会导致项目重启失败! 因为该项目是基于Dubbo, 所以我们首先确认dubbo中哪些节点可用.(全部可用,部分可用还是全部不可用) 1.进入zookeeper的cli, 找到对应服务注册的地方, 查看是否有服务提供者与服务消费者的信息.如下图
2. 经过多次查看,发现h5项目的服务消费者接口注册了, 服务提供者项目没有注册. 而另一个module项目启动则无问题, 消费者和提供者接口都注册了 3. 经过上一步确认, 可以发现已经确认是h5项目的问题, 那么我们需要到这个项目对应的日志下,查看项目的日志信息
4. 根据上面的日志信息, 找到关键内容 Could not autowire field: private com.clife.ctcc.iot.service.h5.utils.FileUploadUtil com.clife.ctcc.iot.business.h5.service.h5edit.AppPanelTemplateServiceImpl.fileuploadutil
解决方案：
- 上面出现Could not autowire field, 说明在代码中已经将FileUploadUtil注入了(但注入是有问题的)
- 在代码中找到这个类被那个类锁注入(ctrl+shift+f),如下图
- 可以发现,这种写法是有问题的, 因为你本来就已经导包了, 可以直接引用了, 但是你又在spring容器中去注入.而且在h5的项目中又找不到这个文件上传的工具类( 因为他被存放到底层的service项目中了,打包后不在一个jar下面的类无法被直接注入!!! )
- 基于如上分析,将注解@Autowired去掉, 打包上传重启一条龙即可~~~ 重启后,发现zk下面项目的服务提供者就注册好了, 一旦能够注册好就说明可以被服务消费者调用了
- 果不其然,去h5项目下查看日志, 发现日志中无异常. 向甲方爸爸报告以后, 也没木得问题了
反思：
在遇到Dubbo项目启动异常后, 必须确认配置文件是否改动, 如果改动了需要分析改动是否合理 确认没有改动后就要去zk确认哪些项目的提供者接口或者消费者接口出现问题, 然后去出现异常的项目中去认真分析启动日志(不要太过依赖百度!!!), 根据日志确认项目的问题. 最后进行相关改动然后,打包上传重启一条龙就OVER啦~~~
ps: 如果你也有交维的经验, 你可能会有一个疑问, 为什么之前提交项目后项目运行没问题, 但是项目挂掉重启就有问题了? 看看下面的图, 相信你就会找到答案
从图上可以看到, 因为之前在19年使用Java用户启动的h5进程没有关闭, 然后今年5.12使用root用户启动的h5进程无论有没有注册到dubbo上, 都不会影响其使用, 因为之前的h5进程一直还在提供服务 ( 勤劳的老代码~ )