The use and experience of Nacos configuration file

1. Getting Started

It is easy to use nacos config in the spring cloud ecosystem, introducing pom dependencies:

        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

Create the bootstrap.properties file and add the connection address of the nacos server:

spring.application.name=demo-api
spring.cloud.nacos.config.server-addr=nacos服务器地址
spring.cloud.nacos.config.prefix=nacos匹配配置前缀，默认为${spring.application.name}

2. Configuration file

2.1. Rule Configuration

The complete format of dataId on nacos is as follows:

${prefix}-${spring.profile.active}.${file-extension}

• prefix : It is taken from the value of spring.cloud.nacos.config.prefix in the bootstrap configuration file, and the default value of this configuration is ${spring.application.name}
• spring.profile.active : Get the profile of the current environment. If the item spring.profile.active is empty, the dataId format becomes ${prefix}.${file-extension}
• file-exetension : It is the data format of the configuration content, which can be configured through configuration item spring.cloud.nacos.config.file-extension . Currently only supports properties and yaml types, the default properties.

In the actual test, if spring.profile.active is configured, the project will actively obtain the configuration files on the nacos server, including: ${prefix}-${spring.profile.active}.${file-extension} , ${prefix}.${file-extension}

2.2. Shared configuration

Larger projects usually need to split configuration information into multiple configuration files, such as database connection information, multi-language configuration, etc. So there are two situations:

1. A project loads multiple configuration files.
2. Multiple projects will share the same configuration file.

At this time, you can use shared-configs or extension-configs , but I haven't found any difference between the two. The function and usage are basically the same. E.g:

spring.cloud.nacos.config.shared-configs[0].data-id=mysql.properties
spring.cloud.nacos.config.shared-configs[0].group=DATABASE_GROUP
spring.cloud.nacos.config.shared-configs[1].data-id=redis.properties
spring.cloud.nacos.config.shared-configs[1].group=DATABASE_GROUP
spring.cloud.nacos.config.shared-configs[2].data-id=common-i18n.properties
spring.cloud.nacos.config.shared-configs[2].group=I18N_GROUP
spring.cloud.nacos.config.shared-configs[2].refresh=true

In the above configuration, replacing shared-configs[n] with extension-configs[n] does not make any difference.

3. Priority

1. Configuration file priority

According to the previous introduction, after using nacos, the source of configuration files of the project has increased. According to the priority order of from high to low, they are:

1. The related Data Id configuration is automatically generated through the internal related rule ${prefix}-${spring.profile.active}.${file-extension} .
2. Data Id configuration supported by extension-configs .
3. Data Id configuration supported by shared-configs .

2. Shared configuration internal priority

Inside the shared configuration shared-configs[n] and extension-configs[n] , the larger the value of n , the higher the priority.

Priority order in the previous example: common-i18n.properties > redis.properties > mysql.properties

3. Local priority

If nacos config is enabled in the configuration file, the same configuration file is created both locally on the nacos server and in the project. The configuration items on the nacos server have higher priority than the local ones.

4. View priority through logs

When you really can't figure out the priority of naco configuration file loading, don't panic, just look at the startup project log.

After enabling nacos config in the spring project, the startup project will print out all the configuration files loaded by nacos on the console, and sort them from front to back in priority order.

According to the previous configuration, the printed log is:

[PropertySourceBootstrapConfiguration.java:112] [] [ ] - Located property source: [BootstrapPropertySource {name='bootstrapProperties-demo-api-native.properties,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-demo-api.properties,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-demo-api,DEFAULT_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-common-i18n.properties,I18N_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-redis.properties,DATABASE_GROUP'}, BootstrapPropertySource {name='bootstrapProperties-mysql.properties,DATABASE_GROUP'}]

4. Project Planning

Here we talk about the idea of nacos config related configuration planning when a project is created.

1. Sub-profile

The function classification of the project local configuration file:

• bootstrap-{profile} : It mainly stores the environment information of nacos. The address of the nacos server in different environments may be different.
• bootstrap : Store nacos basic information that is not related to the environment, such as shared-configs[n], extension-configs, etc., as well as service name, port number, etc.
• application-{profile} : It is mainly used for the configuration of the development environment. Some parameters do not want to be changed directly to the public nacos during local development, but can be modified in the configuration file.
• application : During local development, it stores basic information that is not related to the environment.

In general, after the nacos config service is turned on, it is based on ${prefix}-${spring.profile.active}.${file-extension} on the server. The role of local application is extremely limited, unless it meets the needs of some special local development scenarios.

2. Sub-environment

Although it is possible to divide the environment through ${prefix}-${spring.profile.active}.${file-extension} on a nacos server, it is not recommended to do so.

Different environments have different requirements for the server robustness, security and confidentiality of nacos. It is generally recommended that on a nacos server, connect to different namespaces according to different environments. Even, according to different environments, connects to different nacos servers.

My current common practice is to not store application-related configuration files in the project, but only keep bootstrap.properties file. Configuration files in different environments are completely distinguished by different nacos servers or namespaces, which are run by passing parameters during local runtime or DevOps deployment. For example, the configuration of Program arguments at the local runtime:

--nacos.url=http://x.x.x.x:xxxx
--nacos.config.namespace=xxx
--spring.cloud.nacos.discovery.enabled=false

3. Sub-item

Items are distinguished by GROUP. Some configurations common to multiple projects can be separated into several groups, such as database connection configuration, multi-language configuration, etc.