背景

我們的業(yè)務(wù)共使用 11 臺(tái)（阿里云）服務(wù)器，使用 SpringcloudAlibaba 構(gòu)建微服務(wù)集群, 共計(jì) 60 個(gè)微服務(wù), 全部注冊(cè)在同一個(gè) Nacos 集群。

流量轉(zhuǎn)發(fā)路徑：nginx -> spring-gateway -> 業(yè)務(wù)微服務(wù)。

使用的版本如下：

spring-boot.version：2.2.5.RELEASE

spring-cloud.version：Hoxton.SR3

spring-cloud-alibaba.version：2.2.1.RELEASE

java.version：1.8

案發(fā)

春節(jié)放假期間收到反饋，網(wǎng)頁(yè)報(bào)錯(cuò)服務(wù)未找到（gateway 找不到服務(wù)的報(bào)錯(cuò)提示）。查看 nacos 集群列表，發(fā)現(xiàn)個(gè)別服務(wù)丟失 （下線）。

這個(gè)問(wèn)題每幾天出現(xiàn)一次, 出現(xiàn)時(shí)間不固定, 每次掉線的服務(wù)像是隨機(jī)選的幾個(gè)。服務(wù)手動(dòng) kill+restart 后能穩(wěn)定運(yùn)行 2-3 天。

排查和解決

懷疑對(duì)象一：服務(wù)器內(nèi)存爆了

進(jìn)阿里云控制臺(tái)查看故障機(jī)器近期的各項(xiàng)指標(biāo)，但是發(fā)現(xiàn)故障機(jī)器的指標(biāo)有重要的幾項(xiàng)丟失。內(nèi)存使用率、CPU 使用率、系統(tǒng)負(fù)載均不顯示。

控制臺(tái)看不了只好進(jìn)服務(wù)器內(nèi)查看各指標(biāo)，free -m 查看內(nèi)存無(wú)異常。提交阿里工單。授權(quán)阿里工程師幫忙修復(fù)控制臺(tái)顯示問(wèn)題，懷疑這個(gè)問(wèn)題對(duì)業(yè)務(wù)有影響。

控制臺(tái)修復(fù)后掉線問(wèn)題依然存在。

懷疑對(duì)象二：CPU滿(mǎn)載

能感覺(jué)到執(zhí)行命令很流暢，所以感覺(jué)不是這個(gè)原因。top 查看后很正常。

懷疑對(duì)象三：磁盤(pán)滿(mǎn)了

雖然概率很小，但是 du -sh * 看一下，發(fā)現(xiàn)磁盤(pán)容量還能用到公司倒閉。

懷疑對(duì)象四：網(wǎng)絡(luò)有問(wèn)題

服務(wù)器那三個(gè)基本故障暫時(shí)排除后，最大懷疑對(duì)象就是網(wǎng)絡(luò)。畢竟服務(wù)掉線肯定是服務(wù)端一段時(shí)間內(nèi)接收不到客戶(hù)端心跳包，所以把客戶(hù)端踢下線了。

通過(guò) telnet,mtr -n...,netstat -nat |grep "TIME_WAIT" | wc -l 這些命令也只能看個(gè)大概。

echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse 修改內(nèi)核參數(shù)，開(kāi)啟 TIME_WAIT socket 復(fù)用能力，提升實(shí)例的網(wǎng)絡(luò)發(fā)送請(qǐng)求性能。

查看 nacos 客戶(hù)端（微服務(wù)）的日志，在前面案發(fā)里提到?jīng)]有日志記錄。

懷疑對(duì)象五：Nacos 集群服務(wù)端故障

查看 nacos 集群部署的那幾臺(tái)服務(wù)器, 查看服務(wù)器基礎(chǔ)指標(biāo) (內(nèi)存、CPU、磁盤(pán)等），未發(fā)現(xiàn)異常 （畢竟還有幾十個(gè)微服務(wù)都很正常工作）。

查看 nacos 服務(wù)端日志，發(fā)現(xiàn)確實(shí)有主動(dòng)下線服務(wù)操作。那就奇怪了，這個(gè)機(jī)器上的有些服務(wù)還在正常工作，為什么會(huì)隨機(jī)下線幾個(gè)服務(wù)呢？

懷疑對(duì)象六：微服務(wù)占用資源太多

后來(lái)仔細(xì)想想，這個(gè)懷疑對(duì)象是不是有點(diǎn)離譜了？ 因?yàn)椴渴鹉_本都是同一個(gè)，而且負(fù)載均衡也是一樣的。 但其他機(jī)器的這個(gè)服務(wù)都好好的。

調(diào)大每個(gè)微服務(wù)的內(nèi)存占用。

添加堆棧打印。

等待一段時(shí)間后，異常依然存在，并且沒(méi)有堆棧打印？因?yàn)檫M(jìn)程好好的并沒(méi)退出。

google 搜索 nacos 服務(wù)掉線，找到一篇看起來(lái)極其靠譜的文章。

上文提到我使用的 springcloud 版本，恰好這個(gè)版本的 nacos-client 版本就是 1.4.1， 于是立馬測(cè)試升級(jí)。

觀察幾天后，發(fā)現(xiàn)問(wèn)題依舊，只能將探查方向繼續(xù)轉(zhuǎn)回微服務(wù)本身。

用 arthas 進(jìn)行勘測(cè)各項(xiàng)指標(biāo)，發(fā)現(xiàn)所有正常的服務(wù)各指標(biāo)均正常。

想到服務(wù)掉線大概率是因?yàn)樾奶鼇G失，懷疑是心跳線程因?yàn)槟承┰虮粴⑺懒恕?/p>

翻看 nacos-client 源碼，找到心跳函數(shù)（nacos2.x 不是這個(gè)），使用 arthas 監(jiān)聽(tīng)心跳包，嘗試能找到心跳丟失的證據(jù)，貼上當(dāng)時(shí)的記錄。

當(dāng)異常再次發(fā)生，arthas 監(jiān)聽(tīng)卡死，無(wú)任何記錄和響應(yīng)。

無(wú)奈更換思路，寫(xiě)一個(gè)監(jiān)聽(tīng)服務(wù)掉線的程序，期望可以在工作時(shí)間內(nèi)及時(shí)獲取到異常。

終于在工作時(shí)間捕獲到異常，第一時(shí)間進(jìn)入服務(wù)器內(nèi)查看情況。

確認(rèn)服務(wù)器基礎(chǔ)項(xiàng)沒(méi)問(wèn)題后，使用 arthas 查看服務(wù)進(jìn)程堆棧情況，但是 arthas 無(wú)法進(jìn)入進(jìn)程。

用 jstat 查看 GC 情況，顯示很正常。

用 jmap/jstack 輸出堆棧 jstack -l 25944 >heap.txt，但是提示無(wú)法進(jìn)入進(jìn)程。無(wú)奈使用添加 - F（這個(gè)參數(shù)的堆棧少了很多信息），jstack -F -l 25944 >heap.txt

查看堆棧文件上萬(wàn)行記錄，眼都看花了但是沒(méi)有死鎖也沒(méi)有發(fā)現(xiàn)異常。

此時(shí)發(fā)現(xiàn)監(jiān)聽(tīng)程序提示服務(wù)上線了？檢查后發(fā)現(xiàn)確實(shí)掉線的幾個(gè)微服務(wù)自動(dòng)恢復(fù)了，心想這就難排查了。

嘗試復(fù)現(xiàn) Bug，此時(shí)離第一次案發(fā)已經(jīng)過(guò)去一周多，必須盡快處理好這個(gè) Bug 否則可能得被迫離職了。

當(dāng)?shù)诙伟l(fā)生異常的時(shí)候，使用同樣的方式 arthas 無(wú)法進(jìn)入 ->...->jstack 輸出堆棧。奇跡發(fā)生了，服務(wù)又恢復(fù)正常了。

思考 / 猜測(cè)：因?yàn)?JVM 死了（假死），所以導(dǎo)致進(jìn)程中的一切內(nèi)容，包括心跳線程、日志等都 hold 住。

Google 搜索關(guān)鍵詞 JVM 停止（假死）排查，終于找到一個(gè)極其靠譜的回答。

連忙查看對(duì)比使用的幾個(gè)機(jī)器內(nèi)核版本號(hào) uname -r。

那個(gè)低版本的就是故障機(jī)器，確認(rèn)相關(guān)信息后，聯(lián)系阿里云提交工單。

升級(jí)完內(nèi)核并重啟機(jī)器后，觀察兩天至今這個(gè)問(wèn)題不存在了。誰(shuí)能想到這個(gè)問(wèn)題居然是因?yàn)?Linux 內(nèi)核的 Bug 引起的？！不得不佩服第一個(gè)發(fā)現(xiàn)這個(gè) Bug 的大佬。

完結(jié)感言

這個(gè)問(wèn)題折磨了一周多，每日如鯁在喉！調(diào)試過(guò)程也是苦樂(lè)參半，樂(lè)的是突然有了調(diào)試思路，苦的是思路是一條死胡同，還好最終結(jié)果是滿(mǎn)意的。

審核編輯：劉清