Foreword
Thinking about a problem, we will encounter such a scenario in real development. We split the application into multiple configuration files, so how does Nacos manage multiple configuration files?
Load multiple configurations
We already know that the correspondence between the Spring application and the configuration content in Nacos is controlled by the following three parameters:
- spring.cloud.nacos.config.prefix
- spring.cloud.nacos.config.file-extension
- spring.cloud.nacos.config.group
By default, the way we use: Data ID=${spring.application.name}.properties Group=DEFAULT_GROUPconfiguration.
For example: there is now a demand: we want to do unified configuration management for all applied Actuator modules and log output.
The simplest way to implement is to apply the relevant configuration Actuator.properties and log log.properties. We split these two types of configuration, now need to share the
first step:
to create in Nacos in Data ID=actuator.properties, Group=DEFAULT_GROUPand Data ID=log.properties, Group=DEFAULT_GROUPthe configuration of the content.
Step 2:
Configure the two configuration contents to be loaded in the Spring Cloud application by using spring.cloud.nacos.config.ext-config parameters, such as:
spring.cloud.nacos.config.ext-config[0].data-id=actuator.properties
spring.cloud.nacos.config.ext-config[0].group=DEFAULT_GROUP
spring.cloud.nacos.config.ext-config[0].refresh=true
spring.cloud.nacos.config.ext-config[1].data-id=log.properties
spring.cloud.nacos.config.ext-config[1].group=DEFAULT_GROUP
spring.cloud.nacos.config.ext-config[1].refresh=true
As you can see:
spring.cloud.nacos.config.ext-config ：Set is an array List type. Each configuration includes three parameters: data-id, group, refresh
refresh: This parameter controls when the contents of the configuration file support auto-refresh, by default, only the default configuration will be loaded automatically refresh, for the configuration to load the contents of these extensions need to configure the settings Only then will automatic refresh be achieved.
Shared configuration
In fact, the configuration file can already be shared through the above method of loading the collection. Nacos also provides another convenient configuration method
spring.cloud.nacos.config.shared-dataids=actuator.properties,log.properties
spring.cloud.nacos.config.refreshable-dataids=actuator.properties,log.properties
spring.cloud.nacos.config.shared-dataids:The parameters are used to configure multiple shared configurations Data Id. When multiple are used, they are separated by commas
spring.cloud.nacos.config.refreshable-dataids: The parameters are used to define which shared configuration Data Iddata IDs can be dynamically refreshed in the application when the configuration changes. Multiple `` separated by commas . If there is no explicit configuration, by default, all shared configurations do not support dynamic refresh
Configure loading priority
When we load multiple configurations, if there is the same key, we need to understand the priority relationship of configuration loading.
When using Nacos configuration, there are three main types of configuration:
- Through
spring.cloud.nacos.config.shared-dataidsdefined sharing configuration - Through
spring.cloud.nacos.config.ext-config[n]defined load configuration - By internal rules (
spring.cloud.nacos.config.prefix,spring.cloud.nacos.config.file-extension,spring.cloud.nacos.config.groupsplicing out of these parameters) Configuration
To figure out the loading order of these configurations, we add these configurations to the application and observe the logs
spring.cloud.nacos.config.ext-config[0].data-id=actuator.properties
spring.cloud.nacos.config.ext-config[0].group=DEFAULT_GROUP
spring.cloud.nacos.config.ext-config[0].refresh=true
spring.cloud.nacos.config.shared-dataids=log.properties
spring.cloud.nacos.config.refreshable-dataids=log.properties
We can see the loading order through the log: A <B <C
References
