當(dāng)前位置：首頁 > 科技 > 軟件

深度剖析：Dubbo使用Nacos注冊中心的坑

來源：責(zé)編：時(shí)間：2024-04-11 09:04:05 194觀看

導(dǎo)讀問題描述前幾年我在做微服務(wù)部件升級時(shí)，將Dubbo的注冊中心從Zookeeper切換到Nacos。切換的原因是有2點(diǎn)：Zookeeper保障了CP，面對大量服務(wù)上下線時(shí)，吞吐量和響應(yīng)有瓶頸。Nacos保障了AP，目前微服務(wù)的場景下，業(yè)界建議優(yōu)先保障AP

問題描述

前幾年我在做微服務(wù)部件升級時(shí)，將Dubbo的注冊中心從Zookeeper切換到Nacos。切換的原因是有2點(diǎn)：

Zookeeper保障了CP，面對大量服務(wù)上下線時(shí)，吞吐量和響應(yīng)有瓶頸。Nacos保障了AP，目前微服務(wù)的場景下，業(yè)界建議優(yōu)先保障AP，這樣有較好的吞吐量和較快的響應(yīng)。
本著能少用部件就少用，盡量減少故障點(diǎn)的原則。Nacos既可以做注冊中心也可以做配置中心，所以二合一，只采用一個(gè)部件。

切換完之后，奇怪的事情發(fā)生了，出現(xiàn)2個(gè)現(xiàn)象：

有些微服務(wù)啟動(dòng)很慢很慢，甚至長達(dá)15分鐘的時(shí)間都無法成功啟動(dòng)，一直在打印大量的nacos請求日志。但是有些微服務(wù)啟動(dòng)又較快。
通過VisualVM查看JVM的線程情況，發(fā)現(xiàn)有的微服務(wù)居然高達(dá)4000左右的線程數(shù)。但是沒切換之前只有幾百的線程數(shù)。啟動(dòng)了大量的線程，導(dǎo)致CPU飆升不少，同時(shí)服務(wù)啟動(dòng)也慢。

通過現(xiàn)象開始排查

出現(xiàn)這種問題時(shí)，剛開始有點(diǎn)抓瞎，但是我們只能從常規(guī)的手段一點(diǎn)點(diǎn)排查，急不來。通過表面的現(xiàn)象，我們來逐步分析。

現(xiàn)象一：微服務(wù)啟動(dòng)很慢很慢，一直在打印大量的nacos請求日志。日志如下：

現(xiàn)象二：JVM的線程數(shù)高達(dá)4000左右。線程情況如下：

基于以上現(xiàn)象，我們只能初步判斷是nacos的問題（當(dāng)然結(jié)論不是nacos的問題）。

我們先來猜測：可能由于某種原因，產(chǎn)生了大量的nacos線程，每個(gè)線程又在不停的發(fā)送http請求。

那接下來繼續(xù)分析Nacos。

分析Nacos

1.回顧Nacos原理

我們知道Nacos客戶端注冊和訂閱服務(wù)流程大概如下：

所以，一般nacos-client有4個(gè)重要線程：

定時(shí)從nacos-server拉取服務(wù)的線程
維持心跳的線程
監(jiān)聽服務(wù)變更的線程
推送本服務(wù)變更信息的線程

2.分析Nacos

根據(jù)以上線程的名稱和原理流程圖，我們可以在nacos源碼里找到對應(yīng)的位置，代碼如下：

翻看每個(gè)線程里執(zhí)行的任務(wù)，確實(shí)能找到他們都在向nacos-server發(fā)送對應(yīng)的的http的api請求：

既然找到了創(chuàng)建線程和發(fā)起http調(diào)用的原因，那就繼續(xù)查看是哪里調(diào)用的init方法。

此時(shí)會(huì)自然想到dubbo了，因?yàn)閐ubbo采用nacos作為注冊中心，自然要依賴nacos-client創(chuàng)建出nacos注冊中心相關(guān)的類，然后從nacos注冊中心類中獲取到微服務(wù)的元數(shù)據(jù)信息。

Dubbo登場

在翻看Dubbo源碼之前，先回顧下Dubbo是怎樣基于引用配置文件或者引用配置注解創(chuàng)建Proxy的，大致流程如下：

ReferenceAnnotationBeanPostProcessor#doGetInjectedBean

ReferenceAnnotationBeanPostProcessor#buildReferenceBeanIfAbsent

ReferenceBeanBuilder#build

ReferenceBean#afterPropertiesSet

ReferenceConfig#init

至此完成了referenceProxy的創(chuàng)建。

重點(diǎn)看ReferenceConfig#init方法，方法里有一行代碼：ref = createProxy(map);，順著這行代碼往里走，如下：

RegistryProtocol#refer

AbstractRegistryFactory#getRegistry

重點(diǎn)來了，重點(diǎn)來了，重點(diǎn)來了，核心代碼和注釋見下圖。

總之是：因?yàn)樵谏厦鍾eferenceConfig#init方法里引入了timestamp參數(shù)，同時(shí)又因?yàn)镹acosRegistryFactory又自己實(shí)現(xiàn)了一套createRegistryCacheKey方法，這個(gè)方法里沒有截掉timestamp參數(shù)，所有就會(huì)導(dǎo)致從緩存里取不到注冊中心信息，所有就會(huì)不停的去創(chuàng)建，從而又創(chuàng)建了更多的線程，從而發(fā)送了很多http請求。

再次查看ReferenceConfig#init方法的源碼，確實(shí)是加入了timestamp參數(shù)：

至此問題的原因已經(jīng)找到了，接下來就是如何解決了。

解決方法

解決方法也很簡單，就是在Dubbo的NacosRegistryFactory類里面截掉timestamp參數(shù)。

遺憾的是，我當(dāng)時(shí)發(fā)現(xiàn)了這個(gè)問題時(shí)，打算給Dubbo官方發(fā)issue的，發(fā)現(xiàn)已經(jīng)有網(wǎng)友搶先一步發(fā)了issue，并且已經(jīng)合并到2.7.9分支里了。

以下是解決方法的代碼截圖：

兩個(gè)版本處理URL的結(jié)果如下：

2.7.8版本：nacos://10.20.1.13:8848,10.20.1.14:8848,10.20.1.15:8848/org.apache.dubbo.registry.RegistryService?application=ehome-cloud&application.version=1.0&dubbo=2.0.2&interface=org.apache.dubbo.registry.RegistryService&namespace=dev-jzj&owner=ehome-cloud-owner&pid=21335&qos.enable=false&release=2.7.8×tamp=17125458564892.7.9版本：nacos://10.20.1.13:8848,10.20.1.14:8848,10.20.1.15:8848/org.apache.dubbo.registry.RegistryService?namespace=dev-jzj

這個(gè)問題是在dubbo的2.7.8版本出現(xiàn)的，最后通過將2.7.9的修復(fù)class替換了2.7.8的NacosRegistryFactoryclass類，然后重新打了dubbo依賴包，問題得以解決。

有朋友會(huì)問：為啥不是引用2.7.9呢？因?yàn)槲覔?dān)心2.7.9有其他問題，所以做個(gè)class替換，然后繼續(xù)用2.7.8是個(gè)較好的方式。

總結(jié)

本文主要梳理了Dubbo使用Nacos注冊中心的坑，同時(shí)也講述了，出現(xiàn)問題時(shí)，如何一步一步排查。透過現(xiàn)象結(jié)合源碼，逐步找到問題的真相。

當(dāng)然在排查之前，就需要對Dubbo和Nacos有一定的了解。所以各位朋友，在平時(shí)還是要多積累，多深入原理，這樣遇到問題才能順利解決。

本文鏈接：http://www.www897cc.com/showinfo-26-82749-0.html深度剖析：Dubbo使用Nacos注冊中心的坑

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com

上一篇： Python實(shí)現(xiàn)適配器模式、裝飾器模式、代理模式

下一篇：深入理解C/C++指針的算術(shù)運(yùn)算

標(biāo)簽：

熱門焦點(diǎn)

6月安卓手機(jī)性價(jià)比榜：Note 12 Turbo斷層式碾壓

6月份有一個(gè)618，雖然這是京東周年慶的日子，但別的電商也都不約而同的跟進(jìn)了，反正促銷沒壞處，廠商和用戶都能滿意。618期間一些產(chǎn)品也出現(xiàn)了歷史低價(jià)，那么各個(gè)價(jià)位段的產(chǎn)品性價(jià)比
分享六款相見恨晚的PPT模版網(wǎng)站, 祝你做出精美的PPT!

1、OfficePLUSOfficePLUS網(wǎng)站旨在為全球Office用戶提供豐富的高品質(zhì)原創(chuàng)PPT模板、實(shí)用文檔、數(shù)據(jù)圖表及個(gè)性化定制服務(wù)。優(yōu)點(diǎn)：OfficePLUS是微軟官方網(wǎng)站，囊括PPT模板、Word模
JVM優(yōu)化：實(shí)戰(zhàn)OutOfMemoryError異常

一、Java堆溢出堆內(nèi)存中主要存放對象、數(shù)組等，只要不斷地創(chuàng)建這些對象，并且保證 GC Roots 到對象之間有可達(dá)路徑來避免垃圾收集回收機(jī)制清除這些對象，當(dāng)這些對象所占空間超過
為什么你不應(yīng)該使用Div作為可點(diǎn)擊元素

按鈕是為任何網(wǎng)絡(luò)應(yīng)用程序提供交互性的最常見方式。但我們經(jīng)常傾向于使用其他HTML元素，如 div span 等作為 clickable 元素。但通過這樣做，我們錯(cuò)過了許多內(nèi)置瀏覽器的功能。
最“俊美”淘寶賣家，靠直播和短視頻圈粉，上架秒光，年銷3000萬

來源 | 電商在線文｜易琬玉編輯｜斯問受訪店鋪：Ringdoll戒之人形圖源：微博@御座的黃山、“Ringdoll戒之人形”淘寶店鋪有關(guān)外貌的評價(jià)，黃山已經(jīng)聽累了。生于1985年的他，哪
花7萬退貨退款無門：誰在縱容淘寶珠寶商家造假？

來源：極點(diǎn)商業(yè)作者：楊銘在淘寶購買珠寶玉石后，因?yàn)楸ＷC金不夠賠付，店鋪關(guān)閉，退貨退款難、維權(quán)無門的比比皆是。“提供相關(guān)產(chǎn)品鑒定證書，支持全國復(fù)檢，可以30天無理由退換貨。&
阿里大調(diào)整

來源：產(chǎn)品劉有媒體報(bào)道稱，近期淘寶天貓集團(tuán)啟動(dòng)了近年來最大的人力制度改革，涉及員工績效、層級體系等多個(gè)核心事項(xiàng)，目前已形成一個(gè)初步的“征求意見版”：1、取消P序列
阿里瓴羊One推出背后，零售企業(yè)迎數(shù)字化新解

作者:劉曠近年來隨著數(shù)字經(jīng)濟(jì)的高速發(fā)展，各式各樣的SaaS應(yīng)用服務(wù)更是層出不窮，但本質(zhì)上SaaS大多局限于單一業(yè)務(wù)流層面，對用戶核心關(guān)切的增長問題等則沒有提供更好的解法。在Saa
小米MIX Fold 3配置細(xì)節(jié)曝光：搭載領(lǐng)先版驍龍8 Gen2+罕見5倍長焦

這段時(shí)間以來，包括三星、一加、榮耀等等有不少品牌旗下的最新折疊屏旗艦都得到了不少爆料，而小米新一代折疊屏旗艦——小米MIX Fold 3此前也屢屢被傳

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

深度剖析：Dubbo使用Nacos注冊中心的坑

問題描述

通過現(xiàn)象開始排查

分析Nacos

1.回顧Nacos原理

2.分析Nacos

Dubbo登場

解決方法

總結(jié)

6月安卓手機(jī)性價(jià)比榜：Note 12 Turbo斷層式碾壓

分享六款相見恨晚的PPT模版網(wǎng)站, 祝你做出精美的PPT!

JVM優(yōu)化：實(shí)戰(zhàn)OutOfMemoryError異常

為什么你不應(yīng)該使用Div作為可點(diǎn)擊元素

最“俊美”淘寶賣家，靠直播和短視頻圈粉，上架秒光，年銷3000萬

花7萬退貨退款無門：誰在縱容淘寶珠寶商家造假？

阿里大調(diào)整

阿里瓴羊One推出背后，零售企業(yè)迎數(shù)字化新解

小米MIX Fold 3配置細(xì)節(jié)曝光：搭載領(lǐng)先版驍龍8 Gen2+罕見5倍長焦

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊