目录
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 的持有者。