[[402066]]

本文轉(zhuǎn)載自微信公眾號「Kirito的技術(shù)分享」，作者kiritomoe。轉(zhuǎn)載本文請聯(lián)系Kirito的技術(shù)分享公眾號。

問題發(fā)現(xiàn)

就在這周，我接到 MSE Nacos 用戶的反饋，說線上 Nacos 不可用，服務(wù)都下線了，日志里面也是一堆報錯，我下意識以為線上炸了，趕緊上線排查。本文主要記錄這次問題的排查過程，以及解決方案。

首先看用戶反饋的報錯，日志如下：

并且用戶反饋業(yè)務(wù)日志也出現(xiàn)了大量的服務(wù)地址找不到的報錯，說明 Nacos 服務(wù)都下線了。

我立刻查看了服務(wù)端的監(jiān)控，發(fā)現(xiàn)用戶的 MSE Nacos 集群并無異常，cpu/內(nèi)存等指標(biāo)有下降，并沒有異常行為，排除了服務(wù)端異常的可能性。

隨即將視線聚焦在了客戶端。老實說，這個報錯我第一次見，看異常堆棧，字面意思便是域名解析出問題了。這個報錯大概持續(xù)了 10 分鐘，立刻讓用戶在業(yè)務(wù)節(jié)點上使用 ping、dig 等工具確認(rèn)域名解析是否正常，測試發(fā)現(xiàn)均無異常。繼續(xù)讓用戶 telnet mse-xx.com 8848，發(fā)現(xiàn)也能夠 telnet 通。

根據(jù)這些現(xiàn)象，大概能得出結(jié)論：用戶的機(jī)器上出現(xiàn)了短暫的域名解析問題，導(dǎo)致短時間訪問不通 MSE Nacos。但用戶繼續(xù)反饋說，一部分重啟以后的機(jī)器已經(jīng)恢復(fù)了，但沒有重啟的機(jī)器，竟然還會出現(xiàn)調(diào)用報錯。不然怎么說重啟大法好呢，但也加深了問題的詭異性。

正當(dāng)一籌莫展時，另一用戶也找上來了，竟然也是一樣的問題，并且由于第二個用戶還同時使用了 redis，報錯日志中除了出現(xiàn) nacos 的域名解析問題，還報了 redis 的域名解析報錯。至此，更加堅定了我之前推測，根因肯定是域名解析出現(xiàn)了故障，導(dǎo)致這兩個用戶收到了影響。但問題在于，為什么短暫的域名解析失敗(大概 10 分鐘)，會導(dǎo)致持續(xù)性的 Nacos 問題呢?并且只有重啟才能恢復(fù)。

分析兩個用戶的共性，最終我和同事將可疑點鎖定在了 Nacos 客戶端版本上，對比發(fā)現(xiàn)，用戶都是同一個報錯，并且竟然都是 nacos-client 1.4.1 版本。

Nacos 1.4.1 版本引入的 bug

在問題發(fā)生時，Nacos 1.x 最新的版本已經(jīng)是 Nacos 1.4.2 了，將源碼 checkout 到 1.4.1 版本，追蹤堆棧附近的問題，

上述這段代碼是 Nacos 訪問服務(wù)端的一段代碼，進(jìn)入 595 行，一探究竟。

我們成功找到了堆棧中的直接報錯，就是這段 IsIPv4 的判斷觸發(fā)。splitIPPortStr 這個方法的主要邏輯是從 Nacos 的連接串篩選出連接地址，主要是為了做默認(rèn)端口號的判斷，如果用戶沒有攜帶 8848，會默認(rèn)帶上 8848。

但問題恰恰便是出現(xiàn)在這兒：

InetAddress.getByName(addr) 是一個內(nèi)置的方法，描述如下：

Given the name of a host, returns an array of its IP addresses, based on the configured name service on the system. 

意思是把一個域名傳給操作系統(tǒng)，返回一串 IP，這不就是域名解析嗎!我當(dāng)時就很好奇，你說你判斷 IPv4 格式，為啥要這么判斷呢?直接判斷 IPv4 的 pattern 不行嗎?而這段代碼，恰恰是導(dǎo)致問題的兇手之一。

我們看看 1.4.2，已經(jīng)修復(fù)了這個邏輯了，直接改成了正則判斷。

但疑問還是存在的，域名解析短暫失敗了，為啥會導(dǎo)致服務(wù)全都下線了，并且解析恢復(fù)后，服務(wù)依舊沒有上線呢?

繼續(xù)追蹤這段代碼，發(fā)現(xiàn) callServer 這段代碼會被 com.alibaba.nacos.client.naming.beat.BeatReactor 持有，用于維持自身和 Nacos 的心跳。

而由于上述域名解析失敗，拋出的異常是 IllegalArgumentException，并沒有被里層方法轉(zhuǎn)換成 NacosException，從而導(dǎo)致心跳線程沒有 catch 住異常，徹底停止發(fā)送心跳了!

這也就成功解釋了，為什么短暫的域名解析失敗，會導(dǎo)致服務(wù)全部下線了。(Nacos 是利用心跳維護(hù)和 server 端的存活狀態(tài)的)

改進(jìn)建議

修改 isIPv6 和 isIPv4 的判斷方式，改為正則匹配。上文提及，這點已經(jīng)在 1.4.2 修復(fù)了。

心跳線程要保證不被異常中斷下一次心跳的提交。

第二點，也已經(jīng)被修復(fù)了。

總結(jié)

nacos-client 1.4.1 存在嚴(yán)重的 bug，客戶端與 Nacos Server 如果發(fā)生短暫的域名解析問題，會導(dǎo)致心跳永久丟失，進(jìn)而引發(fā)服務(wù)全量下線，即使網(wǎng)絡(luò)恢復(fù)，也不會自動恢復(fù)心跳。

域名解析失敗常見于網(wǎng)絡(luò)抖動或者 K8s 環(huán)境下的 coreDNS 訪問超時等場景，為避免域名解析對 Nacos 造成的重大影響，請務(wù)必自查應(yīng)用代碼中使用的 nacos-client 的版本。

該問題僅存在于 1.4.1 版本，低于此版本不受此問題的影響，使用 1.4.1 的用戶建議升級至 1.4.2 以避免此問題。

使用 SpringCloud/Dubbo 的用戶，需要確認(rèn)實際框架使用的 nacos-client 版本，可以通過顯式指定 nacos-client 的版本以覆蓋框架默認(rèn)的版本。其中 Dubbo 用戶要格外小心，Dubbo 的 2.7.11 版本默認(rèn)使用了 nacos-client 1.4.1，務(wù)必顯式指定 nacos-client 的版本到 1.4.2，Dubbo 也將在下個 release 版本替換 Nacos 的默認(rèn)版本。