SpringBoot supports configuration files in both properties and YAML formats by default. The former format is simple, but only supports key-value pairs. If you need to express a list, it is best to use YAML format. SpringBoot supports autoloading of configuration files with convention names, eg application.yml. If it is a configuration file with a custom name, you have to find another way. Unfortunately, unlike the former, which has @PropertySourcesuch a convenient loading method, the latter's loading must be implemented with the help of coding logic.
1. The execution order of bootstrap.yml (bootstrap.properties) and application.yml (application.properties)
bootstrap.yml (bootstrap.properties) is used to execute when the program is booted, and it is used to read configuration information earlier. For example, it can be used to configure the parameters used in application.yml, etc.
application.yml (application.properties) Application-specific configuration information, which can be used to configure public parameters to be used in subsequent modules, etc.
bootstrap.yml is loaded before application.yml
2. Typical application scenarios are as follows:
When using Spring Cloud Config Server, you should specify spring.application.name and spring.cloud.config.server.git.uri in bootstrap.yml
and some encrypted/decrypted information
Technically, bootstrap.yml is loaded by a parent Spring ApplicationContext. The Spring ApplicationContext of this parent is loaded first, before the ApplicationContext of application.yml is loaded.
Why do you need to put the config server information in bootstrap.yml?
When using Spring Cloud, configuration information is generally loaded from the config server, in order to obtain configuration information (such as passwords, etc.), you need some early or bootstrap configuration.
Therefore, put the config server information in bootstrap.yml to load the really needed configuration information.
The reading order of configuration files in the git repository:
There are several ways of http access:
(1) First, look for the file according to the name of the application, that is, the name of the application (for example, the name of the project abc).* to find the file.
(2) If there is no corresponding name, read the content in application.properties, and if there is no corresponding name, return an error.
For example, the master branch in the git repository has two configuration files: foobar-dev.yml and application.yml.
Both files have a configuration with the same name but different content, assuming profile=abc-foobar in foobar-dev.yml and profile=abc-application in application.yml
When we visit, for example: localhost:8080/master/foobar-dev.yml, we hit foobar-dev.yml and read abc-foobar
If you visit localhost:8080/master/foobar-default.yml, this file does not exist in git, then hit application.yml and read profile=abc-application
Summary: There is a priority here, first find the corresponding name, if not, find the default application.yml content, if there is no more, then there is no way.
Different modules and microservice modules use their own configuration, and each team manages its own configuration. How to implement different configuration files in different environments:
One environment one warehouse
(1) Wildcard method (personally feel this method is better)
A microservice corresponds to a git repository: the name of the microservice establishes a corresponding relationship with the name of the git repository, so that wildcards can be used
The isolation is better and does not affect the work between teams.
One file per environment, easy to manage.
(2) The way of pattern matching (personal feeling is more troublesome)
