Apollo is an open source configuration management center developed by Ctrip framework department. It can centralize the management of the configuration of different application environments and clusters. After the configuration is modified, it can be pushed to the application end in real time. This paper introduces the concept of configuration, the necessity of configuration center and the characteristics of Apollo. It focuses on the analysis of the design principle of Apollo client, and understands the principle of Apollo, which can help readers understand the implementation principle of configuration center.
1、 What is configuration
Configuration is the ability to dynamically adjust behavior when a program is running.
The configuration has the following properties:
- Configuration is a read-only variable independent of the program. The same program will have different behavior under different configurations, and the configuration is read-only for the program. Therefore, the program can change its behavior by reading the configuration, but it cannot change the configuration file by itself.
- Configure the entire lifecycle of the accompanying application
The application is initialized by reading the configuration at startup, and changes its behavior according to the configuration at runtime.
- There are several loading methods for configuration
- Hard code inside the program, which is anti pattern, is not recommended.
- Configuration file.
- Environment variables, configuration can be preset in the operating system environment variables, program runtime read.
- Start parameters, which can be provided at one time when the program starts.
- Based on the database, the volatile configuration is placed in the database, so that the configuration can be flexibly adjusted during the runtime.
- Configuration needs governance
- Permission control: the modification of configuration needs to have more perfect authority control, otherwise incorrect configuration will cause disaster.
- Different environment, cluster configuration management: the same program in different environments (development, testing, production), different clusters (such as different data centers) often need different configuration, so we need to improve the environment and cluster configuration management.
- Framework class component configuration management: such as the configuration of cat client.
2、 Why a configuration center is needed
Before the introduction of the configuration center, the following pain points will occur during the general research and development:
The configuration format is scattered and nonstandard
- Some use the properties format, some use the YML format, some use the XML format, and some save the DB format. The methods are various.
- It mainly adopts local static configuration, which is troublesome to modify
In distributed microservice environment, when there are many service instances, configuration modification is time-consuming and laborious.
- Easy to cause production accidents
For example, bring the configuration of the test environment to the production environment.
- The configuration lacks security audit and version control functions
Unable to view the person who modified the configuration, what content was modified, and the modification time. If there is a problem, it can not be rolled back in time.
3、 Delivery and configuration separation
1. Separation of delivery and configuration
When the traditional method is applied in the package deployment, it will print out different configuration packages for different environments, and each package contains environment specific configuration. However, it is recommended to package and deliver microservices such as container image. Generally, the application image only takes one copy, which can be deployed to different environments. Therefore, this requires that the delivery and configuration should be separated. Only one delivery is made, and it is immutable and can be deployed to any environment. However, the configuration of all environments can be centrally configured in the configuration center, and the application at runtime can dynamically pull the corresponding configuration from the configuration center according to its own environment.
2. Abstract standardization
The configuration center should encapsulate the details of shielding configuration management and different configuration formats, so as to facilitate users to conduct independent configuration management
- The UI of configuration management interface is convenient for application developers to manage and publish configuration.
- The packaged client API is convenient for application integration and configuration.
3. Multi environment and multi cluster
Most microservice applications adopt multi environment deployment. The general standard environment includes development / test / production. Some applications also need multi cluster deployment, such as supporting cross machine room or multi version deployment. The configuration center needs to support centralized management of multi environment and multi cluster application configuration.
4. High availability
The configuration center cannot be hung up, otherwise the microservices will be greatly affected.
5. Real time
Configuration updates need to be notified to the client as soon as possible. Some configurations require high real-time performance, such as master-slave switch configuration or blue-green deployment configuration. These require the ability to switch configuration in seconds.
Configuration needs governance, including:
- In configuration audit, it is necessary to record the reviser, modification contents and modification events, so as to facilitate the traceability of problems.
- Configure version control. Each change needs to be versioned. If there is a problem, it can be rolled back to the previous version.
- Configuration permission control, configuration change release requires authentication and authorization.
- Grayscale Publishing: when configuring publishing, you can make a few instances take effect first, and then you can expand the application scope if there is no problem.
4、 What is Apollo
Apollo is an open source configuration management center developed by Ctrip framework department. It can centralize the management of the configuration of different application environments and clusters. After configuration modification, it can be pushed to the application end in real time, and has the characteristics of standardized permissions and process governance.
The characteristics of Apollo are as follows:
- Unified management of different environment, different cluster configuration. Apollo provides a unified interface to centrally manage the configurations of different environments, clusters, and spaces. Moreover, the same code deployed in different clusters can have different configurations.
- Configuration modification takes effect in real time (hot release)
- Version release management
- Grayscale Publishing
- Client configuration information monitoring
You can easily see which instances are used by the configuration on the interface.
- Provides Java and. Net native clients
- Provide open platform API
- Simple deployment
5、 The basic model of Apollo
We can see the basic process of Apollo configuration:
- The user now modifies / publishes the configuration in the UI interface.
- Apollo configuration center will push configuration update information to Apollo client.
- The client pulls the latest configuration from the Apollo configuration center, and notifies the application after updating the local configuration.
6、 Design of Apollo client
We have a preliminary understanding of Apollo’s infrastructure, but if we want to understand it more deeply, we have to start from its implementation principle.
1. Implementation principle of Apollo client
- The client and server will maintain a long connection to get the push of configuration update at the first time.
- The client will regularly pull the latest configuration of the application from the Apollo configuration center server, and the client will report to the local version. By default, the client will pull the latest configuration every 5 minutes, which can also be specified by the runtime apollo.refreshInterval The unit is minutes.
- After the client obtains the latest configuration of the application from the server of Apollo configuration center, it will be saved in memory.
- The client will cache a copy of the configuration pulled from the server in the local file system to ensure that the configuration can be recovered locally in case of service unavailability or network failure, and a certain degree of high availability is achieved.
- The application obtains the configuration of the crime from the client and subscribes to the configuration update notification.
2. Configuration update push implementation
As mentioned above, Apollo client and server maintain a long connection, so that configuration updates can be pushed at the first time. In fact, the long connection is realized through HTTP long polling
- Client sends HTTP request to server
- The server keeps the connection for 60s
- If there is a configuration change concerned by the client in 60s, the request will return immediately and inform the client of the configuration change of the namespace information, and the client will pull the latest configuration of the namespace accordingly.
- If there is no configuration change concerned by the client within 60s, the HTTP status code 304 is returned to the client.
7、 Apollo overall design
Before straightening out the train of thought, we should first understand the modules
Provide configuration acquisition interface
Provide configuration push interface
Serving Apollo client
Provide configuration management interface
Provide configuration modification publishing interface
Service for the management interface portal
Get configuration for application, support real-time update
Get the service list of configservice through MetaServer
Calling configservice with SLB mode of client soft load
Configuration management page
Get the service list of adminservice through MetaServer
Calling adminservice with SLB mode of client soft load
For service discovery and registration
The config / adminservice registers the instance and reports the heartbeat regularly
Deploy with configservice
Portal accesses MetaServer through domain name to obtain the address list of adminservice
The client accesses MetaServer through the domain name to obtain the address list of configservice
Equivalent to the deployment of Eureka proxy and configservice
Cooperate with the domain name system to help portal access MetaServer and obtain the address list of adminservice
Cooperate with domain name system to assist client to access MetaServer to obtain address list of configservice
And domain name system configuration to help users access the portal for configuration management.
1. Simplified architecture a
Assuming that there is no service discovery for distributed microservices, then:
- The portal will call adminservice for configuration management and publishing
- Configservice keeps a long connection with the client. Configservice obtains the configuration from the client. Configservice and client can update the configuration in real time and ensure that the configuration update is not lost.
- Configservice and adminservice share configdb. Configdb stores the configuration information of a project in an environment, and the three must be deployed in each configuration environment (dev / fat / UAT / Pro).
- Protal has an independent PORTALDB that stores metadata information about user permissions, projects and configurations. You can deploy more than one portal environment.
2. Simplified architecture B
Because the client needs the address list to find configservice, and the portal needs the address list to find the adminservice. At this time, service discovery is required.
- After the config / adminservice is started, it will register with Eureka service registry and send it regularly to keep the heartbeat.
- Eureka adopts cluster deployment and uses distributed consistency protocol to ensure the final consistency of each faction.
- The client and portal can find the address list of configservice and adminservice through Eureka.
Because Ctrip needs to be compatible with its own. Net system, it introduces MetaServer service, which is equivalent to proxy proxy, exposing Eureka’s service discovery interface in the form of a simpler and more explicit HTTP interface.
However, MetaServer itself is also stateless and deployed in cluster mode. How can client / protal discover MetaServer? The traditional way is to use hardware (where you can specify the location of MetaServer) or software load balancer.
3. Complete structure
Use nginxlb (also known as software load balancer), configure a domain name for MetaServer cluster by operation and maintenance, point to nginxlb cluster, and then load balance and traffic forwarding of MetaServer by nginxlb. The client / portal accesses the MetaServer cluster indirectly through the domain name + nginxlb.
This is a pitfall. Because a set of portal can centrally manage the configuration in multiple environments (dev / fat / UAT / Pro), when switching the environment, you need to pay attention to whether there is a clear mark in the configuration file (springboot) such as. Properties (. YML), which namespace configuration needs to be taken out. Otherwise, the client will not be able to pull the configuration of the configuration center to the local.
I think the old fellow is interested in the official account of Java Architects Association.