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

2020年笔者在做微服务部件升级时，Dubbo的注册中心从Zookeeper切换到Nacos碰到个问题，最近刷Github又有网友提到类似的问题，就在这篇文章里做个梳理和总结。

1、问题描述

前几年我在做微服务部件升级时，将Dubbo的注册中心从Zookeeper切换到Nacos。切换的原因是有2点：

Zookeeper保障了CP，面对大量服务上下线时，吞吐量和响应有瓶颈。Nacos保障了AP，目前微服务的场景下，业界建议优先保障AP，这样有较好的吞吐量和较快的响应。
本着能少用部件就少用，尽量减少故障点的原则。Nacos既可以做注册中心也可以做配置中心，所以二合一，只采用一个部件。

切换完之后，奇怪的事情发生了，出现2个现象：

有些微服务启动很慢很慢，甚至长达15分钟的时间都无法成功启动，一直在打印大量的nacos请求日志。但是有些微服务启动又较快。
通过VisualVM查看JVM的线程情况，发现有的微服务居然高达4000左右的线程数。但是没切换之前只有几百的线程数。启动了大量的线程，导致CPU飙升不少，同时服务启动也慢。

2、通过现象开始排查

出现这种问题时，刚开始有点抓瞎，但是我们只能从常规的手段一点点排查，急不来。通过表面的现象，我们来逐步分析。

现象一：微服务启动很慢很慢，一直在打印大量的nacos请求日志。日志如下：

现象二：JVM的线程数高达4000左右。线程情况如下：

基于以上现象，我们只能初步判断是nacos的问题（当然结论不是nacos的问题）。

我们先来猜测：可能由于某种原因，产生了大量的nacos线程，每个线程又在不停的发送http请求。

那接下来继续分析Nacos。

3、分析Nacos

回顾Nacos原理

我们知道Nacos客户端注册和订阅服务流程大概如下：

所以，一般nacos-client有4个重要线程：

定时从nacos-server拉取服务的线程
维持心跳的线程
监听服务变更的线程
推送本服务变更信息的线程

分析Nacos

根据以上线程的名称和原理流程图，我们可以在nacos源码里找到对应的位置，代码如下：

翻看每个线程里执行的任务，确实能找到他们都在向nacos-server发送对应的的http的api请求：

既然找到了创建线程和发起http调用的原因，那就继续查看是哪里调用的init方法。

此时会自然想到dubbo了，因为dubbo采用nacos作为注册中心，自然要依赖nacos-client创建出nacos注册中心相关的类，然后从nacos注册中心类中获取到微服务的元数据信息。

4、Dubbo登场

在翻看Dubbo源码之前，先回顾下Dubbo是怎样基于引用配置文件或者引用配置注解创建Proxy的，大致流程如下：

ReferenceAnnotationBeanPostProcessor#doGetInjectedBean

⏬

ReferenceAnnotationBeanPostProcessor#buildReferenceBeanIfAbsent

⏬

ReferenceBeanBuilder#build

⏬

ReferenceBean#afterPropertiesSet

⏬

ReferenceConfig#init

至此完成了referenceProxy的创建。

重点看ReferenceConfig#init方法，方法里有一行代码：ref = createProxy(map);，顺着这行代码往里走，如下：

RegistryProtocol#refer

⏬

AbstractRegistryFactory#getRegistry

重点来了，重点来了，重点来了，核心代码和注释见下图。

总之是：因为在上面ReferenceConfig#init方法里引入了timestamp参数，同时又因为NacosRegistryFactory又自己实现了一套createRegistryCacheKey方法，这个方法里没有截掉timestamp参数，所有就会导致从缓存里取不到注册中心信息，所有就会不停的去创建，从而又创建了更多的线程，从而发送了很多http请求。

再次查看ReferenceConfig#init方法的源码，确实是加入了timestamp参数：

至此问题的原因已经找到了，接下来就是如何解决了。

5、解决方法

解决方法也很简单，就是在Dubbo的NacosRegistryFactory类里面截掉timestamp参数。

遗憾的是，我当时发现了这个问题时，打算给Dubbo官方发issue的，发现已经有网友抢先一步发了issue，并且已经合并到2.7.9分支里了。

以下是解决方法的代码截图：

两个版本处理URL的结果如下：

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&timestamp=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版本出现的，最后通过将2.7.9的修复class替换了2.7.8的NacosRegistryFactoryclass类，然后重新打了dubbo依赖包，问题得以解决。

有朋友会问：为啥不是引用2.7.9呢？因为我担心2.7.9有其他问题，所以做个class替换，然后继续用2.7.8是个较好的方式。