怎么解決Dubbo服務啟動兩個小時問題

這篇文章主要講解了“怎么解決Dubbo服務啟動兩個小時問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么解決Dubbo服務啟動兩個小時問題”吧！

現象

現象是這樣的，有一天測試在測試環境重新部署一個 dubbo 應用的時候發現應用“啟動不起來”。

但過幾個小時候之后又能自己慢慢恢復，并能夠對外提供 dubbo 服務。

但其實經過我后續排查發現剛開始其實并不是啟動不起來，而是啟動速度非常緩慢，所以當應用長時間啟動后才會對外提供服務。

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

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

而且經過多次觀察，確實每次都是花費兩小時左右應用才能啟動起來。

嘗試解決

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

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

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

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

第二天一早看到測試同學的微信頭像跳動時我都已經準備接受又一句 “膜拜大佬????” 的回復時，卻收到 “網絡一切正常，沒人動過，再不解決就要罷工了????”。

好吧，忽悠不過去了。

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

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

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

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

隔了一段后應用確實還沒起來，我再次 jstack 后得到如下信息：

翻源碼

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

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

于是我找到此處的源碼：

簡單來說這里的邏輯就是要獲取本機的 IP 將其注冊到 Zookeeper 中用于其他服務調用。

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

但這是一個 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服務啟動兩個小時問題”的內容了，經過本文的學習后，相信大家對怎么解決Dubbo服務啟動兩個小時問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！