Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "what is the role of the configuration center of micro-service architecture". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

First, why do you need a "configuration center"?

Let's first take a look at how we deal with various configuration parameters in traditional projects without a "configuration center":

It is generally static configuration. Most of them write a separate configuration file in the project, such as "config.conf", and then write various parameter configuration, application configuration, environment configuration, security configuration, and business configuration into this file. When configuration is needed in the project code logic, it is read from this configuration file. This is simple, but if the parameters need to be modified, it is very inflexible and even requires a restart of the running project to take effect. I believe that most of the development students have a lot of experience.

The profile cannot distinguish between environments. Because the configuration file is placed in the project, but our project may have multiple environments, such as test environment, pre-release environment, production environment. The configuration parameters used by each environment are theoretically different, so we configure different parameters according to different environments in the configuration file, these are manual maintenance, when the project is released, it is extremely easy to make mistakes due to the mistakes of the developers.

The configuration file is too fragmented. If multiple logical modules are deployed independently in a project, and the configuration content used by each module is different, the traditional practice is to put a configuration file in each module, and even the configuration file format of different modules is not the same. The long-term result is that the configuration files are too fragmented and difficult to manage.

Configuration changes cannot be traced. Because of the static configuration file, when the configuration is modified, it is not easy to form a record, let alone trace who modified it, what was the modification time, and what was it before the modification. Since there is no traceability, there is no way to roll back the configuration when the configuration goes wrong.

The above is only in the form of configuration files as an example, some projects will use database configuration, although a little more flexible, but still can not completely solve the above problems. Since traditional project configuration has so many drawbacks, let's take a look at how the configuration Center solution addresses these pain points:

The idea of "configuration center" is to put all kinds of configurations, parameters and switches in the project into a centralized place for unified management, and provide a set of standard interfaces. When each service needs to get the configuration, it comes to the "configuration center" interface to pull. When the various parameters in the configuration Center are updated, each service can also be notified to synchronize the latest information in real time to make it dynamically updated.

Then, according to the above ideas, our ideal "configuration center" should have the following characteristics:

Configuration centralized management, unified standard

Separation of configuration and application

Real-time update

High availability

How does the "configuration center" with the above characteristics solve the problems faced by the traditional configuration above?

The use of "configuration centralized management" can well solve the traditional problem of "configuration files are too scattered". All the configurations are managed in the configuration center, and there is no need to bring one for each project, which greatly reduces the development cost.

The use of "separation of configuration and application" can well solve the problem that the traditional "configuration file can not distinguish the environment". The configuration does not follow the environment, and when different environments have different requirements, you can obtain it from the configuration center, which greatly reduces the deployment cost of operation and maintenance.

The function of "real-time update" is used to solve the problem of traditional "static configuration". When the online system needs to adjust the parameters, it only needs to be dynamically modified in the configuration center.

Now that the configuration is managed uniformly, the position of the configuration center in the whole system is very important. Once the configuration center can not provide services normally, it may lead to the failure of the project as a whole. Therefore, "high availability" is another key indicator of the configuration center.

Second, the principle and application of "configuration center"?

Through the above introduction, we can understand that the principle of "configuration center" is not very complicated. Its core functions are not many, mainly as follows:

Implement the record of the configuration

Read, update and cancel the configuration

Implement the view of configuration

However, around these core functions, we also need to ensure high feasibility, to achieve real-time updates, to be easy to use, and to have the functions of authority management, operation audit, and so on. After adding these peripheral auxiliary functions, a perfect configuration center is not so simple.

Let's take a look at how to select and apply it in a real project:

Although the core principle of the configuration center is not complex, we can implement a configuration center according to the principle, but if there are no special needs, it is not recommended to repeat the wheel. after all, there are many mature open source solutions in the industry that can be directly selected. Here are some popular open source components of the configuration center for your reference:

Apollo

Apollo is a distributed configuration center open source by Ctrip.

Apollo has many features, such as: the configuration update can take effect in real time, but also can support grayscale publishing function. And can carry on the version management, the operation audit and other functions to all the configurations, and provide the open platform API. In addition, because a lot of people use Apollo, the information on the Internet is also very rich, and the information on github is also very detailed.

The above is the basic model of Apollo, the structure is very simple. However, it has many functions, and it has been said before that the configuration center has high requirements for high availability. Let's move on to look at the architecture of Apollo:

Spring Cloud Config includes two parts: Config Client and Config Server. Config Server implements the storage of configuration files, provides access to configuration files in the form of interfaces, and then Config Client obtains data through these interfaces.

Disconf

Disconf is a distributed configuration center open source by Baidu. In fact, many front-line manufacturers have their own open source configuration center components. Baidu's Disconf is also singled out here because it is hot online, easy to use, and the project is also hosted on github. It is based on Zookeeper to achieve real-time notification and entry into force after configuration changes.

This is the end of the content of "what is the role of the configuration center of micro-service architecture". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.