一、配置架构

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

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

　　二、配置方式

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

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

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

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

　　三、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

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

　　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内部类中提供了构造方法和加载逻辑的实现。

作者：知了一笑    

来源：http://www.51testing.com/html/52/n-7796552.html