nacos源码带读

关于拓展的配置不支持yaml的问题定位

修改配置的时候，发现nacos读取到了准确的配置，但是转换的时候错误了，刷新的key错误。
比如yaml的配置是

data:
	test: 11

最后刷新的是test

跟踪key

先定位结果的出处

根据打印日志的类跟踪，最后发现nacos通过从上下文中获取到配置的，代码如下

        Map<String, Object> before = this.extract(this.context.getEnvironment().getPropertySources());
        this.addConfigFilesToEnvironment();
        Set<String> keys = this.changes(before, this.extract(this.context.getEnvironment().getPropertySources())).keySet();
        this.context.publishEvent(new EnvironmentChangeEvent(this.context, keys));
        return keys;

通过对比得到值不同的key，然后根据得到的key进行刷新数据，所以这里的关键是为啥key和value的匹配出错了。通过debug发现，nacos通过spring的监听来实现对配置文件的读取，读取到配置后有一个刷新配置的过程。

debug跳了很久，感觉大海捞针，差点放弃

定位过程中发现nacos配置的先后等级

然后从文件格式的配置出发去打端点，在下面的代码上打断点

String fileExtension = properties.getFileExtension();

发现在刷新上下文的时候，有下面的代码

loadApplicationConfiguration(composite, dataIdPrefix, nacosConfigProperties, env);

composite是需要刷新的配置，dataIdPrefix就是从配置文件中获取的，

		String name = nacosConfigProperties.getName();

		String dataIdPrefix = nacosConfigProperties.getPrefix();
		if (StringUtils.isEmpty(dataIdPrefix)) {
			dataIdPrefix = name;
		}

		if (StringUtils.isEmpty(dataIdPrefix)) {
			dataIdPrefix = env.getProperty("spring.application.name");
		}

第一name是nacos配置的dataId名字，第二个dataIdPrefix是配置文件的值，第三个是读取spring.application.name。

下面是执行添加配置的操作

		// load directly once by default
		loadNacosDataIfPresent(compositePropertySource, dataIdPrefix, nacosGroup,
				fileExtension, true);
		// load with suffix, which have a higher priority than the default
		loadNacosDataIfPresent(compositePropertySource,
				dataIdPrefix + DOT + fileExtension, nacosGroup, fileExtension, true);
		// Loaded with profile, which have a higher priority than the suffix
		for (String profile : environment.getActiveProfiles()) {
			String dataId = dataIdPrefix + SEP1 + profile + DOT + fileExtension;
			loadNacosDataIfPresent(compositePropertySource, dataId, nacosGroup,
					fileExtension, true);
		}

也就是存在三种方式文件名添加，一个是前缀，第二个加active，第三个加文件后缀

this.addFirstPropertySource(composite, propertySource, false);

最后添加到配置的头部，也就是说这种配置方式优先级比较高。

监听器有一处间接说明了配置的读取格式

回到监听器，有两个，一个是springboot的监听，另一个是配置文件的监听。
看配置文件的监听

最终发现了下面的代码

FilteredPropertySource.apply(this.environment, "defaultProperties", ConfigFileApplicationListener.LOAD_FILTERED_PROPERTY, (defaultProperties) -> {

也就是说默认是Properties。

最后发现了根源

回到加载上面三种配置文件的方法

private NacosPropertySource loadNacosPropertySource(final String dataId,
			final String group, String fileExtension, boolean isRefreshable) {
		if (NacosContextRefresher.getRefreshCount() != 0) {
			if (!isRefreshable) {
				return NacosPropertySourceRepository.getNacosPropertySource(dataId,
						group);
			}
		}
		return nacosPropertySourceBuilder.build(dataId, group, fileExtension,
				isRefreshable);
	}

对于拓展配置文件的调用是

	private void loadNacosConfiguration(final CompositePropertySource composite,
			List<NacosConfigProperties.Config> configs) {
		for (NacosConfigProperties.Config config : configs) {
			loadNacosDataIfPresent(composite, config.getDataId(), config.getGroup(),
					NacosDataParserHandler.getInstance()
							.getFileExtension(config.getDataId()),
					config.isRefresh());
		}
	}

关键就是getFileExtension方法，从名字可以看出是获取后缀，继续看下面代码

	public String getFileExtension(String name) {
		if (StringUtils.isEmpty(name)) {
			return DEFAULT_EXTENSION;
		}
		int idx = name.lastIndexOf(DOT);
		if (idx > 0 && idx < name.length() - 1) {
			return name.substring(idx + 1);
		}
		return DEFAULT_EXTENSION;
	}

从上面就可以看出，最终的文件格式取决于dataId的后缀。

总结

整个过程走完，比较庆幸nacos有文件的配置方式，如果说没有这个配置的修改，那么什么时候能找到问题还比较难说。

回过头看问题，在一次进入问题，然后debug到差点放弃的时候，可以从文件的出发，nacos的类命名还是比较有规律的，比如NacosPropertySourceLocator，翻译过来就是nacos配置源加载器。