相较嫡系的SpringCloudConfig，为什么选择使用Apollo作为微服务的配置中心？

目录

1、SpringCloudConfig和Apollo的对比

2、apollo的介绍

3、apollo架构设计原理

4、客户端通过apollo拉取配置的原理

---

1、SpringCloudConfig和Apollo的对比

如上图对比

• SpringCloudConfig优势是对SpringBoot原生支持，且是SpringCloud组件。缺点是无界面管理，且需要git，SpringCloudBus、Mq支持其动态更新。
• Apollo优势是技术栈单一，仅需要Mysql就可以支持动态更新配置，便于维护。缺点是不是SpringCloud体系，虽然开源，版本更新也活跃，但是对SpringCloud的支持没有SpringCloudConfig的好。

---

2、apollo的介绍

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置：

• application (应用)
• environment (环境)
• cluster (集群)
• namespace (命名空间)
  同时，Apollo基于开源模式开发，开源地址

---

3、apollo架构设计原理

上图简要描述了Apollo的总体设计，我们可以从下往上看：

• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
• Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
• Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
• Client通过域名访问Meta Server获取ConfigService服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在
  Client侧会做load balance、错误重试
• Portal通过域名访问Meta Server获取AdminService服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在
  Portal侧会做load balance、错误重试
• 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

---

4、客户端通过apollo拉取配置的原理

上图简要描述了Apollo客户端的实现原理：

1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
   • 这是一个fallback机制，为了防止推送机制失效导致配置不更新
   • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
   • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份
5. 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
6. 应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

配置更新推送实现

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

• 客户端发起一个Http请求到服务端
• 服务端会保持住这个连接60秒
  • 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
  • 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
• 客户端在收到服务端请求后会立即重新发起连接，回到第一步

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