Nacos动态配置原理

Posted 2021-05-14 少平博客

一、SpringBoot环境引入配置中心依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
    <version>0.9.0.RELEASE</version>
</dependency>

二、查看spring-cloud-starter-alibaba-nacos-config的spring.factories文件

        如下图所示：

1:

首先加载初始化：

org.springframework.cloud.alibaba.nacos.NacosConfigBootstrapConfiguration的NacosPropertySourceLocator对象

ps:何时加载NacosConfigBootstrapConfiguration 请参考:

https://blog.csdn.net/m0_37607945/article/details/107762760)

2:

重点关注NacosPropertySourceLocator.locate方法

那locate方法具体什么时候执行呢？

spring容器在初始化，准备上下文时，会调用所有实现ApplicationContextInitializer接口的类然后遍历执行其initialize()方法

而nacos则正是利用了spring的这种自定义PropertySourceLoader加载机制与spring完美结合，说明一个好的框架的扩展性设计是多么重要,同样如果从事自研中间件的小伙伴也必须对spring的各种机制，功能知识点必须非常熟悉清楚才能写出优秀的框架。

3:接下来就回到了：NacosPropertySourceLocate的locate方法

利用反射创建NacosConfigService实例

接下来我们看看其构造函数都做了什么操作

依次初始化命名空间，以及http的包装类，实际执行的是serverHttpAgent，以及ClientWorker（长轮询），重点看一下ClientWorker

4:

可以看到ClientWorker里面初始化了两个线程池，一个是定时执行任务线程池，一个是不定长线程池,同时启动了定时任务线程池，设定每10毫秒执行一次：checkConfigInfo()方法。（先记得有这么回事）

5:继续跟locate 加载方法：

5.1):先加载共享配置类文件，即配置：spring.cloud.nacos.config. shared-dataids的文件

5.2):再加载配置为：spring.cloud.nacos.config.ext-config 的列表文件

5.3):再去加载系统默认配置

内部方法调用逻辑大同小异，都是调用loadNacosDataIfPresent方法

继续跟，走到loadNacosData方法

走到NacosConfigService的getConfig方法，getConfig方法会先去查询本地文件(降级策略)，本地文件存在则返回，本地文件不存在则调用http接口获取,至此，配置中心初始化拉取数据完毕。

至此：配置自动拉取完毕

6:我们在nacos控制台修改了数据，客户端又是如何快速感知到的呢？

入口在：NacosConfigAutoConfiguration的nacosContextRefresher方法

nacosContextRefresher实现了ApplicationListener<ApplicationReadyEvent>，会在spring容器发布ApplicationReadyEvent事件时，触发监听操作

针对每个配置文件注册监听

首先声明一个Lister逻辑，然后放到listerMap中,key为dataId，lister内部逻辑主要是收到更新配置后，更新md5值，然后利用spring applicaiton发布RefreshEvent事件。

紧接着调用
configService.addListener(dataId, group, listener);
看下其内部处理逻辑
简单概括就是将配置信息封装成了一个cacheData对象,然后放到hashmap中

7:再次回到上文中的，ClientWorker的定时任务线程池中checkConfigInfo方法，每隔10s会去执行一次,

此处的longintTaskCount 自己理解应该一直是0，因为listenerSize 为配置文件数目不会超过3000，然后ParamUtil.getPerTaskConfigSize()也是固定值为3000，因此longingTaskCount为0，currentLongingTaskCount也为0，也就是if条件会永远不满足,但debug发现longingTaskCount会变为1，但是不知道为啥（希望大神解惑）

继续跟LongPollingRunnable的run方法

检查md5值是否有变更，如有通知发送监听

执行lister的receiveConfigInfo()方法

总结：客户端通过定时任务线程池来监听配置，当服务端配置发生变更时，客户端会通过拉(长轮询)方式得到最新的值并保存在cacheData中，然后于cacheData的listener的md5值做对比，如果有更新则通知，触发lister的reveiveConfig方法;

来看下服务端的长轮询处理:
发起长轮询请求，对应http接口：post请求，/v1/cs/configs/listener，并设置超时时间30s,逻辑是如果30s内配置发生了变更，则会立马返回，否则等待29s后执行检查判断配置是否发生变更返回。然后继续发起轮询请求，循环往复

服务端长轮询接口处理逻辑:

将请求设为异步，并封装成ClientLongPolling

ClientLongPolling 的run逻辑:

1.创建一个调度的任务，调度的延时时间为 29.5s,(29.5由客户端默认传递超时时间30s-服务端设置的500ms得来)

2.将该 ClientLongPolling 自身的实例添加到一个 allSubs 中去

3.延时时间到了之后，首先将该 ClientLongPolling 自身的实例从 allSubs 中移除

4.获取服务端中保存的对应客户端请求的 groupKeys 是否发生变更，将结果写入 response 返回给客户端

allSubs则必然和客户端配置变更有必然联系，查看服务端修改配置方法：post /v1/cs/configs/

先持久化，再去发布configDataChangeEvent事件

而我们的LongPollService 监听的则是LocalDataChangeEvent事件，似乎和ConfigDataChangeEvent没关系，其实不然

继续跟进ConfigController的ConfigChangePublisher

.notifyConfigChange(new ConfigDataChangeEvent(....)))方法

AsyncNotifyService中注册监听逻辑

会执行一个AsyncTask任务,从而触发一个http get接口:

也就是：

dumpService是负责将配置保存到磁盘的服务类

看到确实发布了LocalDataChangeEvent事件,

然后又回到了上图：LongPollingService 的onEvent方法,接着看DataChangeTask的逻辑，
首先遍历allStubs队列，然后找出当前的ClientLongPolling，
从队列中移除，然后response写入变更的groupKey

总结：可以看到nacos实际上是利用了推+拉 结合的方式来获取配置，当没有配置发生变更时，会hang住请求，默认等待(30-0.5)29.5秒后返回，而一旦发生数据变更，又会立刻推送变更数据写入到response,然后客户端更新配置;

以上则是动态配置原理，仅为个人理解，如果有不对的地方请指出。