分布式配置中心 Apollo

---

类似Lion

一、Apollo客户端实现原理

1、客户端和服务端会保持一个长连接，从而第一时间获取配置更新的推送。
2、客户端还会定时从Apollo配置中心服务端拉取应用的最新配置，而且客户端定时拉取会上报给本地版本，默认每隔5分钟拉取一次，也可以通过运行时指定apollo.refreshInterval来覆盖，单位为分钟。
3、客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存。
4、客户端会把从服务端拉取到的配置在本地文件系统缓存一份，保证在遇到服务不可用或网路故障时，依赖能从本地恢复配置，也实现了一定的高可用性。应用程序从客户端获取到罪行的配置、订阅配置更新通知。

二、配置更新实现

前面提到了Apollo客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
长连接实际上我们是通过Http Long Polling实现的，具体而言：

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


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


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


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


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

考虑到会有数万客户端向服务端发起长连，在服务端我们使用了async servlet(Spring DeferredResult)来服务HttpLong Polling请求。

三、架构

整体架构：

四大板块 ：

1. ConfigService

   提供配置获取接口
   提供配置推送接口
   服务于Apollo客户端

2. AdminService

   提供配置管理接口
   提供配置修改发布接口
   服务于管理界面Portal

3. Client

   为应用获取配置，支持实时更新
   通过MetaServer获取ConfigService的服务列表
   使用客户端软负载SLB方式调用ConfigService

4. Portal

   配置管理界面
   通过MetaServer获取AdminService的服务列表
   使用客户端软负载SLB方式调用AdminService

三个辅助服务发现模块

1. Eureka

   用于服务发现和注册
   Config/AdminService注册实例并定期报心跳
   和ConfigService住在一起部署

2. MetaServer

   Portal通过域名访问MetaServer获取AdminService的地址列表
   Client通过域名访问MetaServer获取ConfigService的地址列表
   相当于一个Eureka Proxy
   逻辑角色，和ConfigService住在一起部署

3. NginxLB

   和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表
   和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表
   和域名系统配合，协助用户访问Portal进行配置管理

Why Eureka

为什么我们采用Eureka作为服务注册中心，而不是使用传统的zk、etcd呢？我大致总结了一下，有以下几方面的原因：

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

首先是提供了完整的实现，并且也经受住了Netflix自己的生产环境考验，相对使用起来会比较省心。

    和Spring Cloud无缝集成

1）我们的项目本身就使用了Spring Cloud和Spring Boot，同时Spring Cloud还有一套非常完善的开源代码来整合Eureka，所以使用起来非常方便。
2）另外，Eureka还支持在我们应用自身的容器中启动，也就是说我们的应用启动完之后，既充当了Eureka的角色，同时也是服务的提供者。这样就极大的提高了服务的可用性。
3）这一点是我们选择Eureka而不是zk、etcd等的主要原因，为了提高配置中心的可用性和降低部署复杂度，我们需要尽可能地减少外部依赖。

    Open Source

最后一点是开源，由于代码是开源的，所以非常便于我们了解它的实现原理和排查问题。