Features

Unified management of different environments, different cluster configuration
- Apollo provides a unified interface, centralized management of different environments (environment), different clusters (cluster), configure different namespaces (namespace) of.
- The same code deployed in different clusters can have different configurations, such as the address of zk
- It can easily support multiple different applications to share the namespace (namespace) with a configuration, while also allowing application configuration to be shared coverage
- Configuration interface supports multiple languages (Chinese, English)
Configuration changes with immediate effect (heat release)
- After you modify the user configuration and release Apollo, the client in real-time (one second) receive the latest configuration and notification to the application.
Release management
- All configuration concept has released version, which can easily support rollback configurations.
Gray release
- It supports the configuration of the gray release, such as point after release, takes effect only on the part of application examples, and other observations again and again to all application instances after a period of time, no problem.
Rights management, post audit, operational audit
- Application and configuration management has improved rights management mechanism, the management configuration is also divided into two aspects of editing and publishing, thereby reducing human error.
- All operations have audit logs, you can easily track down the problem.
Client configuration information monitoring
- You can easily see what is used in the configuration example
Java and .Net provide native client
- It provides native Java and .Net client for easy application integration
- Support Spring Placeholder, Annotation and Spring Boot of ConfigurationProperties, easy to use application (requires Spring 3.1.1+)
- Http while providing an interface, non-Java and .Net applications can also easily use
It provides an open platform API
- Apollo itself provides a fairly complete unified configuration management interface, support for multiple environments, multiple data center configuration management properties, rights, governance processes.
- But Apollo for general considerations, the modification will not do too many restrictions, provided that they meet the basic format can be saved.
- In our research we found that for some consumers, their configuration may be more complex formats such as xml, json, do need to check the format.
- Some consumers, such as the DAL, not only have a specific format, and the input value need be stored for the rear check, such as checking a database, the user name and password match.
- For such applications, support applications Apollo parties modify and distribute configuration in Apollo through an open interface, and has a perfect authorization and access control
Simple deployment
- Configuration Center as a basis for service availability requirements are very high, which requires as little as possible of Apollo external dependencies
- The only external dependency is MySQL, so deployment is very simple, as long as the installed Java and MySQL can run up to let Apollo
- Apollo also provides packaged script, you can generate a key installation package for all needs, and supports custom run-time parameters

The figure briefly describes the implementation of the principle of Apollo client:

The client and server to maintain a persistent connection, so that it can push the first time to obtain the updated configuration. (Achieved through Http Long Polling)
The client will be timed from the Apollo latest configuration center server configuration pull applications.
- This is a fallback mechanism, resulting in the failure to prevent the push mechanism is not configured to update
- The client will report timing of a local version of pulling, so that under normal circumstances, the timing for the operation of the pull, the server returns 304 - Not Modified
- The default timing frequency of once every 5 minutes, pull, by the client can be specified at run time System Property: apollo.refreshIntervalcovered, in minutes.
After the client obtains from the Apollo configuration center server to the latest configuration of the application, it will be kept in memory
The client will get from the server to configure the cache to a local file system
- In the face of service is not available, or when the network does not make sense, still from the local recovery configuration
The application can get the latest configuration from Apollo clients, subscribe to configure update notification

Apollo distribution center design

The figure of Apollo briefly describes the overall design, we can see from the bottom up:

Config Service provides configurable read, push and other functions, is the object Apollo client service
Admin Service provides configuration changes, publishing and other functions, clients are Apollo Portal (Management Interface)
Config Service and Admin Service are multi-instance, stateless deployment, you need to register yourself and to keep the heartbeat Eureka
Services we stand on top of a layer of Eureka Meta Server package for Eureka Discovery Interface
Client domain names Meta Server Config Service to obtain a list of services (IP + Port), and then directly through the IP + Port access services, while at the Client side will do load balance, error retry
Portal domain names Meta Server Admin Service to obtain a list of services (IP + Port), and then directly through the IP + Port access services, while at the Portal side will do load balance, error retry
To simplify deployment, we will actually Config Service, Eureka and Meta Server three logical roles deployed in the same JVM process

1.3 Each module overview

1.3.1 Config Service

Get Interface provides configuration
Providing push configuration updates interface (based Http long polling)
- The service uses Spring DeferredResult asynchronous, thereby greatly increasing the number of connections length
- Currently tomcat embed using the default configuration is up to 10,000 connections (can be adjusted), using the measured 4C8G virtual machine can support 10,000 connections, so to meet the needs of (an application example will initiate a long connection).
Interface client services targeted at Apollo

1.3.2 Admin Service

Provide configuration management interface
Provide configuration changes, publishing interfaces
Interface service targets for Portal

1.3.3 Meta Server

Portal access Meta Server Admin Service to obtain a list of services (IP + Port) by domain name
Client access Meta Server Config Service to obtain a list of services (IP + Port) by domain name
Meta Server service information Config Service and Admin Service from Eureka, is the equivalent of a Eureka Client
Adding a Meta Server role is mainly to details of the packages found in the service of Portal and Client, you will never get service information Admin Service and the Config Service through a Http interface without concern behind the actual service registration and discovery component
Meta Server is a logical role, Config Service is in a JVM process, so the IP, port and Config Service in the deployment and consistent

1.3.4 Eureka

Based on Eureka and Spring Cloud Netflix service registration and discovery
Config Service and Admin Service service will be registered to Eureka, and keep the heartbeat
For simplicity, the current Eureka when deploying and Config Service is in a JVM process (through Spring Cloud Netflix)

1.3.5 Portal

Provides a Web interface for users to manage the configuration
Admin Service to obtain a list of services (IP + Port) by Meta Server, by IP + Port Access Service
Do load balance, the error retry side Portal

1.3.6 Client

Apollo provides a client program, configuration to obtain applications, real-time updates and other functions
Config Service to obtain a list of services (IP + Port) by Meta Server, by IP + Port Access Service
Do load balance, the error retry Client side

And Apollo Spring / Spring Boot Integration means the almost certain: the application start-up phase, Apollo acquired from the distal end of the configuration, and then assembled into PropertySource and can be inserted in the first

Apollo when creating the project, will by default create an "application" of Namespace. As the name suggests, "application" is used for the application itself, the familiar Spring Boot students know, Spring Boot project has a default configuration file application.yml. Here application.yml equivalent to "application" of Namespace. For 90% of the applications, "application" of the Namespace is already configured to meet the daily use of the scene.

3. Namespace What are the formats?

Profile available in multiple formats, such as: properties, xml, yml, yaml, json like. Similarly Namespace also has these formats. In the Portal UI you can see on the "application" of a Namespace "properties" label, indicating that the "application" are properties format.