Application configuration management, basic principle analysis

The project can be a little messy, but the configuration cannot be ambiguous;

1. Configuration Architecture

In the code engineering of microservices, configuration management is a complicated matter, that is, it is necessary to do a good job of configuration isolation measures for each environment, and to ensure the configuration security of the production environment; if there are enough divided microservices, the configuration should also be considered Efficiency when updating;

Under normal circumstances, in the configuration management system, it is divided into four main environments: development, testing, grayscale, and production; generally speaking, except for the operation and maintenance team, other personnel do not have the authority to view grayscale and production configurations. In this way, the security of configuration is guaranteed; two sets of services in the configuration center will be built: R&D and production are independently deployed.

2. Configuration method

There are many configurations and types involved in the project, but from the large structure, they can be divided into three major blocks: engineering level, application level, and component level; If the continuous integration and automation related modules are also taken into account, the configuration management will be more complicated;

From the perspective of development, the main thing is to manage the configuration at the application level. Under the microservice architecture, many different services have a large number of the same configuration, and there are various differentiated custom parameters, so There is a certain complexity in maintenance;

In a single-service project, there is only one bootstrap.yml configuration file in the application. The configuration content is basically the service name, and the configuration center address and other conventional content. Other complex configurations are closed and maintained to avoid core content. Leaks cause security issues;

The configuration body is usually divided into the following levels: environment control, which is used to identify grayscale and production; application base, which manages and loads the general configuration of each service; service differences are configured in separate files; and to many Each configuration is classified and managed in layers; in this way, the security of the configuration is guaranteed and the maintenance difficulty is reduced.

3. Nacos configuration

First of all, from the bootstrap.yml file as the entry point, taking the common Nacos components as an example, focusing on the basic principle as the idea, to analyze how the service project loads the parameters of the Nacos configuration center;

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

Component configuration : In the configuration logic, a single server provides information about its own configuration parameters. It is found from the source code of the service management in the previous article. This is a very common method; it is necessary to load the configuration in the Nacos service based on this information;

 @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 ;
    }
}

Loading logic : When the service starts, the configuration in Nacos is first read based on the corresponding parameters, and then the data is parsed and loaded by the Spring framework. The loading process reads the Key and Value through the MapPropertySource class;

 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);
    }
}

Request service : The server interacts with the Nacos center through Http requests, carries parameters through the Get request, and calls the Nacos center service to obtain the corresponding configuration;

 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);
    }
}

Fourth, Spring loading

From the structure diagram of the source code, the loading logic of the configuration file is also implemented by the event model, which is described in detail in the previous task management; the core function of the configuration is to load and guide the program when it starts. The key here is EnvironmentPostProcessor understand-- The interface design of 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 interface : load the custom environment of the application;

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

SpringApplication : It is used to start and boot applications, providing core logic such as creating program context instances, initializing listeners, and container refreshing. It can be debugged and analyzed around the run() method;

ConfigurableEnvironment : The core interface of the environment configuration, which involves the identification of the current configuration file, namely profiles.active ; and the parsing capability of the configuration file, that is, PropertyResolver ; in the Loader internal class The implementation of the constructor and loading logic is provided in .

5. Reference source code

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

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