問題描述

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

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

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

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

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

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

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

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

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

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

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

分析Nacos

1.回顧Nacos原理

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

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

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

2.分析Nacos

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

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

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

此時會自然想到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ù)，同時又因?yàn)镹acosRegistryFactory又自己實(shí)現(xiàn)了一套createRegistryCacheKey方法，這個方法里沒有截掉timestamp參數(shù)，所有就會導(dǎo)致從緩存里取不到注冊中心信息，所有就會不停的去創(chuàng)建，從而又創(chuàng)建了更多的線程，從而發(fā)送了很多http請求。

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

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

解決方法

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

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

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

兩個版本處理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=1712545856489

2.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

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

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

總結(jié)

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

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