apollo
4.5.1 Why Eureka
为什么我们采用Eureka作为服务注册中心,而不是使用传统的zk、etcd呢?我大致总结了一下,有以下几方面的原因:
· 它提供了完整的Service Registry和Service Discovery实现
· 首先是提供了完整的实现,并且也经受住了Netflix自己的生产环境考验,相对使用起来会比较省心。
· 和SpringCloud无缝集成
· 我们的项目本身就使用了Spring Cloud和Spring Boot,同时Spring Cloud还有一套非常完善的开源代码来整合Eureka,所以使用起来非常方便。
· 另外,Eureka还支持在我们应用自身的容器中启动,也就是说我们的应用启动完之后,既充当了Eureka的角色,同时也是服务的提供者。这样就极大的提高了服务的可用性。
· 这一点是我们选择Eureka而不是zk、etcd等的主要原因,为了提高配置中心的可用性和降低部署复杂度,我们需要尽可能地减少外部依赖。
· Open Source
· 最后一点是开源,由于代码是开源的,所以非常便于我们了解它的实现原理和排查问题。
上图简要描述了Apollo客户端的实现原理:
1. 客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。
2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
1. 这是一个fallback机制,为了防止推送机制失效导致配置不更新
2. 客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回304 - Not Modified
3. 定时频率默认为每5分钟拉取一次,客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖,单位为分钟。
3. 客户端从Apollo配置中心服务端获取到应用的最新配置后,会保存在内存中
4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份
0. 在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置
5. 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
前面提到了Apollo客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。
长连接实际上我们是通过Http Long Polling实现的,具体而言:
· 客户端发起一个Http请求到服务端
· 服务端会保持住这个连接30秒
· 如果在30秒内有客户端关心的配置变化,被保持住的客户端请求会立即返回,并告知客户端有配置变化的namespace信息,客户端会据此拉取对应namespace的最新配置
· 如果在30秒内没有客户端关心的配置变化,那么会返回Http状态码304给客户端
· 客户端在服务端请求返回后会自动重连
考虑到会有数万客户端向服务端发起长连,在服务端我们使用了async servlet(Spring DeferredResult)来服务HttpLong Polling请求。
4.7 可用性考虑
配置中心作为基础服务,可用性要求非常高,下面的表格描述了不同场景下Apollo的可用性:
场景 |
影响 |
降级 |
原因 |
某台config service下线 |
无影响 |
|
Config service无状态,客户端重连其它config service |
所有config service下线 |
客户端无法读取最新配置,Portal无影响 |
客户端重启时,可以读取本地缓存配置文件 |
|
某台admin service下线 |
无影响 |
|
Admin service无状态,Portal重连其它admin service |
所有admin service下线 |
客户端无影响,portal无法更新配置 |
|
|
某台portal下线 |
无影响 |
|
Portal域名通过slb绑定多台服务器,重试后指向可用的服务器 |
全部portal下线 |
客户端无影响,portal无法更新配置 |
|
|
某个数据中心下线 |
无影响 |
|
多数据中心部署,数据完全同步,Meta Server/Portal域名通过slb自动切换到其它存活的数据中心 |
1.3.2 Admin Service
- 提供配置管理接口
- 提供配置修改、发布等接口
- 接口服务对象为Portal
- Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port)
- Client通过域名访问Meta Server获取Config Service服务列表(IP+Port)
- Meta Server从Eureka获取Config Service和Admin Service的服务信息,相当于是一个Eureka Client
- 增设一个Meta Server的角色主要是为了封装服务发现的细节,对Portal和Client而言,永远通过一个Http接口获取Admin Service和Config Service的服务信息,而不需要关心背后实际的服务注册和发现组件
- Meta Server只是一个逻辑角色,在部署时和Config Service是在一个JVM进程中的
1.3.4 Eureka
- 基于Eureka和Spring Cloud Netflix提供服务注册和发现
- Config Service和Admin Service会向Eureka注册服务,并保持心跳
- 为了简单起见,目前Eureka在部署时和Config Service是在一个JVM进程中的(通过Spring Cloud Netflix)
- 提供Web界面供用户管理配置
- 通过Meta Server获取Admin Service服务列表(IP+Port),通过IP+Port访问服务
- 在Portal侧做load balance、错误重试
- Apollo提供的客户端程序,为应用提供配置获取、实时更新等功能
- 通过Meta Server获取Config Service服务列表(IP+Port),通过IP+Port访问服务
- 在Client侧做load balance、错误重试
Apollo目前支持以下环境:
- DEV
- 开发环境
- FAT
- 测试环境,相当于alpha环境(功能测试)
- UAT
- 集成环境,相当于beta环境(回归测试)
- PRO
- 生产环境
- Portal部署在生产环境的机房,通过它来直接管理FAT、UAT、PRO等环境的配置
- Meta Server、Config Service和Admin Service在每个环境都单独部署,使用独立的数据库
- Meta Server、Config Service和Admin Service在生产环境部署在两个机房,实现双活
- Meta Server和Config Service部署在同一个JVM进程内,Admin Service部署在同一台服务器的另一个JVM进程内
10.82.12.136:5601