莫那-鲁道 阅读(23) 评论(0)

目录:

  1. 前言
  2. 处理方案
  3. 简单例子

前言

有的时候,你可能需要在 Spring 环境中放入一些配置,但这些配置无法写死在配置文件中,只能运行时放入。那么,这个时候该怎么办呢?

Apollo 就是搞配置的,那么自然会遇到这个问题,他是如何处理的呢?

处理方案

首先要知道 Spring 环境中,一个配置的数据结构是什么?

是抽象类 PropertySource<T>, 内部是个 key value 结构。这个 T 可以是任意类型,取决于子类的设计。

子类可以通过重写 getProperty 抽象方法获取配置。

Spring 自身的 org.springframework.core.env.MapPropertySource 就重写了这个方法。

public class MapPropertySource extends EnumerablePropertySource<Map<String, Object>> {

    public MapPropertySource(String name, Map<String, Object> source) {
        super(name, source);
    }


    @Override
    public Object getProperty(String name) {
        return this.source.get(name);
    }

    @Override
    public boolean containsProperty(String name) {
        return this.source.containsKey(name);
    }

    @Override
    public String[] getPropertyNames() {
        return StringUtils.toStringArray(this.source.keySet());
    }
}

可以看到,他的泛型是 Map,getProperty 方法则是从 Map 中获取。

Apollo 就直接利用了这个类。

两个不同的子类,不同的刷新逻辑。我们暂时不关心他们的不同。

这两个类都会被 RefreshableConfig 组合,添加到 Spring 的环境中。

import org.springframework.core.env.ConfigurableEnvironment;

public abstract class RefreshableConfig {

  @Autowired
  private ConfigurableEnvironment environment; // Spring 环境

  @PostConstruct
  public void setup() {
  // 省略代码
    for (RefreshablePropertySource propertySource : propertySources) {
      propertySource.refresh();
      // 注意:成功刷新后,放到 Spring 的环境中
      environment.getPropertySources().addLast(propertySource);
    }
  // 省略代码

当从 Spring 的环境中获取配置的时候,具体代码是下面这样的:

protected <T> T getProperty(String key, Class<T> targetValueType, boolean resolveNestedPlaceholders) {
        for (PropertySource<?> propertySource : this.propertySources) {
            // 注意:这里调用的就是 propertySource.getProperty 方法,子类刚刚重写的方法
            Object value = propertySource.getProperty(key);
             // 省略无关代码........
            return convertValueIfNecessary(value, targetValueType);
        }
        return null;
}

Spring 维护了一个 PropertySource 的集合,这个结合是有顺序的,也就是说,排在最前面的优先级最高(遍历从下标 0 开始)。

而用户可以在 PropertySource 里,维护一个配置字典(Map),这样,就类似 2 维数组的这样一个数据结构。

所以,配置是可以重名的,重名时,以最前面的 PropertySource 中的配置为准。所以,Spring 留给了几个 API:

  1. addFirst(PropertySource<?> propertySource)
  2. addLast(PropertySource<?> propertySource)
  3. addBefore(String relativePropertySourceName, PropertySource<?> propertySource)
  4. addAfter(String relativePropertySourceName, PropertySource<?> propertySource)

从名字可以看出,通过这些 API,我们可以将 propertySource 插入到我们指定的地方。从而可以手动控制配置的优先级。

Spring 中有个现成的 CompositePropertySource 类,内部聚合了一个 PropertySource Set 集合,当 getProperty(String name) 的时候,就会遍历这个集合,然后调用这个 propertySource 的 getProperty(name) 方法。相当于 3 维数组。

大概的设计是这样:

一个环境中,有多个 PS(PropertySource 简称),每个 PS 可以直接包含配置,也可以再包装一层 PS。

简单例子

我们这里有个简单的例子,需求:
程序里有个配置,但不能写死在配置文件中,只能在程序启动过程中进行配置,然后注入到 Spring 环境中,让 Spring 在之后的 IOC 中,可以正常的使用这些配置。

代码如下:

@SpringBootApplication
public class DemoApplication {

  @Value("${timeout:1}")
  String timeout;


  public static void main(String[] args) throws InterruptedException {
    ApplicationContext c = SpringApplication.run(DemoApplication.class, args);
    for (; ; ) {
      Thread.sleep(1000);
      System.out.println(c.getBean(DemoApplication.class).timeout);
    }
  }
}

application.properties 配置文件

timeout=100

上面的代码中,我们在 bean 中定义了一个属性 timeout, 并在本地配置文件中写入了一个 100 的值,也在表达式中给了一个默认值 1。

那么现在打印出来的就是配置文件中的值:100.

但是,这不是我们想要的结果,所以需要修改代码。

我们加入一个类:

@Component
class Test implements EnvironmentAware, BeanFactoryPostProcessor {

  @Override
  public void setEnvironment(Environment environment) {
    ((ConfigurableEnvironment) environment).getPropertySources()
        // 这里是 addFirst,优先级高于 application.properties 配置
        .addFirst(new PropertySource<String>("timeoutConfig", "12345") {
          // 重点
          @Override
          public Object getProperty(String s) {
            if (s.equals("timeout")) {//
              return source;// 返回构造方法中的 source :12345
            }
            return null;
          }
        });
  }

  @Override
  public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
      throws BeansException {
    // NOP
  }
}

运行之后,结果:12345

2018-07-02 15:26:54.315  INFO 43393 --- [           main] o.s.j.e.a.AnnotationMBeanExporter        : Registering beans for JMX exposure on startup
2018-07-02 15:26:54.327  INFO 43393 --- [           main] com.example.demo.DemoApplication         : Started DemoApplication in 0.991 seconds (JVM running for 1.49)
12345
12345

为什么加入了这个类,就能够代替配置文件中的属性呢?解释一下这个类的作用。

我们要做的事情就是在 Spring 的环境中,插入自定义的 PS 对象,以便容器获取的时候,能够通过 getProperty 方法获取对应的配置。

所以,我们要拿到 Spring 环境对象,还需要创建一个 PS 对象,并重写 getProperty 方法,同时,注意:自己的 PS 配置优先级需要高于容器配置文件的优先级,保险起见,放在第一位。

PS 构造方法的第一个参数没什么用,就是一个标识符,第二个参数就是 source,可以定义为任何类型,String,Map,都可以,我们这里简单期间,就是一个 String,直接返回这个值,如果是 Map,就调用 Map 的 get 方法。

为什么要实现 BeanFactoryPostProcessor 接口呢? 实现 BeanFactoryPostProcessor 接口的目的是让该 Bean 的加载时机提前,高于目标 Bean 的初始化。否则,目标 Bean 中的 timeout 属性都注入结束了,后面的操作就没有意义了。

总结

说白了,就是不想写配置文件!!!

而且也不想改老项目的代码,老项目即使在删除配置文件的情况下,依然能够使用配置中心!

这就需要熟悉 Spring 的配置加载逻辑和属性获取逻辑。

现在,我们知道,只需要拿到 Spirng 的环境对象,并向环境中添加自定义的 PS 对象,重写 PS 的 getProperty 方法,即可获取配置(注意优先级)。

还需要注意加载这个配置的 bean 的优先级也要很高,通常实现 BeanFactoryPostProcessor 接口就足够了,如果还不够,就需要做一些特殊操作。