SpringCloud项目中SpringBoot在启动阶段除了会创建SpringBoot容器,还会通过bootstrap.yml构建一个SpringCloud容器,之后会在准备上下文阶段通过SPI加载实现类后,会进行配置合并。
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 端数据是否更新。其实时性不好,且可能会产生数据更新的丢失。
那什么是长轮询呢?
- 长轮询模型整合了 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方法则会触发刷新的方法。
2.10、此时回到CacheData类的checkListenerMd5()方法中,该方法调用了safeNotifyListener()方法
2.11、打开safeNotifyListener()方法,看到Listener被强转为AbstractSharedListener修改了其中的dataId与group
2.12、随后调用了AbstractSharedListener类的receiveConfigInfo()方法,该方法中我们在上文提到过该方法中会发布出一个RefreshEvent事件,该事件会触发带有@RefreshScope注解的类刷新。