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

希望對還未碰到或正在碰到的朋友有所幫助。

現(xiàn)象

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

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

但其實(shí)經(jīng)過我后續(xù)排查發(fā)現(xiàn)剛開始其實(shí)并不是啟動不起來，而是啟動速度非常緩慢，所以當(dāng)應(yīng)用長時間啟動后才會對外提供服務(wù)。而這個速度慢到居然要花費(fèi) 2 個小時。

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

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

嘗試解決

最后測試頂不住了，只能讓我這個“事故報告撰寫專家”來看看。

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

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

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

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

好吧，忽悠不過去了。

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

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

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

加載 Spring ---->連接 Zookeeper ---> 連接 Redis，都是依次執(zhí)行下來沒有阻塞。

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

翻源碼

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

如圖所示可見主線程是卡在了 dubbo 的某個方法 ServiceConfig.java 的 303 行中。

于是我找到此處的源碼：

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

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

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

于是這問題貌似也阻塞在這兒了，沒有太多辦法。

最終解決

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

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

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

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

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

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

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

xx.xx.xx.xx(ip) hostname

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

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

總結(jié)

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

• 當(dāng) Dubbo 在啟動獲取本地 ip 時，是通過服務(wù)器 hostname 從 dns 服務(wù)器返回當(dāng)前的 ip 地址。
• 由于 dns 服務(wù)器或者是本地服務(wù)器與 dns 服務(wù)器之間存在網(wǎng)絡(luò)問題，導(dǎo)致這個過程的時間被拉長（猜測）。
• 我在本地的 host 文件中配置后，就相當(dāng)于本地有一個緩存，優(yōu)先取本地配置的 ip ，避免了和 dns 服務(wù)器交互的過程，所以速度提升了。

雖然問題得到解決了，但還是有幾個疑問：

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

第二就是 Dubbo 在這個依賴外部獲取資源時健壯性是否可以做的更好，雖說我這問題估計也幾人碰到。

對于這種長時間沒有啟動成功的問題是否可以加上提示，比如直接拋出異常退出程序，將問題可能的原因告訴開發(fā)者，方便排查問題。

轉(zhuǎn)載于:https://www.cnblogs.com/CQqf2019/p/11155487.html

總結(jié)

以上是生活随笔為你收集整理的一个 Dubbo 服务启动要两个小时的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。