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