記錄一次“異常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不要慌，好好和運維同事做溝通，每個部門都有自己的規范和要求，像簡單的運行命令出了問題，這個還是很好排查的。切記切記，不要有甩鍋心理，不要有甩鍋心理，不要有甩鍋心理。
這次很明顯，運維同事就是被我們開發擺了一道，這也是開發這邊沒有注意的問題，或者說，這是不應該出現的問題，屬於比較低等的問題。饒是如此，我們也要重視起來，否則一個小小的雷，埋久了，他也是會發酵的，威力越來越大。