目录
配置中心是SpringCloud系统中常见的一种技术方案，配置中心区别于传统的各个系统当中分散的配置方式，它对系统中的配置文件进行集中式、统一管理。
②、当配置信息发生变动时，修改实时生效，无需要重新重启服务器，可以实时去调整相关对应的业务。
最近在做技术调研形成落地方案的时候，突然想到了nacos的动态配置刷新，于是想去看下nacos动态配置到底怎么实现的，今天抽出点时间看了下nacos配置中心源码实现。
所以，本篇文章就介绍nacos是怎么扩展spring实现自己的配置数据动态加载的。
首先第一点需要知道的是nacos动态配置从nacos角度来看核心是通过长轮询(LongPolling)来实现的，我们不妨先从nacos角度来看其长轮询实现方式，然后再看和spring的整合。
所谓长轮询，就是服务器接收到请求后，hold连接一段时间暂时不返回消息，直到进行相关处理完毕后才返回响应信息并关闭连接，客户端接收到响应信息后，进行相关处理，处理完毕后再向服务器发送新的请求。
所以在一次nacos客户端连接服务端当中，服务端断开连接也就有了两种情况：
①、服务端数据发生了变化，需要推送到客户端，向客户端推送数据，断开连接。
②、在一段时间内没有数据发生改变，超时断开连接。
这里我们先从类ClientWorker的构造方法看起，因为下面讲的和spring集成部分都是在类ClientWorker的构造方法的上层部分，等说到和spring继承的时候我们再衔接到类ClientWorker的构造方法这个地方。
然后接下来的for循环核心执行的就是通知监听器刷新nacos数据。
我们直接看cacheData.checkListenerMd5()方法的执行逻辑。
遍历所有的监听器，最终执行safeNotifyListener()这个方法很显然这个方法中创建了一个Runnable任务，最终通过监听器Listener里面的线程池或者直接执行这个Runnable任务。
所以，我们接下来重点看Runnable任务执行的逻辑。
这个Runnable任务里面核心逻辑是这行代码。
表示接收到动态修改的内容。
所以我们直接看这行代码的逻辑。
要看这行代码的逻辑，首先需要搞懂这个listener是哪个实现类，在这里先告诉大家，这个实现类是在NacosContextRefresher里面注册nacos监听器的时候创建的内部类，如果自己debug一下也能找到。
①、nacosRefreshHistory通过链表的方式记录nacos数据变更历史
②、通过ApplicationContext.publishEvent()方法刷新容器
很显然，我们想看的逻辑正是刷新容器这行代码。
然后我在NacosConfigManager这个类的构造方法打了个debug断点，因为这个类就是spring容器启动的时候第一次初始化创建nacos需要的一些组件、开启定时任务等核心逻辑。
果然，是进到了这个debug，也就印证了我的猜想。
上面我们主要是从nacos长轮询LongPolling的核心逻辑倒推监听器怎么执行最后到和spring整合的地方，这里我们详细看下和spring整合的部分。
和spring整合首先看类NacosConfigAutoConfiguration、NacosConfigBootstrapConfiguration这两个配置类，这两个配置类主要创建了nacos的一些核心组件。
重点看类NacosConfigManager和NacosContextRefresher。
NacosConfigManager是创建nacos长轮询的定时任务，定时执行长轮询的定时任务，是nacos配置更新的启动点。
NacosContextRefresher是和spring整合的桥梁，实现了ApplicationContextAware用来获取ApplicationContext，实现了ApplicationListener用来通知spring发布时间通知。
在发布事件通知的逻辑中就注册了nacos的监听器。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/188802.html