Application configuration management, basic principle analysis

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

One 、 Configuration architecture

In the code engineering of microservices , Configuration management is a complex thing , That is, it is necessary to take configuration isolation measures for each environment , You also need to ensure that the configuration of the production environment is secure ; If enough microservices are divided , Also consider the efficiency of configuring updates ;

Under normal circumstances , In the system of configuration management , There are four main environments ： Development 、 test 、 Grayscale 、 production ; Generally speaking, in addition to the O & M team , Other personnel do not have permission to view grayscale and production configuration , To ensure the security of the configuration ; Two sets of services will be set up in the configuration center ： R & D and production are deployed independently .

Two 、 Configuration mode

There are many configurations involved in the project , There are many types , But from the big structure, it can be divided into ： Engineering level 、 Application level 、 Component level three block ; In fact, this is just a simple view of configuration from the perspective of code engineering , If continuous integration 、 If automation related modules are also taken into account , Configuration management will be more complex ;

From a development perspective , It mainly manages the application level configuration , In the framework of microservices , There are many different services with the same configuration , There are also various differentiated user-defined parameters , Therefore, there is a certain complexity in maintenance ;

In a single service project , Only one... Will exist in the application bootstrap.yml The configuration file , The configuration content is basically the service name , And configuration center address , Other complex configurations are closed for maintenance , Avoid security problems caused by core content leakage ;

The configuration body is usually split into the following levels ： environmental control , Used to identify grayscale and production ; Application basis , Manage and load common configurations for each service ; Service differences are configured in separate files ; And manage multiple configurations by categories and layers ; So as to ensure the safety of configuration and reduce the difficulty of maintenance .

3、 ... and 、Nacos To configure

First of all, from bootstrap.yml File as a starting point , Take the common Nacos Component as an example , Focus on the basic principles , To analyze how the service project is loaded Nacos Configuration center parameters ;

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

Component configuration ： Configuration logic , A single server provides information about its own configuration parameters , From the source code of service management in the previous article , This is a very common method ; Based on this information, we need to Nacos Load the configuration in the service ;

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

Load logic ： Service startup , First read based on the corresponding parameters Nacos Configured in , The data is then parsed and Spring Frame to load , The loading process passes MapPropertySource classes Key and Value The read ;

public class NacosPropertySourceBuilder {
    
    private List<PropertySource<?>> loadNacosData(String dataId, String group, String fileExtension) {
    
        //  Query configuration 
        String data = this.configService.getConfig(dataId, group, this.timeout);
        //  Parsing configuration 
        return NacosDataParserHandler.getInstance().parseNacosData(dataId, data, fileExtension);
    }
}

Request service ： The service side and Nacos Center pass Http Request to interact , adopt Get Request to carry parameters , call Nacos Central Services , So as to obtain the corresponding configuration ;

public class ClientWorker implements Closeable {
    
    public String[] getServerConfig(String dataId, String group, String tenant, long readTimeout) {
    
        //  Core parameters 
        Map<String, String> params = new HashMap<String, String>(3);
        params.put("dataId", dataId);
        params.put("group", group);
        params.put("tenant", tenant);
        //  Perform the requested 
        HttpRestResult<String> result = agent.httpGet(Constants.CONFIG_CONTROLLER_PATH, null, params, agent.getEncode(), readTimeout);
    }
}

Four 、Spring load

From the structure diagram of the source code , The loading logic of the configuration file is also implemented using the event model , This is described in detail in the previous task management ; The core function of configuration is to load and boot when the program starts , The key here is to understand EnvironmentPostProcessor Interface design of ;

public class ConfigFileApplicationListener implements EnvironmentPostProcessor, SmartApplicationListener, Ordered {
    
    //  Basic configuration 
    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);
    }
    //  Load logic 
    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： Used to start and boot applications , Provides creation of program context instances , Initialize listener , Container refresh and other core logic , Can revolve around run() Method to debug and analyze ;

ConfigurableEnvironment： The core interface of environment configuration , Involves identification of the current configuration file , namely profiles.active; And the ability to parse configuration files , namely PropertyResolver; stay Loader The inner class provides the implementation of construction methods and loading logic .

---