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文件
首先加载初始化：org.springframework.cloud.alibaba.nacos.NacosConfigBootstrapConfiguration的NacosPropertySourceLocator对象
ps:何时加载NacosConfigBootstrapConfiguration 请参考:https://blog.csdn.net/m0_37607945/article/details/107762760)
重点关注NacosPropertySourceLocator.locate方法
那locate方法具体什么时候执行呢？
spring容器在初始化，准备上下文时，会调用所有实现ApplicationContextInitializer接口的类然后遍历执行其initialize()方法
而nacos则正是利用了spring的这种自定义PropertySourceLoader加载机制与spring完美结合，说明一个好的框架的扩展性设计是多么重要,同样如果从事自研中间件的小伙伴也必须对spring的各种机制，功能点必须非常熟悉才能写出优秀的框架。
接下来就回到了：NacosPropertySourceLocate的locate方法
利用反射创建NacosConfigService实例
接下来我们看看其构造函数都做了什么操作
依次初始化命名空间，以及http的包装类，实际执行的是serverHttpAgent，以及ClientWorker（长轮询），重点看一下ClientWorker
可以看到ClientWorker里面初始化了两个线程池，一个是定时执行任务线程池，一个是不定长线程池,同时启动了定时任务线程池，设定每10毫秒执行一次：checkConfigInfo()方法。（先记得有这么回事）
继续看locate 加载方法：
先加载共享配置类文件，即配置：spring.cloud.nacos.config. shared-dataids的文件
再加载配置为：spring.cloud.nacos.config.ext-config 的列表文件,
再去加载系统默认配置
内部方法调用逻辑大同小异，都是调用loadNacosDataIfPresent方法
继续跟，走到loadNacosData方法
走到NacosConfigService的getConfig方法，getConfig方法会先去查询本地文件(降级策略)，本地文件存在则返回，本地文件不存在则调用http接口获取,至此，配置中心初始化拉取数据完毕。
我们在nacos控制台修改了数据，客户端又是如何快速感知到的呢？
入口在：NacosConfigAutoConfiguration的nacosContextRefresher方法
nacosContextRefresher实现了ApplicationListener<ApplicationReadyEvent>，会在spring容器发布ApplicationReadyEvent事件时，触发监听操作
针对每个配置文件注册监听
首先声明一个Lister逻辑，然后放到listerMap中,key为dataId，lister内部逻辑主要是收到更新配置后，更新md5值，然后利用spring applicaiton发布RefreshEvent事件。
紧接着调用
configService.addListener(dataId, group, listener);
看下其内部处理逻辑
简单概括就是将配置信息封装成了一个cacheData对象,然后放到hashmap中
再次回到上文中的，ClientWorker的定时任务线程池中checkConfigInfo方法，每隔10s会去执行一次,
此处的longintTaskCount 自己理解应该一直是0，因为listenerSize 为配置文件数目不会超过3000，然后ParamUtil.getPerTaskConfigSize()也是固定值为3000，因此longingTaskCount为0，currentLongingTaskCount也为0，也就是if条件会永远不满足,但debug发现longingTaskCount会变为1，但是不知道为啥（希望大神解惑）
继续看LongPollingRunnable的run方法
如果没有用到本地配置，并且本地配置文件确实存在，则采用本地配置
如果是采用的本地配置。并且本地文件删除了 ,则设置setUseLocalConfigInfo(false)
检查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,然后客户端更新配置;
以上则是动态配置原理，如果有不对的地方请指出；
参考：https://www.jianshu.com/p/acb9b1093a54
