nacosConnectionrefused（Connectionrefused）
记录⼀次“异常bug”，具体信息如下。主要是记录⼀下处理过程，可能⼝⽔话⽐较多，如果想看结果，直接往后拉即可。
最后⼀⾏
起初，运维同事到我，跟我说程序出问题了，系统升级，⼀直连不上nacos。
我看了⽇志信息之后，刚开始还是没有在意的。毕竟是nacos报错，报错还那么明显：java.ConnectException: Connection refused (Connection refused)
我信⼼满满告诉他，是nacos没起起来，或者是配置⽂件有问题。这不是代码的问题。(这⾥带有⼀点点侥幸⼼理)
我很快就被打脸了。其他服务都能起起来，唯独我们同事写的这个模块出了bug?就是连不上nacos。此时让他们重启nacos，肯定是不现实的，毕竟nacos是没问题的。重启这个报错的模块也试过了，但是模块就是⼀直在重连nacos，并且最终连不上去。
于是我把nacos的加载顺序重新捋⼀遍。在docker中起服务，⾸先是加载docker的环境变量，然后替代掉程序中的l。这⾥猜测是启动命令的问题。
配置的读取过程
spring怎么读取配置
1.当docker容器启动时，获取到容器的环境变量（通常是服务名，nacos地址，nacos命名空间，nacos组，需要的配置⽂件）。
2.jar启动时，会使⽤容器的环境变量会作为相关参数。（原理可以查询关键词： spring jar 参数）
3.springboot启动时会注⼊相关的参数，从⽽获取到nacos的配置信息，并将nacos做为配置中⼼，从nacos上读取相关配置。
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不要慌，好好和运维同事做沟通，每个部门都有⾃⼰的规范和要求，像简单的运⾏命令出了问题，这个还是很好排查的。切记切记，不要有甩锅⼼理，不要有甩锅⼼理，不要有甩锅⼼理。
这次很明显，运维同事就是被我们开发摆了⼀道，这也是开发这边没有注意的问题，或者说，这是不应该出现的问题，属于⽐较低等的问题。饶是如此，我们也要重视起来，否则⼀个⼩⼩的雷，埋久了，他也是会发酵的，威⼒越来越⼤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。