5

应用配置管理，基础原理分析_知了一笑的技术博客_51CTO博客

 2 years ago
source link: https://blog.51cto.com/u_14439672/5398360
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

工程可以有点小乱，但配置不能含糊；

一、配置架构

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

应用配置管理，基础原理分析_微服务

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

二、配置方式

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

应用配置管理，基础原理分析_配置中心_02

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

应用配置管理，基础原理分析_微服务_03

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

应用配置管理，基础原理分析_配置中心_04

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

三、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
应用配置管理，基础原理分析_微服务_05

组件配置：配置逻辑中，单个服务端提供自身配置参数的信息，从上篇服务管理的源码中发现，这是一种很常用的手段；需要基于这些信息去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的接口设计；

应用配置管理，基础原理分析_配置中心_06
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

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK