Nacos配置拉取及配置刷新原理
一、初始化时获取配置文件
背景
SpringCloud项目中SpringBoot在启动阶段除了会创建SpringBoot容器,还会通过bootstrap.yml构建一个SpringCloud容器,之后会在准备上下文阶段通过SPI加载实现类后,会进行配置合并。
NacosPropertySourceLocator类
1、该类为拉取nacos配置文件的核心类,在结果SPI加载时NacosPropertySourceLocator作为PropertySourceLocator的实现类,也将被加载到PropertySourceBootstrapConfiguration中参加遍历。
2、最后来到NacosPropertySourceLocator类的locate方法,在该方法中会通过nacosConfigManager来获取ConfigService接口实现类
3、该方法结果调用最后会通过反射获取NacosConfigService对象的有参构造器创建并返回
4、回到上面的locate方法,最后开始加载配置文件,此处会加载三种类型配置文件,分别为共享配置文件、拓展配置文件、应用自身的配置文件。此时由于顺序的原因导致覆盖我们可以得出优先级为从下至上,而其中每一种配置文件的加载都会有三种加载方式,分别是从本地获取,再从nacos获取,为从nacos获取时网络异常等原因导致获取失败,最后一种获取方式为从快照获取(快照的来源为每一种成功从nacos获取后保存)。
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属性构造。该属性即为配置刷新的核心。
2.2、来到ClientWorker构造方法,我们可以看到其中有两个周期线程池,其中executor线程池就是为了控制发出配置检测的间隔,为10秒一次,断开连接默认为3秒
2.3、接下来我们看到发出配置检测请求的checkConfigInfo()方法
ParamUtil.getPerTaskConfigSize()的值为3000,currentLongingTaskCount默认为0,所以正常情况下都只是循环一次
2.4、接下来我们点到LongPollingRunnable看着像长轮询的类,该类实现了Runnable接口,查看其run方法。
以下是使用本地配置时检测是否更新
2.5、然后开始检测并获得远程的变化了的key
2.6、然后获取到对应的value设置新值且计算md5,md5即用于比较是否发现变化,注意其中的setContent方法
public void setContent(String content) {
this.content = content;
this.md5 = getMd5String(this.content);
}
2.7、随后开始检测并开启下一次任务
2.8、接下来我们打开检测是否变化的方法checkListenerMd5()
2.9、发现发生变化后将会调用safeNotifyListener方法,safeNotifyListener方法则会触发刷新的方法。
补充
- 3.1、在介绍该方法之前我们补充以下之前遗漏的初始化监听器的步骤,在springboot准备完环境后将会发出ApplicationReadyEvent事件。而在NacosConfigAutoConfiguration配置类中注入了一个NacosContextRefresher对象
- 3.2、我们打开NacosContextRefresher对象,看到该类实现了ApplicationListener接口,并且监听事件刚好为上步骤中提到的ApplicationReadyEvent事件。
- 3.3、接下来我们看看他的监听方法中做了什么,看到使用了CAS来控制registerNacosListenersForApplications方法的调用来注册Nacos监听器
- 3.4、接下来接着查看registerNacosListenersForApplications方法如何绑定的监听器,我们看到是调用registerNacosListener()方法给每一个dataId绑定监听器。
- 3.5、接下来我们点到registerNacosListener方法中,看到给使用dataId与groupId生成的key绑定一个AbstractSharedListener抽象实现类的监听器,需要注意的时候该实现类中的实现的innerReceive()方法会发出一个RefreshEvent事件,该事件会触发带有@RefreshScope注解的类刷新。
- 3.6、至此我们看到了绑定监听器的过程,接下来我们回到之前的地方。
2.10、此时回到CacheData类的checkListenerMd5()方法中,该方法调用了safeNotifyListener()方法
2.11、打开safeNotifyListener()方法,看到Listener被强转为AbstractSharedListener修改了其中的dataId与group
2.12、随后调用了AbstractSharedListener类的receiveConfigInfo()方法,该方法中我们在上文提到过该方法中会发布出一个RefreshEvent事件,该事件会触发带有@RefreshScope注解的类刷新。
-
@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的装配机制就是新的属性了
- @RefreshScope注解标注了@Scope注解,井默认了ScopedProxyMode.TARGET_CLASS