SpringCloud (unified configuration service)

For traditional monolithic applications, configuration files are often used to manage all configurations. For example, a single application developed by springBoot can put the configuration content in the application.yml file. If you need to switch environments, you can set multiple profiles and specify spring.profiles.active={profile} when starting the application. However, in the microservice architecture, the configuration management of microservices generally has the following requirements:

a) Centralized management configuration. An application system using a microservice architecture may contain hundreds or thousands of microservices, so centralized management of configuration is very necessary.

(b) Different environments, different configurations. For example, datasource configurations are different in different environments (development, test, staging, production, etc.).

(c) It can be adjusted dynamically during operation. For example, according to the load of each microservice, the size of the data source connection pool or the fusing threshold can be dynamically adjusted, and the microservice will not be stopped when adjusting the configuration.

(d) The configuration can be automatically updated after modification. If the configuration content changes, the microservice can automatically update the configuration. To sum up, for the microservice architecture, a common configuration management mechanism is essential, and the common practice is to use the configuration server to manage the configuration. The spring cloud bus utilizes management configurations such as Git or SVN, and uses message buses such as Kafka or RabbitMQ to notify all applications, so as to realize automatic configuration update and refresh the configuration of all microservice instances.