类似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请求。

三、架构

整体架构：

在这里插入图片描述

四大板块：

ConfigService

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

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

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

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

三个辅助服务发现模块

Eureka

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

Portal通过域名访问MetaServer获取AdminService的地址列表
Client通过域名访问MetaServer获取ConfigService的地址列表
相当于一个Eureka Proxy
逻辑角色，和ConfigService住在一起部署
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等的主要原因，为了提高配置中心的可用性和降低部署复杂度，我们需要尽可能地减少外部依赖。