您好,登錄后才能下訂單哦!
這篇文章主要講解了“怎么解決Dubbo服務啟動兩個小時問題”,文中的講解內(nèi)容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“怎么解決Dubbo服務啟動兩個小時問題”吧!
現(xiàn)象是這樣的,有一天測試在測試環(huán)境重新部署一個 dubbo
應用的時候發(fā)現(xiàn)應用“啟動不起來”
。
但過幾個小時候之后又能自己慢慢恢復,并能夠?qū)ν馓峁?dubbo
服務。
但其實經(jīng)過我后續(xù)排查發(fā)現(xiàn)剛開始其實并不是啟動不起來,而是啟動速度非常緩慢,所以當應用長時間啟動后才會對外提供服務。
而這個速度慢到居然要花費 2 個小時
。
導致的一個結(jié)果是測試完全不敢在測試環(huán)境發(fā)版驗證了,每驗證一個功能修復一個 bug
就得等上兩個小時,這誰受得了????。
而且經(jīng)過多次觀察,確實每次都是花費兩小時左右應用才能啟動起來。
最后測試頂不住了,只能讓我這個“事故報告撰寫專家”
來看看。
當我得知這個問題的現(xiàn)象時其實完全沒當一回事:
都不用想,這不就是主線程阻塞了嘛,先看看是否在初始化的時候數(shù)據(jù)庫、Zookeeper 之類的連不上導致阻塞了-------來之多次事故處理的經(jīng)驗告訴我。
于是我把這事打回給測試讓他先找運維排查下,不到萬不得已不要影響我 Touch fish
????。
第二天一早看到測試同學的微信頭像跳動時我都已經(jīng)準備接受又一句 “膜拜大佬????”
的回復時,卻收到 “網(wǎng)絡一切正常,沒人動過,再不解決就要罷工了????”。
好吧,忽悠不過去了。
首先這類問題的排查方向應該不會錯,就是主線程阻塞了,至于是啥導致的阻塞就不能像之前那樣瞎猜了。
我將應用重啟后用 jstack pid
將線程快照打印到終端,直接拉到最后看看 main
線程到底在干啥。
前幾次的快照都是很正常:
加載 Spring
---->連接 Zookeeper
---> 連接 Redis
,都是依次執(zhí)行下來沒有阻塞。
隔了一段后應用確實還沒起來,我再次 jstack
后得到如下信息:
我一直等了十幾分鐘再多次 jstack
得到的快照得到的信息都是一樣的。
如圖所示可見主線程是卡在了 dubbo 的某個方法 ServiceConfig.java
的 303 行中。
于是我找到此處的源碼:
簡單來說這里的邏輯就是要獲取本機的 IP
將其注冊到 Zookeeper
中用于其他服務調(diào)用。
再往下跟就如堆棧中一樣是卡在了 Inet4AddressImpl.getLocalHostName
處。
但這是一個 native
方法,我們應用也根本干涉不了,最終的現(xiàn)象就是調(diào)用這個本地方法非常耗時。
于是這問題貌似也阻塞在這兒了,沒有太多辦法。
既然這是一個 native 方法,那說明和應用本身沒有啥關(guān)系(確實也是這樣,這個問題是突然間出現(xiàn)的。)
那是否是服務器本身的問題呢,想到在 native
方法里是獲取本機的 hostname
,那是否和這個 hostname
有關(guān)系呢。
這是在我自己的阿里云服務器上測試,真正的測試環(huán)境不是這個名字。
拿到服務器 hostname
后再嘗試 ping
這個 hostname
,奇怪的現(xiàn)象發(fā)生了:
命令剛開始會卡住一段時間(大概幾十秒),然后才會輸出 hostname
對應的 ip
以及對應的延遲。
而當我直接 ping
這個 ip
時卻能快速響應后面的輸出。
最后我嘗試在 /etc/hosts 配置文件中加入了對應的 host 配置:
xx.xx.xx.xx(ip) hostname
再次 ping hostname
的效果就和直接 ping ip
一樣了。
感謝各位的閱讀,以上就是“怎么解決Dubbo服務啟動兩個小時問題”的內(nèi)容了,經(jīng)過本文的學習后,相信大家對怎么解決Dubbo服務啟動兩個小時問題這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。