记录一次“异常bug”,具体信息以下。主要是记录一下处理过程,可能口水话比较多,若是想看结果,直接日后拉便可。java
最后一行git
起初,运维同事找到我,跟我说程序出问题了,系统升级,一直连不上nacos。spring
我看了日志信息以后,刚开始仍是没有在乎的。毕竟是nacos报错,报错还那么明显:java.net.ConnectException: Connection refused (Connection refused)docker
我信心满满告诉他,是nacos没起起来,或者是配置文件有问题。这不是代码的问题。(这里带有一点点侥幸心理)bootstrap
我很快就被打脸了。其余服务都能起起来,惟独咱们同事写的这个模块出了bug?就是连不上nacos。此时让他们重启nacos,确定是不现实的,毕竟nacos是没问题的。重启这个报错的模块也试过了,可是模块就是一直在重连nacos,而且最终连不上去。springboot
因而我把nacos的加载顺序从新捋一遍。在docker中起服务,首先是加载docker的环境变量,而后替代掉程序中的bootstrap.yml。这里猜想是启动命令的问题。运维
1.当docker容器启动时,获取到容器的环境变量(一般是服务名,nacos地址,nacos命名空间,nacos组,须要的配置文件)。ide
2.jar启动时,会使用容器的环境变量会做为相关参数。(原理能够查询关键词: spring jar 参数)spa
3.springboot启动时会注入相关的参数,从而获取到nacos的配置信息,并将nacos作为配置中心,从nacos上读取相关配置。.net
4.springboot 读到相关配置,其中一个配置是将nacos作为注册中心,将服务注册到nacos上。 (本次异常的发生点)
因而我又去问运维同事容器的启动命令。(由于docker中的环境变量,已经在启动命令中作了映射了,全部咱们只用看运维同事的启动命令便可)
exec java -jar island-serviceconfig.jar --server-addr=sc-nacos:8848 --namespace=public --group=service-cool --config-common=island-common.yaml --config-service=island-serviceconfig.yaml
看着启动命令,我又陷入了沉思,这是怎么操做,必定毛病也没有。就这样,尝试了好几遍。一个下午就没有了。
后面我仔细回味报错信息。这不可能,nacos难道有版本错误?很快被我否认,此次升级系统,从新拉了代码。以前都是好好的,运维那边的nacos版本是没有改动过的。
因而我上去仓库看代码。代码也没有问题,近期没有人修改过。这很郁闷呐。
最后无可奈何,去看了nacos的源码,最后找到了一点点信息,nacos是在咱们没有配置nacos地址的时候,才会去加载localhost:8848这个地址。
那么问题来了,明明咱们配置了nacos地址,为何仍是会去加载localhost:8848?这又回到了原点。又开始怀疑是运维同事的执行命令出了问题,可是确实是没有问题的。
我慢慢静下心来。也许是我一开始的出发点就出问题了。我一直觉得是运维同事部署出了问题,思惟停留在运维那边,丝毫没有怀疑是配置问题的问题。
最终快下班了和另外一个同事讨论,我刚开口描述完问题,他就说了一句:卧槽,我搞了三天。
果真,以前不是好着的,而是有这位同事一直在“擦屁股”,可是git上面的配置问题,他又没有进行更新。致使运维每次拉取代码,都会出现这个问题。具体问题以下
乍一看这配置没啥问题,我以前检查配置文件也是,每次看下去都没有问题,洽洽是个人觉得,致使这个问题没能及时被发现。这就是一个缩进的问题。
正确的配置以下:
最后,感觉一波吐槽,其实最初运维的同事也发现这个缩进有问题,全部他手动改了不少,也反馈了,可是估计开发都很忙,就没有修改git上的配置文件。致使埋下了一颗大雷。好在写代码的同事已经离职(手动狗头保命)
总结:遇到bug不要慌,好好和运维同事作沟通,每一个部门都有本身的规范和要求,像简单的运行命令出了问题,这个仍是很好排查的。切记切记,不要有甩锅心理,不要有甩锅心理,不要有甩锅心理。
此次很明显,运维同事就是被咱们开发摆了一道,这也是开发这边没有注意的问题,或者说,这是不该该出现的问题,属于比较低等的问题。饶是如此,咱们也要重视起来,不然一个小小的雷,埋久了,他也是会发酵的,威力愈来愈大。