通过上篇，我们把基本的环境搭建好，可以着手去源码层面去看看nacos的数据同步实现。
soul-admin
- 找到数据同步配置的入口
DataSyncConfiguration，我们可以看到关于Nacos配置监听的初始化类NacosListener -
当然下图会更直观
DatasSyncConfiguration - 我们再看下
NacosListener该类的实现
NacosListener - 分为两块：数据变更监听
NacosDataChangedListener和数据初始化的处理NacosDataInit
数据初始化的处理-NacosDataInit
- 先看数据初始化的处理
NacosDataInit。该类实现了spring的CommandLineRunner，也就是这个bean是属于spring应用的一部分，程序启动时会自动执行该bean的run方法，我们看下run方法逻辑
public void run(final String... args) {
// 存在三部分的data，plugin & auth & meta
String pluginDataId = NacosPathConstants.PLUGIN_DATA_ID;
String authDataId = NacosPathConstants.AUTH_DATA_ID;
String metaDataId = NacosPathConstants.META_DATA_ID;
// 只有当admin的配置数据没有在nacos上存在时，才同步所有数据
if (dataIdNotExist(pluginDataId) && dataIdNotExist(authDataId) && dataIdNotExist(metaDataId)) {
syncDataService.syncAll(DataEventTypeEnum.REFRESH);
}
}
- 我们知道，整个
soul-admin中的配置变更，都是通过spring的应用事件机制实现。初始化中调用syncDataService.syncAll则会从soul-admin数据库中取出所有的配置数据（plugin & selector & rule & auth），并发布DataChangedEvent的数据变更事件。
public boolean syncAll(final DataEventTypeEnum type) {
appAuthService.syncData();
List<PluginData> pluginDataList = pluginService.listAll();
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.PLUGIN, type, pluginDataList));
List<SelectorData> selectorDataList = selectorService.listAll();
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.SELECTOR, type, selectorDataList));
List<RuleData> ruleDataList = ruleService.listAll();
eventPublisher.publishEvent(new DataChangedEvent(ConfigGroupEnum.RULE, type, ruleDataList));
metaDataService.syncData();
return true;
}
- 在前面文章分析，我们可以知道，对于配置数据变更是由
DataChangedEventDispatcher来接收事件的处理，其主要逻辑就是遍历DataChangedListener的bean，然后根据配置的不同类型去调用listener中不同的方法 - 当我们采用
nacos的同步时，则会调用NacosDataChangedListener的相关方法
数据变更监听-NacosDataChangedListener
- 我们只分析插件数据的变更处理
onPluginChanged，其余类型的变更处理类似
public void onPluginChanged(final List<PluginData> changed, final DataEventTypeEnum eventType) {
// 1. 更新加载到内存的数据
// 更新策略：将原有内存中的数据清掉，然后将nacos拉回来的数据重新载入到内存
updatePluginMap(getConfig(NacosPathConstants.PLUGIN_DATA_ID));
// 2. 处理此次变更的数据
switch (eventType) {
case DELETE:
changed.forEach(plugin -> PLUGIN_MAP.remove(plugin.getName()));
break;
case REFRESH:
case MYSELF:
Set<String> set = new HashSet<>(PLUGIN_MAP.keySet());
// 替换掉内存中的数据，以数据库全量的内容为准
// 也就是说，每次的REFRESH或者MYSELF变更，传过来的数据都是当前数据库的全量数据
changed.forEach(plugin -> {
set.remove(plugin.getName());
PLUGIN_MAP.put(plugin.getName(), plugin);
});
PLUGIN_MAP.keySet().removeAll(set);
break;
default:
changed.forEach(plugin -> PLUGIN_MAP.put(plugin.getName(), plugin));
break;
}
// 3. 再发布处理完之后的配置给到nacos
publishConfig(NacosPathConstants.PLUGIN_DATA_ID, PLUGIN_MAP);
}
总结
soul-admin端配置数据同步采用nacos，其大致处理流程如下：
-
soul-admin端的数据同步分为两块：数据变更监听NacosDataChangedListener和数据初始化的处理NacosDataInit； - 当
soul-admin启动时就会将所有配置数据从数据库加载出来，发布数据变更事件；如果是有多个节点，则都是同样的操作，也就是每个启动启动时，都会从数据库拉取到所有配置数据，同步到nacos - 数据变更的监听器
NacosDataChangedListener，会监听到数据变更的事件，根据不同的配置类型，调用不同的处理方法onXxxChanged进行处理 - 所有的配置数据都会先在内存放置一份，
NacosDataChangedListener中XXX_MAP存放； - 当有配置变更时，先从
nacos中拉取一份配置下来，将现有内存XXX_MAP中存放的数据清除，然后用nacos拉取的配置进行替换； - 如果要
delete或者add，则直接在nacos拉取的配置上进行对应操作；如果是refresh，则需要再将当前数据库中最新配置替换掉nacos拉取的配置 - 采用此策略同步配置时，
soul-admin的各节点中的内存会存在不一致的情况。不过没有关系，因为每次同步之前都会从nacos取回数据再进行操作。
soul-bootstrap
接下来分析soul-bootstrap端。
-
先看下关键类图
bootstrap-nacos-syn-data -
NacosSyncDataConfiguration配置中会初始化bean：NacosSyncDataService与nacos的ConfigService -
nacos数据同步服务实例化过程中会执行启动逻辑，改逻辑会监听nacos上各个类型的数据配置
public NacosSyncDataService(final ConfigService configService, final PluginDataSubscriber pluginDataSubscriber,
final List<MetaDataSubscriber> metaDataSubscribers, final List<AuthDataSubscriber> authDataSubscribers) {
super(configService, pluginDataSubscriber, metaDataSubscribers, authDataSubscribers);
start();
}
public void start() {
// 监听逻辑
watcherData(PLUGIN_DATA_ID, this::updatePluginMap);
watcherData(SELECTOR_DATA_ID, this::updateSelectorMap);
watcherData(RULE_DATA_ID, this::updateRuleMap);
watcherData(META_DATA_ID, this::updateMetaDataMap);
watcherData(AUTH_DATA_ID, this::updateAuthMap);
}
- 看下这里的
watchData逻辑
protected void watcherData(final String dataId, OnChange oc) {
// 创建nacos的监听器
Listener listener = new Listener() {
@Override
public void receiveConfigInfo(final String configInfo) {
// 监听的处理逻辑
oc.change(configInfo);
}
@Override
public Executor getExecutor() {
return null;
}
};
// 初始拉取一次配置，并处理配置
oc.change(getConfigAndSignListener(dataId, listener));
// 添加nacos的配置监听，computeIfAbsent线程安全
LISTENERS.computeIfAbsent(dataId, key -> new ArrayList<>()).add(listener);
}
- 从上得知，
nacos配置监听的逻辑实际上就是调用updateXXXMap方法，我们以updatePluginMap为例
protected void updatePluginMap(final String configInfo) {
try {
List<PluginData> pluginDataList = new ArrayList<>(GsonUtils.getInstance().toObjectMap(configInfo, PluginData.class).values());
// 将从nacos获取到的插件配置，更新内存中的配置
// 更新策略：先remove cache, 然后再put，一个个处理
pluginDataList.forEach(pluginData -> Optional.ofNullable(pluginDataSubscriber).ifPresent(subscriber -> {
// 先删数据
subscriber.unSubscribe(pluginData);
// 然后添加数据
subscriber.onSubscribe(pluginData);
}));
} catch (JsonParseException e) {
log.error("sync plugin data have error:", e);
}
}
- 该方法的基本逻辑是将从
nacos获取到的配置，去更新soul-boostrap端内存中存储的配置 - 其更新的策略是先删除配置数据，然后将新的数据添加到内存
- 更新的调用逻辑如下：
- 删除配置：
PluginDataSubscriber.unSubscribe->CommonPluginDataSubscriber.unSubscribe->CommonPluginDataSubscriber.subscribeDataHandler->BaseDataCache.getInstance().removePluginData->PluginDataHandler.removePlugin - 添加配置：
PluginDataSubscriber.onSubscribe->CommonPluginDataSubscriber.onSubscribe->CommonPluginDataSubscriber.subscribeDataHandler->BaseDataCache.getInstance().cachePluginData->PluginDataHandler.handlerPlugin
- 删除配置：
- 关于
nacos如何实现的配置变更的监听这里就不展开了，对于应用端，只要完成NacosConfigService初始化以及添加监听逻辑就行了。
总结
在分析了soul-admin与soul-bootstrap基于nacos的配置数据同步实现后，感觉相比较HttpLongPolling的在代码实现层面要简单一些。主要的差别在于配置变更监听的实现：对于nacos的实现方式而言，因nacos本身就是一个配置服务中间件，其提供的nacos-client能在nacos-server端配置存在变更后，nacos-client端就能获取到变更的配置，通过client端添加自身配置变更监听的逻辑后，就能完成soul-bootstrap内存中配置数据的更新；而HttpLongPolling则需要自身完成配置变更监听机制，实现逻辑会更复杂些。
