Nacos配置拉取及配置动态刷新原理【源码阅读】

野性酷女 2023-09-24 23:03 53阅读 0赞

# Nacos配置拉取及配置刷新原理 #

## 一、初始化时获取配置文件 ##

### 背景 ###

> SpringCloud项目中SpringBoot在启动阶段除了会创建SpringBoot容器，还会通过bootstrap.yml构建一个SpringCloud容器，之后会在准备上下文阶段通过SPI加载实现类后，会进行配置合并。

### NacosPropertySourceLocator类 ###

1、该类为拉取nacos配置文件的核心类，在结果SPI加载时**NacosPropertySourceLocator**作为PropertySourceLocator的实现类，也将被加载到**PropertySourceBootstrapConfiguration**中参加遍历。

![image-20230311052048583][]

2、最后来到NacosPropertySourceLocator类的locate方法，在该方法中会通过nacosConfigManager来获取ConfigService接口实现类

![image-20230311052539842][]

3、该方法结果调用最后会通过反射获取NacosConfigService对象的有参构造器创建并返回

![image-20230311052913557][]

4、回到上面的locate方法，最后开始加载配置文件，此处会加载三种类型配置文件，分别为共享配置文件、拓展配置文件、应用自身的配置文件。此时由于顺序的原因导致覆盖我们可以得出优先级为从下至上，而其中每一种配置文件的加载都会有三种加载方式，分别是从本地获取，再从nacos获取，为从nacos获取时网络异常等原因导致获取失败，最后一种获取方式为从快照获取（快照的来源为每一种成功从nacos获取后保存）。

![image-20230311054017540][]

5、最后都将使用上文的NacosConfigService对象getConfigInner方法实现三种方式的获取

private String getConfigInner(String tenant, String dataId, String group, long timeoutMs) throws NacosException {
        
        group = blank2defaultGroup(group);
        ParamUtils.checkKeyParam(dataId, group);
        ConfigResponse cr = new ConfigResponse();
        
        cr.setDataId(dataId);
        cr.setTenant(tenant);
        cr.setGroup(group);
        
        // 优先使用本地配置
        String content = LocalConfigInfoProcessor.getFailover(agent.getName(), dataId, group, tenant);
        if (content != null) {
        
            LOGGER.warn("[{}] [get-config] get failover ok, dataId={}, group={}, tenant={}, config={}", agent.getName(),
                    dataId, group, tenant, ContentUtils.truncateContent(content));
            cr.setContent(content);
            String encryptedDataKey = LocalEncryptedDataKeyProcessor
                    .getEncryptDataKeyFailover(agent.getName(), dataId, group, tenant);
            cr.setEncryptedDataKey(encryptedDataKey);
            configFilterChainManager.doFilter(null, cr);
            content = cr.getContent();
            return content;
        }
        
        try {
        
            ConfigResponse response = worker.getServerConfig(dataId, group, tenant, timeoutMs);
            cr.setContent(response.getContent());
            cr.setEncryptedDataKey(response.getEncryptedDataKey());
            
            configFilterChainManager.doFilter(null, cr);
            content = cr.getContent();
            
            return content;
        } catch (NacosException ioe) {
        
            if (NacosException.NO_RIGHT == ioe.getErrCode()) {
        
                throw ioe;
            }
            LOGGER.warn("[{}] [get-config] get from server error, dataId={}, group={}, tenant={}, msg={}",
                    agent.getName(), dataId, group, tenant, ioe.toString());
        }
        
        LOGGER.warn("[{}] [get-config] get snapshot ok, dataId={}, group={}, tenant={}, config={}", agent.getName(),
                dataId, group, tenant, ContentUtils.truncateContent(content));
        content = LocalConfigInfoProcessor.getSnapshot(agent.getName(), dataId, group, tenant);
        cr.setContent(content);
        String encryptedDataKey = LocalEncryptedDataKeyProcessor
                .getEncryptDataKeyFailover(agent.getName(), dataId, group, tenant);
        cr.setEncryptedDataKey(encryptedDataKey);
        configFilterChainManager.doFilter(null, cr);
        content = cr.getContent();
        return content;
    }

6、最后将配置文件中的信息都保存到composite中返回。

### 以上为项目启动时获取的配置文件流程 ###

## 配置刷新原理 ##

### 背景 ###

> 当远程 Nacos Config Server 中的配置信息发生了变更，我们springboot应用作为Nacos Config Client 是如何感知到的呢？
> 
> 此处我们需要知道一点前置知识，那就是两个数据消费模型，push模型和pull模型。
> 
>  *  **Push 模型**：当 Server 端的数据发生了变更，其会主动将更新推送给 Client。Push 模型 适合于 Client 数量不多，且 Server 端数据变化比较频繁的场景。其实时性较好，但其需要维护长连接，占用系统资源。
>  *  **Pull 模型**：需要 Client 定时查看 Server 端数据是否更新。其实时性不好，且可能会产生数据更新的丢失。

### 那nacos采用的是哪种模型呢？ ###

#### 其实都不是，Nacos采用了**长轮询模型**实现的变更通知。 ####

> 那什么是长轮询呢？
> 
>  *  长轮询模型整合了 Push 与 Pull 模型的优势。Client 仍定时发起 Pull 请求，查看 Server 端数据是否更新。若发生了更新，则 Server 立即将更新数据以响应的形式发送给 Client 端； 若没有发生更新，Server 端不会发送任何信息，但其会临时性的保持住这个连接一段时间。 若在此时间段内，Server 端数据发生了变更，这个变更就会触发 Server 向 Client 发送变更结 果。这次发送的执行，就是因为长连接的存在。若此期间仍未发生变更，则放弃这个连接。 等待着下一次 Client 的 Pull 请求。 长轮询模型，是 Push 与 Pull 模型的整合，既减少了 Push 模型中长连接的被长时间维护 的时间，又降低了 Pull 模型实时性较差的问题。
>  *  Nacos断开连接默认为3秒

2.1、在上文**第2、3步**我们提到NacosPropertySourceLocator会通过反射获取到NacosConfigService类的全程构造方法并且构造出NacosConfigService对象。此时我们来看看NacosConfigService类的构造方法。注意该方法中我画绿圈的worker属性构造。该属性即为配置刷新的核心。

![image-20230311055333689][]

2.2、来到ClientWorker构造方法，我们可以看到其中有两个周期线程池，其中executor线程池就是为了控制发出配置检测的间隔，为10秒一次，断开连接默认为3秒

![image-20230311061429849][]

![image-20230311061628943][]

2.3、接下来我们看到发出配置检测请求的checkConfigInfo()方法

![image-20230311061728396][]

> ParamUtil.getPerTaskConfigSize()的值为3000，currentLongingTaskCount默认为0，所以正常情况下都只是循环一次

2.4、接下来我们点到LongPollingRunnable看着像长轮询的类，该类实现了Runnable接口，查看其run方法。

以下是使用本地配置时检测是否更新

![image-20230311062409691][]

2.5、然后开始检测并获得远程的变化了的key

![image-20230311063653075][]

2.6、然后获取到对应的value设置新值且计算md5，md5即用于比较是否发现变化，注意其中的setContent方法

public void setContent(String content) {
        
        this.content = content;
        this.md5 = getMd5String(this.content);
    }

![image-20230311063839977][]

2.7、随后开始检测并开启下一次任务

![image-20230311064047195][]

2.8、接下来我们打开检测是否变化的方法checkListenerMd5()

![image-20230311064134822][]

2.9、发现发生变化后将会调用safeNotifyListener方法，safeNotifyListener方法则会触发刷新的方法。

### 补充 ###

*  3.1、在介绍该方法之前我们补充以下之前遗漏的初始化监听器的步骤，在springboot准备完环境后将会发出ApplicationReadyEvent事件。而在NacosConfigAutoConfiguration配置类中注入了一个NacosContextRefresher对象

![image-20230311065040389][]

*  3.2、我们打开NacosContextRefresher对象，看到该类实现了ApplicationListener接口，并且监听事件刚好为上步骤中提到的ApplicationReadyEvent事件。

![image-20230311065209722][]

*  3.3、接下来我们看看他的监听方法中做了什么，看到使用了CAS来控制registerNacosListenersForApplications方法的调用来注册Nacos监听器

![image-20230311065244186][]

*  3.4、接下来接着查看registerNacosListenersForApplications方法如何绑定的监听器，我们看到是调用registerNacosListener()方法给每一个dataId绑定监听器。

![image-20230311065910627][]

*  3.5、接下来我们点到registerNacosListener方法中，看到给使用dataId与groupId生成的key绑定一个AbstractSharedListener抽象实现类的监听器，需要注意的时候该实现类中的实现的innerReceive()方法会发出一个RefreshEvent事件，该事件会触发带有@RefreshScope注解的类刷新。

![image-20230311070043576][]

*  3.6、至此我们看到了绑定监听器的过程，接下来我们回到之前的地方。

--------------------

2.10、此时回到CacheData类的checkListenerMd5()方法中，该方法调用了safeNotifyListener()方法

![image-20230311070826494][]

2.11、打开safeNotifyListener()方法，看到Listener被强转为AbstractSharedListener修改了其中的dataId与group

![image-20230311070932641][]

2.12、随后调用了AbstractSharedListener类的receiveConfigInfo()方法，该方法中我们在上文提到过该方法中会发布出一个RefreshEvent事件，该事件会触发带有@RefreshScope注解的类刷新。

![image-20230311071319772][]

*  # @RefreshScope概述 #
    
     *  @RefreshScope注解标注了@Scope注解，井默认了ScopedProxyMode.TARGET\_CLASS  
        属性，此属性的功能就是创建一个代理，在每次调用的时候都用它来调用GenericScope\#get方法来获取bean对象
     *  在GenericScope里面包装了一个内部类BeanLifecycleWrapperCache来对加了  
        @RefreshScope的bean进行缓存，使其在不刷新时获取的都是同一个对象
     *  如属性发生变更会调用ContextRefresher\#frefresh()一>RefreshScope\#refreshAll()进行缓存  
        清理方法调用，并发送刷新事件通知一>调用GenericScope\#destroy()实现清理缓存
     *  当下一次使用此bean对象时，代理对象会调用GenericScoper\#get(String name,  
        ObjectFactory<?>objectFactory)方法创建一个新的bean对象，井存入缓存中，此时新对象因为Spring的装配机制就是新的属性了

[image-20230311052048583]: https://img-blog.csdnimg.cn/img_convert/de7e51f43bf8094569db0ee43d9b803c.png
[image-20230311052539842]: https://img-blog.csdnimg.cn/img_convert/3962aa5bb9f31eedb58f206757fa64e4.png
[image-20230311052913557]: https://img-blog.csdnimg.cn/img_convert/554391287bf378d0ec9c085babccb2c9.png
[image-20230311054017540]: https://img-blog.csdnimg.cn/img_convert/764e5766bc49c7525e075f08674cf940.png
[image-20230311055333689]: https://img-blog.csdnimg.cn/img_convert/1d7d3f79a83bd254f1f53f2a88eac17f.png
[image-20230311061429849]: https://img-blog.csdnimg.cn/img_convert/777e122b969125542002792e99b2839f.png
[image-20230311061628943]: https://img-blog.csdnimg.cn/img_convert/21c099f46b7f5318b2328499a07fa804.png
[image-20230311061728396]: https://img-blog.csdnimg.cn/img_convert/a7ddb112b14ded307fb1d59939b7c702.png
[image-20230311062409691]: https://img-blog.csdnimg.cn/img_convert/07e3ab730ef4151903ea62e87c12b5ba.png
[image-20230311063653075]: https://img-blog.csdnimg.cn/img_convert/8fc4679db6fa3dc0f86446a5814a6016.png
[image-20230311063839977]: https://img-blog.csdnimg.cn/img_convert/29a99ba2660156ba19f4f4d7d2010dda.png
[image-20230311064047195]: https://img-blog.csdnimg.cn/img_convert/4004e369e15fa055a14637b6664ee4fb.png
[image-20230311064134822]: https://img-blog.csdnimg.cn/img_convert/583aafabfcfa2c41b06d36b7b6c5aee1.png
[image-20230311065040389]: https://img-blog.csdnimg.cn/img_convert/0c671c16b47bd9a37757595dcb67cc70.png
[image-20230311065209722]: https://img-blog.csdnimg.cn/img_convert/33265b51cb933020bb29e2d2e7e80415.png
[image-20230311065244186]: https://img-blog.csdnimg.cn/img_convert/87b5d73ecd8d100f18f51f2c75fac78d.png
[image-20230311065910627]: https://img-blog.csdnimg.cn/img_convert/e9c22b99a3374bcb6fb839ca049b6ed5.png
[image-20230311070043576]: https://img-blog.csdnimg.cn/img_convert/6820b73a04d3fcd3e735b79a330a4999.png
[image-20230311070826494]: https://img-blog.csdnimg.cn/img_convert/ff1389392cf46570f7e34f4ec7867f88.png
[image-20230311070932641]: https://img-blog.csdnimg.cn/img_convert/2bf50b71b95ae274c06b9cfa46fd8746.png
[image-20230311071319772]: https://img-blog.csdnimg.cn/img_convert/ae025c9e4d1315717c280b13dbb5ed01.png