Official account: Mufeng Technical Notes

A true master always has the heart of an apprentice

The introduction

The configuration center is a very important infrastructure service in the microservice architecture system, and is responsible for centralized management of distributed configuration, hot release of configuration and audit. This article focuses on how the configuration hot publishing feature of Apollo configuration Center is implemented.

How is configuration hot publishing implemented

1. Configure the main release process

As shown in the figure above, the main process of configuration publishing is as follows:

(1) The user advertises configuration information to AdminService through the Portal.

(2) AdminService inserts a message record into the ReleaseMessage table after the configuration is published;

(3) ConfigService contains a timer thread that scans the ReleaseMessage table every second to see if there are new message records in the table;

ConfigService notifies all message listeners if there is a configuration update.

(5) Notification Controller will notify corresponding clients according to published configuration information;

The client’s interaction with the configuration center is roughly as follows:

In fact, the configuration update push here is not really information push, but through long polling to achieve configuration update. In fact, it is not a configuration update push, but a configuration update notification push. After receiving the notification, the client needs to obtain the specific configuration information of the change.

2. Long polling

(1) What is the problem if Push data is used?

The server needs to establish a long-term connection with the client. When data is updated, the server can push data in a timely manner. However, the server cannot perceive the processing capability of the client, which may cause data backlog. In addition, in the case of cluster, some nodes will be notified of failure if they are not online. After the clients are online again, they need to be compensated and pushed, and the nodes may be expanded. For the business scenario of configuration center, data pushing through Push mode is complicated.

(2) What are the problems if data is pulled in Pull mode?

PullIn this mode, clients proactively request data from the configuration center and pull corresponding configuration information. Because the client is active pull, so there is no data accumulation problem. But how to pull the data, when to pull, how to control the frequency of pull, these are all problems. If the frequency is too high and the configuration is not updated, it can cause unnecessary connection stress on the server. If the frequency is too low, there will be delays in configuration updates. Therefore, it is also not suitable for the service scenario of the configuration center.

(3) Long polling

The client makes a request to the configuration center, but the configuration center does not respond immediately. Instead, the configuration center holds the request until the specified time expires. If the configuration is not changed, Http status code 304 is returned to the client. After the timeout returns, the client will initiate the request again.

If the configuration is changed, the namespace information is displayed. The client obtains the configuration information based on the namespace information. In addition, to ensure the validity of the configuration, the client periodically requests configuration information to prevent possible anomalies in configuration updates, which is a fallback mechanism for data guarantee. In addition, the obtained configuration is synchronized to the local configuration file. In this way, the client can obtain configuration information from the local configuration file even if the client cannot communicate with the configuration center.

So the question is, why not just reply to the configuration information directly in the response to the long poll? Due to the fact that there are already steps in the timed pull configuration, in order to ensure a single principle and code simplicity and reuse. So this is a way to get configuration updates and then pull data.

3. The client obtains configuration information

Let’s take a look at how the client works, as shown below:

ConfigServiceLocator: Obtains the ConfigService address list from the Eruka registry.

(2) RemoteConfigLongPollService: get to the address list from ConfigServiceLocator information, through the way of long polling for configuration changes information;

(3) RemoteConfigReposity: Gets the changed configuration data from ConfigService.

(4) LocalFileConfigReposity: Reposity the configuration data to the local server and serves as the source of the local configuration data.

(5) DefaultConfig: Mainly interacts with the business side, provides the method of obtaining configuration, and registers configuration change events.

conclusion

This paper mainly discusses the configuration hot publishing of Apollo configuration center, and analyzes why long polling is more suitable for data interaction of configuration center. We can also use this as a reference in future architecture design. In addition, the client design also reflects the hierarchical and single responsibility of the code style, our own in the actual project development is also more reference significance.