What？一個 Dubbo 服務啓動要兩個小時！

前言

前幾天在測試環境碰到一個很是奇怪的與 dubbo 相關的問題，過後我在網上搜索了一圈並無發現相似的帖子或文章，因而便有了這篇。

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

現象

現象是這樣的，有一天測試在測試環境從新部署一個 dubbo 應用的時候發現應用「啓動不起來」。
但過幾個小時候以後又能本身慢慢恢復，並可以對外提供 dubbo 服務。

但其實通過我後續排查發現剛開始其實並非啓動不起來，而是啓動速度很是緩慢，因此當應用長時間啓動後纔會對外提供服務。

而這個速度慢到竟然要花費 2 個小時。

致使的一個結果是測試徹底不敢在測試環境發版驗證了，每驗證一個功能修復一個 bug 就得等上兩個小時，這誰受得了😂。

並且通過屢次觀察，確實每次都是花費兩小時左右應用才能啓動起來。

嘗試解決

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

當我得知這個問題的現象時其實徹底沒當一回事：

都不用想，這不就是主線程阻塞了嘛，先看看是否在初始化的時候數據庫、Zookeeper 之類的連不上致使阻塞了-------來之屢次事故處理的經驗告訴我。

因而我把這事打回給測試讓他先找運維排查下，不到萬不得已不要影響我 Touch fish🐳。

次日一早看到測試同窗的微信頭像跳動時我都已經準備接受又一句 「膜拜大佬👍」 的回覆時，卻收到 「網絡一切正常，沒人動過，再不解決就要罷工了🤬」。

好吧，忽悠不過去了。

首先這類問題的排查方向應該不會錯，就是主線程阻塞了，至因而啥致使的阻塞就不能像以前那樣瞎猜了。

我將應用重啓後用 jstack pid 將線程快照打印到終端，直接拉到最後看看 main 線程到底在幹啥。
前幾回的快照都是很正常：

加載 Spring ---->鏈接 Zookeeper ---> 鏈接 Redis，都是依次執行下來沒有阻塞。

隔了一段後應用確實還沒起來，我再次 jstack 後獲得以下信息：

翻源碼

我一直等了十幾分鍾再屢次 jstack 獲得的快照獲得的信息都是同樣的。

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

因而我找到此處的源碼：

簡單來講這裏的邏輯就是要獲取本機的 IP 將其註冊到 Zookeeper 中用於其餘服務調用。

但這是一個 native 方法，咱們應用也根本干涉不了，最終的現象就是調用這個本地方法很是耗時。

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

最終解決

既然這是一個 native 方法，那說明和應用自己沒有啥關係（確實也是這樣，這個問題是忽然間出現的。）

那是不是服務器自己的問題呢，想到在 native 方法裏是獲取本機的 hostname，那是否和這個 hostname 有關係呢。

這是在我本身的阿里雲服務器上測試，真正的測試環境不是這個名字。

拿到服務器 hostname 後再嘗試 ping 這個 hostname，奇怪的現象發生了：

命令剛開始會卡住一段時間（大概幾十秒），而後纔會輸出 hostname 對應的 ip 以及對應的延遲。

而當我直接 ping 這個 ip 時卻能快速響應後面的輸出。

最後我嘗試在 /etc/hosts 配置文件中加入了對應的 host 配置：

xx.xx.xx.xx(ip) hostname

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

因而我再次重啓應用，一切都正常了。

總結

最後根據我調整的內容嘗試分析下本次問題的緣由：

• 當 Dubbo 在啓動獲取本地 ip 時，是經過服務器 hostname 從 dns 服務器返回當前的 ip 地址。
• 因爲 dns 服務器或者是本地服務器與 dns 服務器之間存在網絡問題，致使這個過程的時間被拉長（猜想）。
• 我在本地的 host 文件中配置後，就至關於本地有一個緩存，優先取本地配置的 ip ，避免了和 dns 服務器交互的過程，因此速度提高了。

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

第一個是爲何和 DNS 服務器的交互會這麼慢，即使是慢也沒有像應用那樣須要 2 個小時才能返回，這裏我也沒搞得太清楚，有相關經驗的朋友能夠留言討論。

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

對於這種長時間沒有啓動成功的問題是否能夠加上提示，好比直接拋出異常退出程序，將問題可能的緣由告訴開發者，方便排查問題。