Disconf源码分析之启动过程分析下（2）
接上文，下面是第二次扫描的XML配置。
<bean id="disconfMgrBean2" class="com.baidu.disconf.client.DisconfMgrBeanSecond"
init-method="init" destroy-method="destroy">
</bean>
查看init()方法，会调用DisconfMgr的secondScan()方法。
protected synchronized void secondScan() {
// 上面是顺序的校验
try {
// 扫描回调函数
if (scanMgr != null) {
scanMgr.secondScan();
}
// 注入数据至配置实体中
// 获取数据/注入/Watch
if (disconfCoreMgr != null) {
disconfCoreMgr.inject2DisconfInstance();
}
} catch (Exception e) {
LOGGER.error(e.toString(), e);
}
isSecondInit = true;
}
scanMgr是扫描处理器，调用第二次扫描的secondScan()方法。主要处理如下
// 将回调函数实例化并写入仓库
ScanDynamicStoreAdapter.scanUpdateCallbacks(scanModel, registry);
ScanDynamicStoreAdapter是动态扫描与Store模块的转换器。下面主要对回调函数的处理。
// ScanStaticModel是第一次扫描结束得到的静态配置存储的对象
public static void scanUpdateCallbacks(ScanStaticModel scanModel, Registry registry) {
// 扫描出来
ScanDynamicModel scanDynamicModel = analysis4DisconfUpdate(scanModel, registry);
// 写到仓库中
transformUpdateService(scanDynamicModel.getDisconfUpdateServiceInverseIndexMap());
transformPipelineService(scanDynamicModel.getDisconfUpdatePipeline());
}
analysis4DisconfUpdate()会将配置中和回调相关的配置扫描处理。
private static ScanDynamicModel analysis4DisconfUpdate(ScanStaticModel scanModel, Registry registry) {
// 配置项或文件，DisconfKey通过配置类型和名称来标记一个配置key
Map<DisconfKey, List<IDisconfUpdate>> inverseMap = new HashMap<DisconfKey, List<IDisconfUpdate>>();
// disconfUpdateService是第一次扫描和回调相关的配置，@DisconfUpdateService注解
Set<Class<?>> disconfUpdateServiceSet = scanModel.getDisconfUpdateService();
for (Class<?> disconfUpdateServiceClass : disconfUpdateServiceSet) {
// 回调对应的参数
DisconfUpdateService disconfUpdateService =
disconfUpdateServiceClass.getAnnotation(DisconfUpdateService.class);
// 校验是否有继承正确,是否继承IDisconfUpdate
if (!ScanVerify.hasIDisconfUpdate(disconfUpdateServiceClass)) {
continue;
}
// 获取回调接口实例
IDisconfUpdate iDisconfUpdate = getIDisconfUpdateInstance(disconfUpdateServiceClass, registry);
if (iDisconfUpdate == null) {
continue;
}
// 主要逻辑，将DisconfKey作为key、回调接口作为list vlaue，存入到inverseMap中
// 配置项
processItems(inverseMap, disconfUpdateService, iDisconfUpdate);
//
// 配置文件
processFiles(inverseMap, disconfUpdateService, iDisconfUpdate);
}
// set data，存储所有和回调相关配置结果集合
ScanDynamicModel scanDynamicModel = new ScanDynamicModel();
scanDynamicModel.setDisconfUpdateServiceInverseIndexMap(inverseMap);
//
// set update pipeline，实现iDisconfUpdatePipeline接口的处理
//
if (scanModel.getiDisconfUpdatePipeline() != null) {
IDisconfUpdatePipeline iDisconfUpdatePipeline = getIDisconfUpdatePipelineInstance(scanModel
.getiDisconfUpdatePipeline(), registry);
if (iDisconfUpdatePipeline != null) {
// 存储到scanDynamicModel中
scanDynamicModel.setDisconfUpdatePipeline(iDisconfUpdatePipeline);
}
}
return scanDynamicModel;
}
返回以后，会将结果存储到Store仓库中。两种回调方式分别处理。
transformUpdateService(scanDynamicModel.getDisconfUpdateServiceInverseIndexMap());
transformPipelineService(scanDynamicModel.getDisconfUpdatePipeline());
private static void transformUpdateService(Map<DisconfKey,
List<IDisconfUpdate>> disconfUpdateServiceInverseIndexMap) {
// 分别取出配置文件仓库和配置项仓库处理器
DisconfStoreProcessor disconfStoreProcessorFile = DisconfStoreProcessorFactory.getDisconfStoreFileProcessor();
DisconfStoreProcessor disconfStoreProcessorItem = DisconfStoreProcessorFactory.getDisconfStoreItemProcessor();
for (DisconfKey disconfKey : disconfUpdateServiceInverseIndexMap.keySet()) {
try {
if (disconfKey.getDisConfigTypeEnum().equals(DisConfigTypeEnum.FILE)) {
// 如果是文件，第一次静态扫描结束后，肯定会有对应的配置值
if (!disconfStoreProcessorFile.hasThisConf(disconfKey.getKey())) {
throw new Exception();
}
// 存储到仓库的回调函数属性中
disconfStoreProcessorFile.addUpdateCallbackList(disconfKey.getKey(),
disconfUpdateServiceInverseIndexMap
.get(disconfKey));
} else if (disconfKey.getDisConfigTypeEnum().equals(DisConfigTypeEnum.ITEM)) {
// 配置项
if (!disconfStoreProcessorItem.hasThisConf(disconfKey.getKey())) {
throw new Exception();
}
// 存储到仓库的回调函数属性中
disconfStoreProcessorItem.addUpdateCallbackList(disconfKey.getKey(),
disconfUpdateServiceInverseIndexMap
.get(disconfKey));
}
} catch (Exception e) {
// 找不到回调对应的配置，这是用户配置 错误了
StringBuffer sb = new StringBuffer();
sb.append("cannot find " + disconfKey + "for: ");
for (IDisconfUpdate serClass : disconfUpdateServiceInverseIndexMap.get(disconfKey)) {
sb.append(serClass.toString() + "\t");
}
LOGGER.error(sb.toString());
}
}
}
对于pipeline回调函数类似的处理。
继续第二次扫描。
// 注入数据至配置实体中
// 获取数据/注入/Watch
if (disconfCoreMgr != null) {
disconfCoreMgr.inject2DisconfInstance();
}
该方法的处理，会分别处理File和item两项，分别调用DisconfCoreProcessor实现类（和第一次扫描处理类似）
for (DisconfCoreProcessor disconfCoreProcessor : disconfCoreProcessorList) {
disconfCoreProcessor.inject2Conf();
}
下面已File处理为例分析：
inject2Conf()的处理逻辑。
Object object;
try {
object = disconfCenterFile.getObject();
if (object == null) {
// 从上下文获取实例
object = registry.getFirstByType(disconfCenterFile.getCls(), false, true);
}
} catch (Exception e) {
LOGGER.error(e.toString());
object = null;
}
// 注入实体中
disconfStoreProcessor.inject2Instance(object, fileName);
继续向下看。
@Override
public void inject2Instance(Object object, String fileName) {
// 先取出配置存储对象
DisconfCenterFile disconfCenterFile = getInstance().getConfFileMap().get(fileName);
// 校验是否存在
if (disconfCenterFile == null) {
LOGGER.error("cannot find " + fileName + " in store....");
return;
}
//
// 非静态类
//
if (object != null) {
// 设置object
disconfCenterFile.setObject(object);
}
// 根据类型设置值
//
// 注入实体
//
Map<String, FileItemValue> keMap = disconfCenterFile.getKeyMaps();
for (String fileItem : keMap.keySet()) {
// 根据类型设置值
try {
//
// 静态类
//
if (object == null) {
if (keMap.get(fileItem).isStatic()) {
LOGGER.debug(fileItem + " is a static field. ");
keMap.get(fileItem).setValue4StaticFileItem(keMap.get(fileItem).getValue());
}
//
// 非静态类
//
} else {
LOGGER.debug(fileItem + " is a non-static field. ");
if (keMap.get(fileItem).getValue() == null) {
// 如果仓库值为空，则实例 直接使用默认值
Object defaultValue = keMap.get(fileItem).getFieldDefaultValue(object);
keMap.get(fileItem).setValue(defaultValue);
} else {
// 如果仓库里的值为非空，则实例使用仓库里的值
keMap.get(fileItem).setValue4FileItem(object, keMap.get(fileItem).getValue());
}
}
} catch (Exception e) {
LOGGER.error("inject2Instance fileName " + fileName + " " + e.toString(), e);
}
}
}
分别对静态和非静态对象属性赋值。
到这里位置第二次扫描结束了。
通过两次扫描加载的数据，都是通过注解式的分布式配置方式，Disconf同时支持XML非注解式配置方式，在上篇介绍的时候，我们留下了关于XML载入的配置处理的分析，下面分析下XML非注解式配置的源码。
对于非注解式配置，Disconf主要区分为properties文件和非properties文件（properties文件才支持自动reload）、是否自动载入reload到bean对象中（通过XML配置决定）。
我们先分析支持自动reload。
<!-- 使用托管方式的disconf配置(无代码侵入, 配置更改会自动reload)-->
<bean id="configproperties_disconf"
class="com.baidu.disconf.client.addons.properties.ReloadablePropertiesFactoryBean">
<property name="locations">
<list>
<value>classpath:/autoconfig.properties</value>
<value>classpath:/autoconfig2.properties</value>
</list>
</property>
</bean>
<bean id="propertyConfigurer"
class="com.baidu.disconf.client.addons.properties.ReloadingPropertyPlaceholderConfigurer">
<property name="ignoreResourceNotFound" value="true" />
<property name="ignoreUnresolvablePlaceholders" value="true" />
<property name="propertiesArray">
<list>
<ref bean="configproperties_disconf"/>
</list>
</property>
</bean>
解读上面的配置前，先了解下Spring提供的PropertyPlaceholderConfigurer类 ，它支持将properties文件中的配置项读取并在XML中通过#{}的方式读取，他的触发是因为实现了BeanFactoryPostProcessor接口，扩展了postProcessBeanFactory方法。
而Disconf就是在此基础上继续扩展，ReloadingPropertyPlaceholderConfigurer继承了PropertyPlaceholderConfigurer类。
首先看下ReloadablePropertiesFactoryBean类，它继承了PropertiesLoaderSupport类，入口是setLocations()方法。
public void setLocations(List<String> fileNames) {
List<Resource> resources = new ArrayList<Resource>();
for (String filename : fileNames) {
// trim
filename = filename.trim();
String realFileName = getFileName(filename);
//
// register to disconf
// 开始扫描，可以参考上文文件和配置项的扫描
//
DisconfMgr.getInstance().reloadableScan(realFileName);
//
// only properties will reload
//
String ext = FilenameUtils.getExtension(filename);
if (ext.equals("properties")) {
PathMatchingResourcePatternResolver pathMatchingResourcePatternResolver =
new PathMatchingResourcePatternResolver();
try {
Resource[] resourceList = pathMatchingResourcePatternResolver.getResources(filename);
for (Resource resource : resourceList) {
resources.add(resource);
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
this.locations = resources.toArray(new Resource[resources.size()]);
lastModified = new long[locations.length];
super.setLocations(locations);
}
reloadableScan()方法如下：
public synchronized void reloadableScan(String fileName) {
if (!isFirstInit) {
return;
}
if (DisClientConfig.getInstance().ENABLE_DISCONF) {
try {
// 判断是不是忽略同步的文件
if (!DisClientConfig.getInstance().getIgnoreDisconfKeySet().contains(fileName)) {
if (scanMgr != null) {
// 扫描配置
scanMgr.reloadableScan(fileName);
}
if (disconfCoreMgr != null) {
// 核心处理器处理
disconfCoreMgr.processFile(fileName);
}
LOGGER.debug("disconf reloadable file: {}", fileName);
}
} catch (Exception e) {
LOGGER.error(e.toString(), e);
}
}
}
scanMgr.reloadableScan()会执行StaticScannerNonAnnotationFileMgrImpl.scanData2Store();，注意StaticScannerNonAnnotationFileMgrImpl，在上文中，我们介绍了，扫描工具主要包括三种：文件、配置项、非注解配置。在第一次扫描的时候，非注解配置因为list为空（详细看上文），所以没有执行后面的逻辑。
继续看非注解扫描工具处理。
public static void scanData2Store(String fileName) {
// 组装仓库对象，和注解文件的不同在于，文件注解本身就是一个对象，非注解配置是一个配置文件，需要转换为对象。
// 组装的过程，存在disconfCenterFile.setIsTaggedWithNonAnnotationFile(true);设置。
// 在第一次扫描的时候，有提到，如果是非注解的，该属性会覆盖之前注解的仓库对象
DisconfCenterBaseModel disconfCenterBaseModel =
StaticScannerNonAnnotationFileMgrImpl.getDisconfCenterFile(fileName);
// 因为非注解配置肯定文件，所以调用文件仓库处理器，后面的逻辑参考上文 DisconfStoreProcessorFactory.getDisconfStoreFileProcessor().transformScanData(disconfCenterBaseModel);
}
扫描完成以后，开始核心处理器处理。
/**
* 只处理某一个
*/
@Override
public void processFile(String fileName) {
// 获取配置文件核心处理器，原理和上文一样
DisconfCoreProcessor disconfCoreProcessorFile =
DisconfCoreProcessorFactory.getDisconfCoreProcessorFile(watchMgr, fetcherMgr, registry);
// 在第一次扫描的时候会调用processAllItems()处理，但是xml配置的扫描肯定是单个的，所以直接调用单个处理
disconfCoreProcessorFile.processOneItem(fileName);
}
再后面的处理和第一次扫描的处理是同一个方法，一個配置文件, 下载、注入到仓库、Watch 三步骤。
继续XML配置解析，对于properties类型的文件，Spring的PropertyPlaceholderConfigurer类支持处理，所以最后将properties类型的文件设置到父类的locations属性中。setLocations()结束。
因为ReloadablePropertiesFactoryBean继承自PropertiesFactoryBean，PropertiesFactoryBean实现了InitializingBean接口，所以在初始化的时候，会调用afterPropertiesSet()方法。
public final void afterPropertiesSet() throws IOException {
if(this.singleton) {
this.singletonInstance = this.createProperties();
}
}
protected Properties createProperties() throws IOException {
return this.mergeProperties();
}
而ReloadablePropertiesFactoryBean重载了createProperties()方法。
@Override
protected Properties createProperties() throws IOException {
return (Properties) createMyInstance();
}
/**
* @throws IOException
*/
protected Object createMyInstance() throws IOException {
// would like to uninherit from AbstractFactoryBean (but it's final!)
if (!isSingleton()) {
throw new RuntimeException("ReloadablePropertiesFactoryBean only works as singleton");
}
// set listener
reloadableProperties = new ReloadablePropertiesImpl();
if (preListeners != null) {
reloadableProperties.setListeners(preListeners);
}
// reload
reload(true);
// add for monitor
ReloadConfigurationMonitor.addReconfigurableBean((ReconfigurableBean) reloadableProperties);
return reloadableProperties;
}
首先看ReloadablePropertiesImpl的实现，他继承自ReloadablePropertiesBase，包含了List<IReloadablePropertiesListener> listeners监听列表。开始preListeners默认为null，直接执行reload(true)，默认情况下reload方法通过判断配置文件的修改时间来确认是否重新加载，这里因为传参为true，所以强制reload()。调用ReloadablePropertiesBase的setProperties()。
/**
* 通过listener去通知 reload
*
* @param oldProperties
*/
protected void notifyPropertiesChanged(Properties oldProperties) {
PropertiesReloadedEvent event = new PropertiesReloadedEvent(this, oldProperties);
for (IReloadablePropertiesListener listener : listeners) {
listener.propertiesReloaded(event);
}
}
/**
* set value 触发
*
* @param properties
*/
protected void setProperties(Properties properties) {
Properties oldProperties = internalProperties;
synchronized(this) {
internalProperties = properties;
}
notifyPropertiesChanged(oldProperties);
}
可以看到最后会遍历前面所说的listeners列表，如果有值的情况会调用listener的propertiesReloaded()方法去reload。IReloadablePropertiesListener接口的实现类是ReloadingPropertyPlaceholderConfigurer。
有了ReloadablePropertiesFactoryBean以后，Disconf支持两种非注解式处理，分别的Spring自带的PropertyPlaceholderConfigurer和ReloadingPropertyPlaceholderConfigurer。两者的区别是会不会自动reload。结合上面所说，如果想要自动reload，就是通过listeners列表实现。如果使用Spring自带的PropertyPlaceholderConfigurer，那么自然就不会有listener。
当我们使用ReloadingPropertyPlaceholderConfigurer的作为XML配置时，因为实现了InitializingBean接口，所以会执行afterPropertiesSet()。
/**
* afterPropertiesSet
* 将自己 添加 property listener
*/
public void afterPropertiesSet() {
for (Properties properties : propertiesArray) {
if (properties instanceof ReloadableProperties) {
logger.debug("add property listener: " + properties.toString());
// addReloadablePropertiesListener执行了listeners.add()。
((ReloadableProperties) properties).addReloadablePropertiesListener(this);
}
}
}
在加载ReloadablePropertiesFactoryBean的时候，我们已经把所有的properties格式的文件放入到propertiesArray，所以都会加入到listener中，最后会调用propertiesReloaded()进行处理。
至此，Disconf的启动过程分析结束。
转载请注明出处。
作者：wuxiwei
出处：https://www.cnblogs.com/wxw16/p/10741202.html
