记录一次“异常bug”,具体信息如下。主要是记录一下处理过程，可能口水话比较多，如果想看结果，直接往后拉即可。
最后一行
起初，运维同事找到我，跟我说程序出问题了，系统升级，一直连不上nacos。
我看了日志信息之后，刚开始还是没有在意的。毕竟是nacos报错，报错还那么明显：java.net.ConnectException: Connection refused (Connection refused)
我信心满满告诉他，是nacos没起起来，或者是配置文件有问题。这不是代码的问题。(这里带有一点点侥幸心理)
我很快就被打脸了。其他服务都能起起来，唯独我们同事写的这个模块出了bug?就是连不上nacos。此时让他们重启nacos，肯定是不现实的，毕竟nacos是没问题的。重启这个报错的模块也试过了，但是模块就是一直在重连nacos，并且最终连不上去。
于是我把nacos的加载顺序重新捋一遍。在docker中起服务，首先是加载docker的环境变量，然后替代掉程序中的bootstrap.yml。这里猜测是启动命令的问题。
配置的读取过程
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不要慌，好好和运维同事做沟通，每个部门都有自己的规范和要求，像简单的运行命令出了问题，这个还是很好排查的。切记切记，不要有甩锅心理，不要有甩锅心理，不要有甩锅心理。
这次很明显，运维同事就是被我们开发摆了一道，这也是开发这边没有注意的问题，或者说，这是不应该出现的问题，属于比较低等的问题。饶是如此，我们也要重视起来，否则一个小小的雷，埋久了，他也是会发酵的，威力越来越大。
