table of Contents
Configuration issues faced by distributed systems
Introduction to Spring Cloud Config
Configuration issues faced by distributed systems
Microservices means that the business in a monolithic application should be split into individual services. The granularity of each service is relatively small, so a large number of services will appear in the system. Since each service requires the necessary configuration information to run, a centralized and dynamic configuration management facility is essential. SpringCloud provides ConfigServer to solve this problem. Each of our microservices comes with an application.yml, which is managed by hundreds of configuration files.
Introduction to Spring Cloud Config
SpringCloud Config provides centralized external configuration support for microservices in the microservice architecture. The configuration server provides a centralized external configuration for all environments of different microservice applications.
SpringCloud Config is divided into server and client.
The server is also known as a distributed configuration center. It is an independent microservice application that is used to connect to the configuration server and provide access interfaces for clients to obtain configuration information and encrypt / decrypt information.
The client manages application resources and business-related configuration content through a designated configuration center, and obtains and loads configuration information from the configuration center at startup.
The configuration server uses git to store configuration information by default, which is helpful for version management of the environment configuration, and can easily manage and access configuration content through the git client tool.
use
Centrally manage configuration files.
Different configurations for different environments, dynamic configuration updates, sub-environment deployment such as dev / test / prod / beta / release.
Dynamically adjust the configuration during operation. It is no longer necessary to write configuration files on the machine where each service is deployed, and the service will submit to the configuration center.
Unifiedly pull and configure your own information.
When the configuration changes, the service can detect the configuration change and apply the new configuration without restarting.
Expose configuration information in the form of REST interface.
Config architecture
springCloudConfig is divided into a server and a client. The server is responsible for publishing the configuration files stored in the local, git or svn into a REST-style interface. The client can obtain the configuration from the server-side REST interface. However, the client cannot actively sense the configuration change, so as to actively obtain the new configuration. This requires each client to trigger its own / refresh interface through the POST method. And the SpringCloudBus we mentioned above has played its role
SpringCloudBus connects the nodes of a distributed system (a bit like a message queue) through a lightweight message broker. This can be used to broadcast status changes (such as configuration changes) or other management instructions. SpringCloudBus provides endpoint / bus / refresh accessed through the post method (spring boot has many monitored endpoints, such as / health). This interface is usually called by the git hook function (listening trigger) to notify each SpringCloudConfig client to go The server updates the configuration .
The git server will pull the configuration file from the remote git and store it in the local git file library.When the remote git is not available, it will pull the configuration information from the local git file library
The following is a workflow diagram of spring cloud config combined with bus
The second is the priority relationship when accessing the configuration file. Please see the following figure (the data I tried myself, accessed directly from the server)
The configured priority is from top to bottom, with the highest
