Design and implementation of Ctrip open source project — Apollo

Apollo is the open source unified application configuration center of Ctrip framework configuration department, which supports configuration management from four dimensions, namely Appllication (application), environment (environment), Cluster (Cluster) and namespace (namespace).

Configuration is a read-only variable independent of the program. Programs can read configuration to change their behavior, but should not change configuration. Configurations accompany the entire life cycle of the application, read at startup and adjust behavior based on the configuration at run time. Configurations can also be loaded in a variety of ways, such as internal hard code, configuration files, environment variables, startup parameters, database-based, etc.

Because the configuration can change the behavior of the program, the wrong configuration will lead to the failure of the program, so the modification and release of the configuration need a set of sound permission management, in addition to the configuration in different environments and clusters are different, which requires good management.

Apollo is a governance configuration management platform that provides unified management of configurations across different environments and clusters, and configuration changes take effect in real time. A new version is created each time the configuration is modified, which can be easily rolled back if the configuration fails.

Apollo supports grayscale publishing, which allows you to run critical features on multiple machines before releasing them. It also provides the functions of permission management, release audit, operation audit, and the ability to monitor client configuration information. By the way, Apollo has native Java and.NET clients and good support for Spring.

Above is Apollo’s configuration center screen, with a list of environments in the current application at the top left and some project information at the bottom. The two parts on the right can be simply considered as two files, in which each Application has the default configuration management through the table situation, you can see that there are changes history, modifiers and other information as well as some function buttons.

Adding a modified configuration item in Apollo can be performed directly by clicking the New or modify configuration button. Note that the modified configuration does not take effect immediately, but takes effect only after you click Publish.

As you can see, we first get the config object, then call the getIntProperty method and pass in the key and default values to get the latest values for the program.

Apollo provides event triggering mechanism. You only need to add an addChangeListener. OnChange method will be called every time configuration changes are made, and the corresponding configuration change event will be passed in. This event contains changes to configuration items.

A simple use of Spring integration simply adds EnableApolloConfig to the AppConfig class. In actual configuration, we still recommend using the following method, which also supports configuration change events.

As mentioned earlier, Apollo supports four dimensions. In the application dimension, Apollo can identify applications with a uniquely identified appId while in the run-time state. In the environment dimension, we consider environment information irrelevant to the code, only relevant to the current code deployment body, so this information is stored on the machine by default.

The third dimension is clustering, which is equivalent to grouping different instances of an application. Clustering can be physical or logical. The configuration can be different for different clusters, so we default to data centers as clusters.

The last dimension, namespace, is an abstract concept. It is simply a group of different configurations of an application. By default, an application has its own namespace-application configuration, or it can use the configuration of a common component.

The Config server at the bottom of the figure provides functions such as reading and pushing configurations. The service object is the client. The Admin Service provides the functions of modifying, publishing, and auditing configurations. The Service object is the Apollo Service interface. Both services are multi-instance stateless deployments.

The upper-layer Mate Server is mainly used to encapsulate the interface built by Eureka service. In the actual call, the client first gets the address list of the service it is interested in from the Mate Server, and then accesses the corresponding interface directly via IP and port.

To facilitate actual deployment, Mate Server, Eureka, and Config Service are deployed on the same node.

Eureka provides a complete implementation of service registration and publication, as well as seamless integration with Spring Cloud, which can transform an externally dependent Eureka implementation into an internal one. And because Eureka is open source, it’s easier to find problems and understand implementation principles.

The running time of the client and the application are in the same container. When the application is started, the client initializes and pulls the configuration from the configuration center. The obtained configuration is cached in the memory and local file of the application respectively. In addition, the client and server maintain a long connection to ensure that configuration changes can be detected in real time.

By default, the server keeps the connection for 30 seconds after the client initiates a long connection. During this period, the server returns if the configuration changes. If the configuration changes, the server disconnects and the client automatically reconnects. Spring DeferredResult is implemented using asynchronous servlets to ensure long connections on the server side.

Making address: https://github.com/ctripcorp/apollo

The server is developed based on Spring Cloud and Spring Boot