项目场景：
最近在与电信做交维的时候, 由于一些原因, 项目挂了. 然后甲方爸爸让我们这边负责追查问题并且解决 (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进程一直还在提供服务 ( 勤劳的老代码~ )
