应用配置管理,基础原理分析

应用配置管理,基础原理分析,第1张

工程可以有点小乱,但配置不能含糊;

一、配置架构

在微服务的代码工程中,配置管理是一项复杂的事情,即需要做好各个环境的配置隔离措施,还需要确保生产环境的配置安全;如果划分的微服务足够的多,还要考虑配置更新时的效率;

应用配置管理,基础原理分析,第3张

常规情况下,在配置管理的体系中,分为四个主要的环境:开发、测试、灰度、生产;通常来说除了运维团队之外,其他人员没有查看灰度和生产配置的权限,以此来保证配置的安全性;配置中心的服务也会搭建两套:研发与生产各自独立部署。

二、配置方式

在项目中涉及到的配置非常多,类型也很多,但是从大的结构上可以分为:工程级、应用级、组件级三大块;实际上这里只是单纯的从代码工程来看配置,如果把持续集成、自动化相关模块也考虑进来的话,配置的管理会更加复杂;

应用配置管理,基础原理分析,第4张

站在开发的角度来看,主要还是对应用级的配置进行管理,而在微服务的架构下,多个不同的服务既有大量相同的配置,又存在各种差异化的自定义参数,所以在维护上有一定的复杂性;

应用配置管理,基础原理分析,第5张

在单服务的工程中,应用中只会存在一个bootstrap.yml配置文件,配置内容基本就是服务名称,和配置中心地址等常规内容,其他复杂的配置都被封闭维护,避免核心内容泄露引发安全问题;

应用配置管理,基础原理分析,第6张

配置主体通常会被拆分成如下几个层次:环境控制,用来识别灰度和生产;应用基础,管理和加载各个服务的通用配置;服务差异则配置在各自独立的文件内;并且对多个配置进行分类分层管理;以此保证配置的安全和降低维护难度。

三、Nacos配置

首先还是从bootstrap.yml文件作为切入点,以当下常见的Nacos组件为例,围绕基础原理作为思路,来分析服务工程是如何加载Nacos配置中心的参数;

spring:
  profiles:
    active: dev,facade
  cloud:
    nacos:
      config:
        prefix: application
        server-addr: 127.0.0.1:8848
        file-extension: yml

应用配置管理,基础原理分析,第7张

组件配置:配置逻辑中,单个服务端提供自身配置参数的信息,从上篇服务管理的源码中发现,这是一种很常用的手段;需要基于这些信息去Nacos服务中加载配置;

@ConfigurationProperties("spring.cloud.nacos.config")
public class NacosConfigProperties {
    public Properties assembleConfigServiceProperties() {
        Properties properties = new Properties();
        properties.put("serverAddr", Objects.toString(this.serverAddr, ""));
        properties.put("namespace", Objects.toString(this.namespace, ""));
        return properties ;
    }
}

加载逻辑:服务启动时,先基于相应参数读取Nacos中配置的,然后解析数据并被Spring框架进行加载,加载的过程通过MapPropertySource类进行Key和Value的读取;

public class NacosPropertySourceBuilder {
    private List<PropertySource<?>> loadNacosData(String dataId, String group, String fileExtension) {
        // 查询配置
        String data = this.configService.getConfig(dataId, group, this.timeout);
        // 解析配置
        return NacosDataParserHandler.getInstance().parseNacosData(dataId, data, fileExtension);
    }
}

请求服务:服务端与Nacos中心通过Http请求的方式进行交互,通过Get请求携带参数,调用Nacos中心服务,从而获取相应配置;

public class ClientWorker implements Closeable {
    public String[] getServerConfig(String dataId, String group, String tenant, long readTimeout) {
        // 核心参数
        Map<String, String> params = new HashMap<String, String>(3);
        params.put("dataId", dataId);
        params.put("group", group);
        params.put("tenant", tenant);
        // 执行请求
        HttpRestResult<String> result = agent.httpGet(Constants.CONFIG_CONTROLLER_PATH, null, params, agent.getEncode(), readTimeout);
    }
}

四、Spring加载

从源码的结构图来看,配置文件的加载逻辑也是采用事件模型实现的,这在前面任务管理中有详细的描述;配置的核心作用就是在程序启动时进行加载引导,这里关键要理解EnvironmentPostProcessor的接口设计;

应用配置管理,基础原理分析,第8张

public class ConfigFileApplicationListener implements EnvironmentPostProcessor, SmartApplicationListener, Ordered {
    // 基础配置
    private static final String DEFAULT_NAMES = "application";
    public static final String ACTIVE_PROFILES_PROPERTY = "spring.profiles.active";
    public static final String INCLUDE_PROFILES_PROPERTY = "spring.profiles.include";
    static {
	    Set<String> filteredProperties = new HashSet<>();
	    filteredProperties.add("spring.profiles.active");
	    filteredProperties.add("spring.profiles.include");
	    LOAD_FILTERED_PROPERTY = Collections.unmodifiableSet(filteredProperties);
    }
    // 加载逻辑
    void load() {
	FilteredPropertySource.apply(this.environment, DEFAULT_PROPERTIES, LOAD_FILTERED_PROPERTY,
			(defaultProperties) -> {
			});
    }
}

EnvironmentPostProcessor接口:加载应用的自定义环境;

@FunctionalInterface
public interface EnvironmentPostProcessor {
	void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application);
}

SpringApplication:用于启动和引导应用程序,提供创建程序上下文实例,初始化监听器,容器刷新等核心逻辑,可以围绕run()方法进行调试分析;

ConfigurableEnvironment:环境配置的核心接口,涉及到当前配置文件识别,即profiles.active;以及配置文件的解析能力,即PropertyResolver;在Loader内部类中提供了构造方法和加载逻辑的实现。

五、参考源码

应用仓库:
https://gitee.com/cicadasmile/butte-flyer-parent

组件封装:
https://gitee.com/cicadasmile/butte-frame-parent

文章来源:https://www.cnblogs.com/cicada-smile/p/16395449.html

本文经用户投稿或网站收集转载,如有侵权请联系本站。

发表评论

0条回复