Spring Cloud 中自定义外部化扩展机制原理及实战记录

目录
  • 自定义PropertySource
  • 扩展PropertySourceLocator
  • Spring.factories
  • 编写controller测试
  • 阶段性总结
  • SpringApplication.run
  • PropertySourceBootstrapConfiguration.initialize
  • ApplicationContextInitializer的理解和使用
    • 创建一个TestApplicationContextInitializer
    • 添加spi加载

Spring Cloud针对Environment的属性源功能做了增强,

在spring-cloud-contenxt这个包中,提供了PropertySourceLocator接口,用来实现属性文件加载的扩展。我们可以通过这个接口来扩展自己的外部化配置加载。这个接口的定义如下

public interface PropertySourceLocator {

   /**
    * @param environment The current Environment.
    * @return A PropertySource, or null if there is none.
    * @throws IllegalStateException if there is a fail-fast condition.
    */
   PropertySource<?> locate(Environment environment);
}

locate这个抽象方法,需要返回一个PropertySource对象。

这个PropertySource就是Environment中存储的属性源。 也就是说,我们如果要实现自定义外部化配置加载,只需要实现这个接口并返回PropertySource即可。

按照这个思路,我们按照下面几个步骤来实现外部化配置的自定义加载。

自定义PropertySource

既然PropertySourceLocator需要返回一个PropertySource,那我们必须要定义一个自己的PropertySource,来从外部获取配置来源。

GpDefineMapPropertySource 表示一个以Map结果作为属性来源的类。

public class GpDefineMapPropertySource extends MapPropertySource {
    /**
     * Create a new {@code MapPropertySource} with the given name and {@code Map}.
     *
     * @param name   the associated name
     * @param source the Map source (without {@code null} values in order to get
     *               consistent {@link #getProperty} and {@link #containsProperty} behavior)
     */
    public GpDefineMapPropertySource(String name, Map<String, Object> source) {
        super(name, source);
    }

    @Override
    public Object getProperty(String name) {
        return super.getProperty(name);
    public String[] getPropertyNames() {
        return super.getPropertyNames();
}

扩展PropertySourceLocator

扩展PropertySourceLocator,重写locate提供属性源。

而属性源是从gupao.json文件加载保存到自定义属性源GpDefineMapPropertySource中。

public class GpJsonPropertySourceLocator implements PropertySourceLocator {

    //json数据来源
    private final static String DEFAULT_LOCATION="classpath:gupao.json";
    //资源加载器
    private final ResourceLoader resourceLoader=new DefaultResourceLoader(getClass().getClassLoader());
    @Override
    public PropertySource<?> locate(Environment environment) {
        //设置属性来源
        GpDefineMapPropertySource jsonPropertySource=new GpDefineMapPropertySource
                ("gpJsonConfig",mapPropertySource());
        return jsonPropertySource;
    }
    private Map<String,Object> mapPropertySource(){
        Resource resource=this.resourceLoader.getResource(DEFAULT_LOCATION);
        if(resource==null){
            return null;
        }
        Map<String,Object> result=new HashMap<>();
        JsonParser parser= JsonParserFactory.getJsonParser();
        Map<String,Object> fileMap=parser.parseMap(readFile(resource));
        processNestMap("",result,fileMap);
        return result;
    //加载文件并解析
    private String readFile(Resource resource){
        FileInputStream fileInputStream=null;
        try {
            fileInputStream=new FileInputStream(resource.getFile());
            byte[] readByte=new byte[(int)resource.getFile().length()];
            fileInputStream.read(readByte);
            return new String(readByte,"UTF-8");
        } catch (IOException e) {
            e.printStackTrace();
        }finally {
            if(fileInputStream!=null){
                try {
                    fileInputStream.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        return null;
	//解析完整的url保存到result集合。 为了实现@Value注入
    private void processNestMap(String prefix,Map<String,Object> result,Map<String,Object> fileMap){
        if(prefix.length()>0){
            prefix+=".";
        for (Map.Entry<String, Object> entrySet : fileMap.entrySet()) {
            if (entrySet.getValue() instanceof Map) {
                processNestMap(prefix + entrySet.getKey(), result, (Map<String, Object>) entrySet.getValue());
            } else {
                result.put(prefix + entrySet.getKey(), entrySet.getValue());
}

Spring.factories

/META-INF/spring.factories文件中,添加下面的spi扩展,让Spring Cloud启动时扫描到这个扩展从而实现GpJsonPropertySourceLocator的加载。

org.springframework.cloud.bootstrap.BootstrapConfiguration=\
  com.gupaoedu.env.GpJsonPropertySourceLocator

编写controller测试

@RestController
public class ConfigController {
    @Value("${custom.property.message}")
    private String name;

    @GetMapping("/")
    public String get(){
        String msg=String.format("配置值:%s",name);
        return msg;
    }
}

阶段性总结

通过上述案例可以发现,基于Spring Boot提供的PropertySourceLocator扩展机制,可以轻松实现自定义配置源的扩展。

于是,引出了两个问题。

  • PropertySourceLocator是在哪个被触发的?
  • 既然能够从gupao.json中加载数据源,是否能从远程服务器上加载呢?

PropertySourceLocator加载原理

先来探索第一个问题,PropertySourceLocator的执行流程。

SpringApplication.run

在spring boot项目启动时,有一个prepareContext的方法,它会回调所有实现了ApplicationContextInitializer的实例,来做一些初始化工作。

ApplicationContextInitializer是Spring框架原有的东西, 它的主要作用就是在,ConfigurableApplicationContext类型(或者子类型)的ApplicationContext做refresh之前,允许我们对ConfiurableApplicationContext的实例做进一步的设置和处理。

它可以用在需要对应用程序上下文进行编程初始化的web应用程序中,比如根据上下文环境来注册propertySource,或者配置文件。而Config 的这个配置中心的需求恰好需要这样一个机制来完成。

public ConfigurableApplicationContext run(String... args) {
   //省略代码...
        prepareContext(context, environment, listeners, applicationArguments, printedBanner);
   //省略代码
    return context;
}

PropertySourceBootstrapConfiguration.initialize

其中,PropertySourceBootstrapConfiguration就实现了ApplicationContextInitializerinitialize方法代码如下。

@Override
public void initialize(ConfigurableApplicationContext applicationContext) {
    List<PropertySource<?>> composite = new ArrayList<>();
    //对propertySourceLocators数组进行排序,根据默认的AnnotationAwareOrderComparator
    AnnotationAwareOrderComparator.sort(this.propertySourceLocators);
    boolean empty = true;
    //获取运行的环境上下文
    ConfigurableEnvironment environment = applicationContext.getEnvironment();
    for (PropertySourceLocator locator : this.propertySourceLocators) {
        //回调所有实现PropertySourceLocator接口实例的locate方法,并收集到source这个集合中。
        Collection<PropertySource<?>> source = locator.locateCollection(environment);
        if (source == null || source.size() == 0) { //如果source为空,直接进入下一次循环
            continue;
        }
        //遍历source,把PropertySource包装成BootstrapPropertySource加入到sourceList中。
        List<PropertySource<?>> sourceList = new ArrayList<>();
        for (PropertySource<?> p : source) {
            sourceList.add(new BootstrapPropertySource<>(p));
        }
        logger.info("Located property source: " + sourceList);
        composite.addAll(sourceList);//将source添加到数组
        empty = false; //表示propertysource不为空
    }
     //只有propertysource不为空的情况,才会设置到environment中
    if (!empty) {
        //获取当前Environment中的所有PropertySources.
        MutablePropertySources propertySources = environment.getPropertySources();
        String logConfig = environment.resolvePlaceholders("${logging.config:}");
        LogFile logFile = LogFile.get(environment);
       // 遍历移除bootstrapProperty的相关属性
        for (PropertySource<?> p : environment.getPropertySources()) {

            if (p.getName().startsWith(BOOTSTRAP_PROPERTY_SOURCE_NAME)) {
                propertySources.remove(p.getName());
            }
        }
        //把前面获取到的PropertySource,插入到Environment中的PropertySources中。
        insertPropertySources(propertySources, composite);
        reinitializeLoggingSystem(environment, logConfig, logFile);
        setLogLevels(applicationContext, environment);
        handleIncludedProfiles(environment);
    }
}

上述代码逻辑说明如下。

1.首先this.propertySourceLocators,表示所有实现了PropertySourceLocators接口的实现类,其中就包括我们前面自定义的GpJsonPropertySourceLocator

2.根据默认的 AnnotationAwareOrderComparator 排序规则对propertySourceLocators数组进行排序。

3.获取运行的环境上下文ConfigurableEnvironment

4.遍历propertySourceLocators时

  • 调用 locate 方法,传入获取的上下文environment
  • 将source添加到PropertySource的链表中
  • 设置source是否为空的标识标量empty

5.source不为空的情况,才会设置到environment中返回Environment的可变形式,可进行的操作如addFirst、addLast移除propertySources中的bootstrapProperties根据config server覆写的规则,设置propertySources处理多个active profiles的配置信息

  • 返回Environment的可变形式,可进行的操作如addFirst、addLast
  • 移除propertySources中的bootstrapProperties
  • 根据config server覆写的规则,设置propertySources
  • 处理多个active profiles的配置信息

注意:this.propertySourceLocators这个集合中的PropertySourceLocator,是通过自动装配机制完成注入的,具体的实现在BootstrapImportSelector这个类中。

ApplicationContextInitializer的理解和使用

ApplicationContextInitializer是Spring框架原有的东西, 它的主要作用就是在,ConfigurableApplicationContext类型(或者子类型)的ApplicationContext做refresh之前,允许我们对ConfiurableApplicationContext的实例做进一步的设置和处理。

它可以用在需要对应用程序上下文进行编程初始化的web应用程序中,比如根据上下文环境来注册propertySource,或者配置文件。而Config 的这个配置中心的需求恰好需要这样一个机制来完成。

创建一个TestApplicationContextInitializer

public class TestApplicationContextInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext>{
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        ConfigurableEnvironment ce=applicationContext.getEnvironment();
        for(PropertySource<?> propertySource:ce.getPropertySources()){
            System.out.println(propertySource);
        }
        System.out.println("--------end");
    }
}

添加spi加载

创建一个文件/resources/META-INF/spring.factories。添加如下内容

org.springframework.context.ApplicationContextInitializer= \
  com.gupaoedu.example.springcloudconfigserver9091.TestApplicationContextInitializer

在控制台就可以看到当前的PropertySource的输出结果。

ConfigurationPropertySourcesPropertySource {name='configurationProperties'}
StubPropertySource {name='servletConfigInitParams'}
StubPropertySource {name='servletContextInitParams'}
PropertiesPropertySource {name='systemProperties'}
OriginAwareSystemEnvironmentPropertySource {name='systemEnvironment'}
RandomValuePropertySource {name='random'}
MapPropertySource {name='configServerClient'}
MapPropertySource {name='springCloudClientHostInfo'}
OriginTrackedMapPropertySource {name='applicationConfig: [classpath:/application.yml]'}
MapPropertySource {name='kafkaBinderDefaultProperties'}
MapPropertySource {name='defaultProperties'}
MapPropertySource {name='springCloudDefaultProperties'}

到此这篇关于Spring Cloud 中自定义外部化扩展机制原理及实战的文章就介绍到这了,更多相关Spring Cloud 扩展机制原理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详解Spring Cloud Gateway 数据库存储路由信息的扩展方案

    动态路由背景 ​ 无论你在使用Zuul还是Spring Cloud Gateway 的时候,官方文档提供的方案总是基于配置文件配置的方式 例如: # zuul 的配置形式 routes: pig-auth: path: /auth/** serviceId: pig-auth stripPrefix: true # gateway 的配置形式 routes: - id: pigx-auth uri: lb://pigx-auth predicates: - Path=/auth/** filte

  • Spring Cloud 中自定义外部化扩展机制原理及实战记录

    目录 自定义PropertySource 扩展PropertySourceLocator Spring.factories 编写controller测试 阶段性总结 SpringApplication.run PropertySourceBootstrapConfiguration.initialize ApplicationContextInitializer的理解和使用 创建一个TestApplicationContextInitializer 添加spi加载 Spring Cloud针对E

  • spring cloud中微服务之间的调用以及eureka的自我保护机制详解

    上篇讲了spring cloud注册中心及客户端的注册,所以这篇主要讲一下服务和服务之间是怎样调用的 不会搭建的小伙伴请参考我上一篇博客:idea快速搭建spring cloud-注册中心与注册 基于上一篇的搭建我又自己搭建了一个客户端微服务: 所以现在有两个微服务,我们所实现的就是微服务1和微服务2之间的调用 注册中心就不用多说了,具体看一下两个微服务 application.yml配置也不用说了,不知道怎么配置的请参考我上篇博客 在project-solr中的constroller中: @R

  • 浅谈Spring Cloud中的API网关服务Zuul

    到目前为止,我们Spring Cloud中的内容已经介绍了很多了,Ribbon.Hystrix.Feign这些知识点大家都耳熟能详了,我们在前文也提到过微服务就是把一个大的项目拆分成很多小的独立模块,然后通过服务治理让这些独立的模块配合工作等.那么大家来想这样两个问题:1.如果我的微服务中有很多个独立服务都要对外提供服务,那么对于开发人员或者运维人员来说,他要如何去管理这些接口?特别是当项目非常大非常庞杂的情况下要如何管理?2.权限管理也是一个老生常谈的问题,在微服务中,一个独立的系统被拆分成很

  • Spring Cloud Feign 自定义配置(重试、拦截与错误码处理) 代码实践

    基于 spring-boot-starter-parent 2.1.9.RELEASE, spring-cloud-openfeign 2.1.3.RELEASE 引子 Feign 是一个声明式.模板化的HTTP客户端,简化了系统发起Http请求.创建它时,只需要创建一个接口,然后加上FeignClient注解,使用它时,就像调用本地方法一样,作为开发者的我们完全感知不到这是在调用远程的方法,也感知不到背后发起了HTTP请求: /** * @author axin * @suammry xx 客

  • Spring Cloud中使用Feign,@RequestBody无法继承的解决方案

    目录 Spring Cloud中使用Feign,@RequestBody无法继承的问题 原因分析 解决方案 spring cloud 使用feign遇到的问题 1.示例 2.首次访问超时问题 3.FeignClient接口中,如果使用到@PathVariable,必须指定其value Spring Cloud中使用Feign,@RequestBody无法继承的问题 根据官网FeignClient的例子,编写一个简单的updateUser接口,定义如下 @RequestMapping("/user

  • SpringBoot扩展外部化配置的原理解析

    Environment实现原理 在基于SpringBoot开发的应用中,我们常常会在application.properties.application-xxx.properties.application.yml.application-xxx.yml等配置文件中设置一些属性值,然后通过@Value.@ConfigurationProperties等注解获取,或者采用编码的方式通过Environment获取. # application.properties my.config.appId=d

  • 一文吃透Spring Cloud gateway自定义错误处理Handler

    目录 正文 AbstractErrorWebExceptionHandler isDisconnectedClientError方法 isDisconnectedClientErrorMessage方法: 小结 NestedExceptionUtils getRoutingFunction logError write 其他的方法 afterPropertiesSet renderDefaultErrorView renderErrorView DefaultErrorWebExceptionH

  • 解决Spring Cloud中Feign/Ribbon第一次请求失败的方法

    前言 在Spring Cloud中,Feign和Ribbon在整合了Hystrix后,可能会出现首次调用失败的问题,要如何解决该问题呢? 造成该问题的原因 Hystrix默认的超时时间是1秒,如果超过这个时间尚未响应,将会进入fallback代码.而首次请求往往会比较慢(因为Spring的懒加载机制,要实例化一些类),这个响应时间可能就大于1秒了.知道原因后,我们来总结一下解决放你. 解决方案有三种,以feign为例. 方法一 hystrix.command.default.execution.

  • Spring Cloud中关于Feign的常见问题总结

    一.FeignClient接口,不能使用@GettingMapping 之类的组合注解 代码示例: @FeignClient("microservice-provider-user") public interface UserFeignClient { @RequestMapping(value = "/simple/{id}", method = RequestMethod.GET) public User findById(@PathVariable(&quo

  • Spring Cloud zuul自定义统一异常处理实现方法

    Zuul在springcloud微服务体系中提供filer和router功能,是微服务不可或缺的部分.filer处理默认实现的外还可以自定义进行授权.限流.安全校验等,router完全可以替代Nginx反向代理.Zuul异常处理就是由SendErrorFilter完成. 在我们应用过程我们发现使用默认的异常filter有两个问题不是很友好: 1.无法快速识别出是否是请求路由的服务超时还是没有任何可用节点,发生错误只能查看日志通过堆栈去定位: 2.无法兼容自定义的譬如{code:500,msg:"

随机推荐