统一配置中心搭建

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客户端获取最新的配置、订阅配置更新通知

4.6.1 配置更新推送实现

前面提到了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

1.3.3 Meta Server

• 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）

1.3.5 Portal

• 提供Web界面供用户管理配置
• 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务
• 在Portal侧做load balance、错误重试

1.3.6 Client

• Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
• 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
• 在Client侧做load balance、错误重试

https://github.com/ctripcorp/apollo/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97

 

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