Distributed Configuration Center Apollo

---

Similar to Lion

1. Implementation principle of Apollo client

1. The client and server will maintain a long connection, so as to obtain the push of configuration updates at the first time.
2. The client will also regularly pull the latest configuration of the application from the Apollo configuration center server, and the client will report to the local version when it pulls regularly. By default, it pulls once every 5 minutes. You can also specify apollo.refreshInterval at runtime to cover, in minutes.
3. After the client obtains the latest configuration of the application from the Apollo configuration center server, it will be saved in memory.
4. The client will cache a copy of the configuration pulled from the server in the local file system to ensure that in the event of service unavailability or network failure, the configuration can be restored locally and high availability is achieved. The application obtains the crime configuration from the client and subscribes to configuration update notifications.

2. Implementation of configuration update

As mentioned earlier, the Apollo client and server maintain a long connection, so that they can get the push of configuration updates at the first time.
Long connection is actually implemented by Http Long Polling, specifically:

    客户端发起一个Http请求到服务端


    服务端会保持住这个连接30秒


    如果在30秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置


    如果在30秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端


    客户端在服务端请求返回后会自动重连

Considering that tens of thousands of clients will initiate long connections to the server, we use async servlet (Spring DeferredResult) to serve HttpLong Polling requests on the server.

3. Structure

Overall structure :

Four major sectors:

1. ConfigService

   Provide configuration acquisition interface
   Provide configuration push interface
   Serve Apollo client

2. AdminService

   Provide configuration management interface
   Provide configuration modification release interface
   Serve management interface Portal

3. Client

   Obtain configuration for the application and support real-time update
   Obtain the service list of ConfigService through MetaServer
   Use client-side soft load SLB to call ConfigService

4. Portal

   Configure the management interface
   Obtain the AdminService service list through MetaServer
   Use the client soft load SLB method to call AdminService

Three auxiliary service discovery modules

1. Eureka

   Used for service discovery and registration
   Config/AdminService registration instance and regular heartbeat report
   Live and deploy with ConfigService

2. MetaServer

   Portal accesses MetaServer through the domain name to obtain the address list of AdminService.
   Client accesses MetaServer through the domain name to obtain the address list of ConfigService.
   It is equivalent to a
   logical role of Eureka Proxy and lives and deploys with ConfigService.

3. NginxLB

   Cooperate with Domain Name System, assist Portal to access MetaServer to obtain AdminService address list
   Cooperate with Domain Name System, assist Client to access MetaServer to obtain ConfigService address list
   Cooperate with Domain Name System, assist users to access Portal for configuration management

Why Eureka

Why do we use Eureka as a service registry instead of traditional zk and etcd? I roughly summed it up, there are the following reasons:

    它提供了完整的Service Registry和Service Discovery实现

First of all, it provides a complete implementation, and has also withstood the test of Netflix's own production environment, which is relatively worry-free to use.

    和Spring Cloud无缝集成

1) Our project itself uses Spring Cloud and Spring Boot, and Spring Cloud also has a very complete set of open source code to integrate Eureka, so it is very convenient to use.
2) In addition, Eureka also supports starting in our application's own container, that is to say, after our application is started, it not only acts as Eureka, but also serves as a service provider. This greatly improves the availability of the service.
3) This is the main reason why we choose Eureka instead of zk, etcd, etc. In order to improve the availability of the configuration center and reduce the complexity of deployment, we need to reduce external dependencies as much as possible.

    Open Source

The last point is open source. Since the code is open source, it is very convenient for us to understand its implementation principle and troubleshoot problems.