Nacos回调机制

目录

1. 创建 ConfigService并实例化 ConfigService

1）ConfigFactory.createConfigService()创建ConfigService

2）NacosConfigService 的构造方法实例化 ConfigService ：

HttpAgent

ClientWorker

--checkConfigInfo()：

--LongPollingRunnable

    ① 本地检查

    ② 服务端检查

2. 添加Listener

ClientWorker.addTenantListeners()

CacheData类

3. 触发回调

cacheData.checkListenerMd5()

safeNotifyListener()

---

Nacos的动态配置：

nacos 服务端保存了配置信息，客户端连接到服务端之后，根据 dataID，group可以获取到具体的配置信息，当服务端的配置发生变更时，客户端会收到通知。

Nacos回调机制：

• Nacos 服务端创建了相关的配置项（创建 ConfigService并实例化 ConfigService）。
• 客户端就可以进行监听了（添加 Listener）。
• 客户端通过一个定时任务（cacheData.checkListenerMd5()）来检查自己监听的配置项的数据的，一旦服务端的数据发生变化时，客户端将会获取到最新的数据，并将最新的数据保存在一个 CacheData 对象中，然后会重新计算 CacheData 的 md5 属性的值，此时（safeNotifyListener()）就会对该 CacheData 所绑定的 Listener 触发 receiveConfigInfo 回调。

demo：

package com.learn.nacos;
 
import com.alibaba.nacos.api.NacosFactory;
import com.alibaba.nacos.api.config.ConfigService;
import com.alibaba.nacos.api.config.listener.Listener;
import com.alibaba.nacos.api.exception.NacosException;
 
import java.util.Properties;
import java.util.concurrent.Executor;
 
/**
 * @author liuliuyang001
 *
 */
public class NacosConfig {
 
    public static void main(String[] args) {
        try {
            String serverAddr = "127.0.0.1:8848";
            String dataId = "nacos-sdk-java-config";
            String group = "DEFAULT_GROUP";
            String content = "nacos-sdk-java-config:init";
            Properties properties = new Properties();
            properties.put("serverAddr", serverAddr);
 
            // 方式一：创建ConfigService
            ConfigService configService = NacosFactory.createConfigService(serverAddr);
 
            // 方式二：创建ConfigService
            //ConfigService configService = ConfigFactory.createConfigService(serverAddr);
 
            // 方式三：创建ConfigService
            //ConfigService configService = NacosFactory.createConfigService(properties);
 
            // 方式四：创建ConfigService
            //ConfigService configService = ConfigFactory.createConfigService(properties);
 
            // 获取服务状态
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,服务状态：" + configService.getServerStatus());
 
            Listener configListener = new Listener() {
                public Executor getExecutor() {
                    return null;
                }
 
                public void receiveConfigInfo(String configInfo) {
                    System.out.println("当前线程：" + Thread.currentThread().getName() + " ,监听到配置内容变化：" + configInfo);
                }
            };
 
            // 添加监听（有时候能监听到，有时候监听不到，为什么？）
            System.out.println("添加监听");
            configService.addListener(dataId, group, configListener);
            System.out.println("添加监听成功");
 
            // 发布配置（多次运行，有时候会获取不到配置内容，难道要等待一段时间才能获取？）
            System.out.println("发布配置");
            configService.publishConfig(dataId, group, content);
            System.out.println("发布配置成功");
          
            try {
                Thread.sleep(1000 * 3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
 
            // 本地缓存：\nacos\config\fixed-127.0.0.1_8848_nacos\snapshot\DEFAULT_GROUP
            // 读取配置
            String configAfterPublish = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,发布配置后获取配置内容：" + configAfterPublish);
 
            // 重新发布配置
            content = "sdk-java-config:update";
            System.out.println("重新发布配置");
            boolean rePublishFlag = configService.publishConfig(dataId, group, content);
            if(rePublishFlag) {
                System.out.println("重新发布配置成功");
            } else {
                System.out.println("重新发布配置失败");
            }
 
            // 重新读取配置
            String configAfterUpdate = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,重新发布配置后获取配置内容：" + configAfterUpdate);
 
            try {
                Thread.sleep(1000 * 30);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
 
            // 移除配置
            System.out.println("移除配置");
            boolean removeFlag = configService.removeConfig(dataId, group);
            if(removeFlag) {
                System.out.println("移除配置成功");
            } else {
                System.out.println("移除配置失败");
            }
 
         try {
                Thread.sleep(1000 * 3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
          
            String configAfterRemove = configService.getConfig(dataId, group, 3000);
            System.out.println("当前线程：" + Thread.currentThread().getName() + " ,移除配置后获取配置内容：" + configAfterRemove);
 
          /*  // 取消监听
            System.out.println("取消监听");
            configService.removeListener(dataId, group, configListener);
            System.out.println("取消监听成功");*/
        } catch (NacosException e) {
            e.printStackTrace();
        }
    }
}

1. 创建 ConfigService并实例化 ConfigService

1）ConfigFactory.createConfigService()创建ConfigService

实际是通过反射调用了 NacosConfigService 的构造方法来创建 ConfigService 的，而且是有一个 Properties 参数的构造方法。
需要注意的是，这里并没有通过单例或者缓存技术，也就是说每次调用都会重新创建一个 ConfigService的实例。

2）NacosConfigService 的构造方法实例化 ConfigService ：

实例化时主要是初始化了两个对象，他们分别是：

• HttpAgent
• ClientWorker

HttpAgent

agent 是通过装饰者模式实现的，ServerHttpAgent 是实际工作的类，MetricsHttpAgent 在内部也是调用了 ServerHttpAgent 的方法，另外加上了一些统计操作，所以我们只需要关心 ServerHttpAgent 的功能就可以了。

ClientWorker

• 第一个线程池是只拥有一个线程用来执行定时任务的 executor，executor 每隔 10ms 就会执行一次 checkConfigInfo() 方法，从方法名上可以知道是每 10 ms 检查一次配置信息。
• 第二个线程池是一个普通的线程池，从 ThreadFactory 的名称可以看到这个线程池是做长轮询LongPollingRunnable的。

--checkConfigInfo()：

checkConfigInfo方法是取出了一批任务，然后提交给executorService线程池去执行，执行的任务就是LongPollingRunnable，每个任务都有一个 taskId。

--LongPollingRunnable

    ① 本地检查

首先取出与该 taskId 相关的 CacheData，然后对 CacheData 进行检查，包括本地配置检查和监听器的 md5 检查，本地检查主要是做一个故障容错，当服务端挂掉后，Nacos 客户端可以从本地的文件系统中获取相关的配置信息，如下图所示：

    ② 服务端检查

通过 checkUpdateDataIds() 方法从服务端获取那些值发生了变化的 dataId 列表，
通过 getServerConfig 方法，根据 dataId 到服务端获取最新的配置信息，接着将最新的配置信息保存到 CacheData 中。
最后调用 CacheData 的 checkListenerMd5 方法，可以看到该方法在第一部分也被调用过。

在该任务的最后，也就是在 finally 中又重新通过 executorService 提交了本任务。

2. 添加Listener

ClientWorker.addTenantListeners()

调用了ClientWorker 的 addTenantListeners 方法为 ConfigService 来添加一个 Listener

• 首先根据 dataId，group 和当前的场景获取一个 CacheData 对象
• 然后将当前要添加的 listener 对象添加到 CacheData 中去。

listener 最终是被这里的 CacheData 所持有了，那 listener 的回调方法 receiveConfigInfo 就应该是在 CacheData 中触发的。CacheData 是出现频率非常高的一个类，在 LongPollingRunnable 的任务中，几乎所有的方法都围绕着 CacheData 类，现在添加 Listener 的时候，实际上该 Listener 也被委托给了 CacheData。

CacheData类

成员变量：

• dataId，group，content，taskId：跟配置相关的属性
• listeners：该 CacheData 所关联的所有 listener，不过不是保存的原始的 Listener 对象，而是包装后的ManagerListenerWrap 对象，该对象除了持有 Listener 对象，还持有了一个 lastCallMd5 属性。
•  md5：根据当前对象的 content 计算出来的 md5 值。

3. 触发回调

cacheData.checkListenerMd5()

在 ClientWorker 中的定时任务中，启动了一个长轮询的任务：LongPollingRunnable，该任务多次执行了 cacheData.checkListenerMd5() 方法：

该方法会检查 CacheData 当前的 md5 与 CacheData 持有的所有 Listener 中保存的 md5 的值是否一致，如果不一致，就执行一个安全的监听器的通知方法：safeNotifyListener()，通应该是通知 Listener 的使用者，该 Listener 所关注的配置信息已经发生改变了。

safeNotifyListener()

那 CacheData 的 md5 值是何时发生改变的呢？我们可以回想一下，在上面的 LongPollingRunnable 所执行的任务中，在获取服务端发生变更的配置信息时，将最新的 content 数据写入了 CacheData 中，我们可以看下该方法如下：

在长轮询的任务中，当服务端配置信息发生变更时，客户端将最新的数据获取下来之后，保存在了 CacheData 中，同时更新了该 CacheData 的 md5 值，所以当下次执行 checkListenerMd5 方法时，就会发现当前 listener 所持有的 md5 值已经和 CacheData 的 md5 值不一样了，也就意味着服务端的配置信息发生改变了，这时就需要将最新的数据通知给 Listener 的持有者。

Nacos 并不是通过推的方式将服务端最新的配置信息发送给客户端的，而是客户端维护了一个长轮询的任务，定时去拉取发生变更的配置信息，然后将最新的数据推送给 Listener 的持有者。