分布式配置中心disconf第三部(基于xml配置的实现原理)

2019独角兽企业重金招聘Python工程师标准>>>

基于配置与基于注入实现方式，区别还是比较大的,为了便于理解，我们先了解一下大家常见的场景，通过spring配置properties文件，达到使用@Value注解获取参数配置的原理：

• 传统的spring参数注解实现原理
  首先需要定一个叫做PropertyPlaceholderConfigurer的bean,定义如下

  <bean id="appProperty"
      class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
      <property name="locations">
          <array>
              <value>classpath:app.properties</value>
          </array>
      </property>
  </bean>

  结合类图的集成结构看下：
  
  1、PlaceholderConfigurerSupport---提供基础的操作，如properties的load、merge，实现流转换成为property对象
  2、PropertyResourceConfigurer--因为这个类集成了BeanFactoryPostProcessor，所以容器加载阶段，执行postProcessBeanFactory方法，调用子类也就是PlaceholderConfigureSupport的doProcessProperties方法，完成properties装载，bean中的$value替换
  3、PlaceholderConfigureSupport---执行具体的替换动作，兼容spring版本差异带来的配置替换不同
  4、PropertyPlaceholderConfigurer---通过processProperties方法提供替换的具体实现

• disconf配置实现原理：
  ReloadablePropertiesFactoryBean，做了哪些事情
  1、文件远程下载，存储至内存
  2、把下载至本地的文件，提供给父类，保证PlaceholderConfigurerSupport能够load到数据
  ReloadingPropertyPlaceholderConfigurer,做了哪些事情
  1、当远程数据变化，需要调用该接口的propertiesReloaded方法，做bean的重新赋值，这里使用的是注册监听事件的方式
  2、系统正常启动时，提供了一个bean属性替换的功能也就是processProperties，这里重写了PropertyPlaceholderConfigurer的processProperties实现，为什么要重写，因为我们实现了disconf所特有的解析和替换逻辑！

转载于:https://my.oschina.net/13426421702/blog/3050281