前言

前幾天在測(cè)試環(huán)境碰到一個(gè)非常奇怪的與 dubbo 相關(guān)的問(wèn)題邑茄，事后我在網(wǎng)上搜索了一圈并沒(méi)有發(fā)現(xiàn)類似的帖子或文章，于是便有了這篇俊啼。

希望對(duì)還未碰到或正在碰到的朋友有所幫助肺缕。

現(xiàn)象

現(xiàn)象是這樣的，有一天測(cè)試在測(cè)試環(huán)境重新部署一個(gè) dubbo 應(yīng)用的時(shí)候發(fā)現(xiàn)應(yīng)用“啟動(dòng)不起來(lái)”授帕。

但過(guò)幾個(gè)小時(shí)候之后又能自己慢慢恢復(fù)同木，并能夠?qū)ν馓峁?dubbo 服務(wù)。

但其實(shí)經(jīng)過(guò)我后續(xù)排查發(fā)現(xiàn)剛開(kāi)始其實(shí)并不是啟動(dòng)不起來(lái)跛十，而是啟動(dòng)速度非常緩慢彤路，所以當(dāng)應(yīng)用長(zhǎng)時(shí)間啟動(dòng)后才會(huì)對(duì)外提供服務(wù)。

而這個(gè)速度慢到居然要花費(fèi) 2 個(gè)小時(shí)芥映。

導(dǎo)致的一個(gè)結(jié)果是測(cè)試完全不敢在測(cè)試環(huán)境發(fā)版驗(yàn)證了洲尊，每驗(yàn)證一個(gè)功能修復(fù)一個(gè) bug 就得等上兩個(gè)小時(shí)，這誰(shuí)受得了屏轰。

而且經(jīng)過(guò)多次觀察颊郎，確實(shí)每次都是花費(fèi)兩小時(shí)左右應(yīng)用才能啟動(dòng)起來(lái)。

嘗試解決

最后測(cè)試頂不住了霎苗，只能讓我這個(gè)“事故報(bào)告撰寫專家”來(lái)看看姆吭。

當(dāng)我得知這個(gè)問(wèn)題的現(xiàn)象時(shí)其實(shí)完全沒(méi)當(dāng)一回事：

都不用想，這不就是主線程阻塞了嘛唁盏，先看看是否在初始化的時(shí)候數(shù)據(jù)庫(kù)内狸、Zookeeper 之類的連不上導(dǎo)致阻塞了-------來(lái)之多次事故處理的經(jīng)驗(yàn)告訴我。

于是我把這事打回給測(cè)試讓他先找運(yùn)維排查下厘擂，不到萬(wàn)不得已不要影響我 Touch fish昆淡。

第二天一早看到測(cè)試同學(xué)的微信頭像跳動(dòng)時(shí)我都已經(jīng)準(zhǔn)備接受又一句 “膜拜大佬” 的回復(fù)時(shí)，卻收到 “網(wǎng)絡(luò)一切正常刽严，沒(méi)人動(dòng)過(guò)昂灵，再不解決就要罷工了”。

好吧舞萄，忽悠不過(guò)去了眨补。

首先這類問(wèn)題的排查方向應(yīng)該不會(huì)錯(cuò)，就是主線程阻塞了倒脓，至于是啥導(dǎo)致的阻塞就不能像之前那樣瞎猜了撑螺。

我將應(yīng)用重啟后用 jstack pid 將線程快照打印到終端，直接拉到最后看看 main 線程到底在干啥崎弃。

前幾次的快照都是很正常：

加載 Spring ---->連接 Zookeeper ---> 連接 Redis甘晤，都是依次執(zhí)行下來(lái)沒(méi)有阻塞含潘。

隔了一段后應(yīng)用確實(shí)還沒(méi)起來(lái)，我再次 jstack 后得到如下信息：

翻源碼

我一直等了十幾分鐘再多次 jstack 得到的快照得到的信息都是一樣的线婚。

如圖所示可見(jiàn)主線程是卡在了 dubbo 的某個(gè)方法 ServiceConfig.java 的 303 行中遏弱。

于是我找到此處的源碼：

簡(jiǎn)單來(lái)說(shuō)這里的邏輯就是要獲取本機(jī)的 IP 將其注冊(cè)到 Zookeeper 中用于其他服務(wù)調(diào)用。

再往下跟就如堆棧中一樣是卡在了 Inet4AddressImpl.getLocalHostName 處塞弊。

但這是一個(gè) native 方法腾窝，我們應(yīng)用也根本干涉不了，最終的現(xiàn)象就是調(diào)用這個(gè)本地方法非常耗時(shí)居砖。

于是這問(wèn)題貌似也阻塞在這兒了，沒(méi)有太多辦法驴娃。

最終解決

既然這是一個(gè) native 方法奏候，那說(shuō)明和應(yīng)用本身沒(méi)有啥關(guān)系（確實(shí)也是這樣，這個(gè)問(wèn)題是突然間出現(xiàn)的唇敞。）

那是否是服務(wù)器本身的問(wèn)題呢蔗草，想到在 native 方法里是獲取本機(jī)的 hostname，那是否和這個(gè) hostname 有關(guān)系呢疆柔。

這是在我自己的阿里云服務(wù)器上測(cè)試咒精，真正的測(cè)試環(huán)境不是這個(gè)名字。

拿到服務(wù)器 hostname 后再嘗試 ping 這個(gè) hostname旷档，奇怪的現(xiàn)象發(fā)生了：

命令剛開(kāi)始會(huì)卡住一段時(shí)間（大概幾十秒）模叙，然后才會(huì)輸出 hostname 對(duì)應(yīng)的 ip 以及對(duì)應(yīng)的延遲。

而當(dāng)我直接 ping 這個(gè) ip 時(shí)卻能快速響應(yīng)后面的輸出鞋屈。

最后我嘗試在 /etc/hosts 配置文件中加入了對(duì)應(yīng)的 host 配置：

xx.xx.xx.xx(ip) hostname

復(fù)制代碼

再次 ping hostname 的效果就和直接 ping ip 一樣了范咨。

于是我再次重啟應(yīng)用，一切都正常了厂庇。

總結(jié)

最后根據(jù)我調(diào)整的內(nèi)容嘗試分析下本次問(wèn)題的原因：

當(dāng) Dubbo 在啟動(dòng)獲取本地 ip 時(shí)渠啊，是通過(guò)服務(wù)器 hostname 從 dns 服務(wù)器返回當(dāng)前的 ip 地址。

由于 dns 服務(wù)器或者是本地服務(wù)器與 dns 服務(wù)器之間存在網(wǎng)絡(luò)問(wèn)題权旷，導(dǎo)致這個(gè)過(guò)程的時(shí)間被拉長(zhǎng)（猜測(cè)）替蛉。

我在本地的 host 文件中配置后，就相當(dāng)于本地有一個(gè)緩存拄氯，優(yōu)先取本地配置的 ip 躲查，避免了和 dns 服務(wù)器交互的過(guò)程，所以速度提升了坤邪。

雖然問(wèn)題得到解決了熙含，但還是有幾個(gè)疑問(wèn)：

第一個(gè)是為什么和 DNS 服務(wù)器的交互會(huì)這么慢，即便是慢也沒(méi)有像應(yīng)用那樣需要 2 個(gè)小時(shí)才能返回艇纺，這里我也沒(méi)搞得太清楚怎静，有相關(guān)經(jīng)驗(yàn)的朋友可以留言討論邮弹。

第二就是 Dubbo 在這個(gè)依賴外部獲取資源時(shí)健壯性是否可以做的更好，雖說(shuō)我這問(wèn)題估計(jì)也幾人碰到蚓聘。

對(duì)于這種長(zhǎng)時(shí)間沒(méi)有啟動(dòng)成功的問(wèn)題是否可以加上提示腌乡，比如直接拋出異常退出程序，將問(wèn)題可能的原因告訴開(kāi)發(fā)者夜牡，方便排查問(wèn)題与纽。

Dubbo面試文檔

獲取方式：加入Java架構(gòu)交流群：609073571，群內(nèi)有更多免費(fèi)的架構(gòu)視頻和文檔提供學(xué)習(xí)!