In the previous section, we have looked at the emergence of distributed architectures. Some problems and solutions in the evolution of distributed architecture are also mentioned. Here we focus on the distributed configuration section.
What is a distributed configuration center
Background of distributed configuration
inaboveAs we learned, distributed architectures slowly evolve, eventually leading to architectures like the following.
What are the problems with such an architecture?
- Multiple user service node, there is a local configuration (application. Yaml/application. The properties). As a result, if there are more and more nodes, you may need to maintain as many or more configuration files as there are nodes.
- User services and commodity services may have some of the same configuration, such as relational database configuration information and non-relational database configuration information. However, these configurations cannot be shared and can only be redundant for each service.
- If the configuration needs to be updated, it cannot be guaranteed that all nodes of the same service will be updated, or that redundant configurations of different services will be updated synchronously. It creates a certain amount of uncertainty.
- Configuration updates also require re-service, which cannot meet the requirements of high availability.
- In multiple environments, different configurations need to be maintained, but configurations cannot be isolated.
Why do you need a distributed configuration center
The introduction of the distributed configuration center is to solve the problem of distributed configuration caused by the above architecture.
Main advantages:
- Manage application and service configurations for all environments in a centralized, external, and dynamic manner.
- Eliminates the need to redeploy applications and services when configuration changes, making configuration management more efficient and agile.
- Centralized configuration management makes it easier to implement stateless services and make it easier for services to scale flexibly on demand.
- Realize configuration isolation and unified management of multiple environment configurations.
- Reduce the heavy workload of development and operation.
Configuration center principle and implementation
In fact, based on the above problems solved, we have a general idea of what elements this distributed configuration center needs:
- Multiple nodes of the same service only need to maintain one configuration – configure content centralized storage
- Dynamic service scaling – persistent storage
- Applications need to get their configuration from a centralized configuration center — providing external apis
- Configuration changes do not require application redeployment — clients are notified of data changes
- Ensure availability when configuration center is abnormal – Configure high availability and local cache
With these elements in mind, let’s look at the current implementations of most configuration centers
In the figure above, git/zookepper/mysql stores are used as persistent stores for configuration content. High availability of the configuration center is realized through local cache and configuration server cluster. Periodically listens to the configuration of the server to notify of data changes. Such an architecture can accomplish most of the functions required by a distributed configuration center.
conclusion
In this section, the generation and principle of the distributed configuration center in the evolution of distributed architecture are described. The use and principle of Alibaba NacOS as the configuration center will be selected later.