一、配置基本概念

  1. 配置是独立于程序的只读变量
  2. 配置伴随应用的整个生命周期
  3. 配置可以有多种加载方式（程序内部hard code，配置文件，环境变量，启动参数，基于数据库等）

 

二、配置治理

  1. 权限控制：由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
  2. 不同环境、集群配置管理
  3. 框架类组件配置管理

 

三、Apollo的功能特性

  1. 统一管理不同环境、不同集群配置1）Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置2）同一份代码部署在不同的集群，可以有不同的配置3）通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
  2. 配置修改实时生效（热发布）1）用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
  3. 版本发布管理1）所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
  4. 灰度发布1）支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
  5. 权限管理、发布审核、操作审计1）应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误2）所有的操作都有审计日志，可以方便地追踪问题
  6. 客户端配置信息监控1）所有的操作都有审计日志，可以方便地追踪问题
  7. 提供java和.net原生客户端
  8. 提供开放平台API
  9. 部署简单

 

四、基本工作原理

  1.  用户在配置中心对配置进行修改并发布
  2.  配置中心通知Apollo客户端有配置更新
  3.  Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

 

五、配置更新推送实现

  1. Apollo客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送
  2. 长连接实际上我们是通过Http Long Polling实现的
  3. 客户端发起一个Http请求到服务端
  4. 服务端会保持住这个连接60秒
  5. 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
  6. 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
  7. 客户端在收到服务端请求后会立即重新发起连接，回到第一步
  8. 考虑到会有数万客户端向服务端发起长连，在服务端我们使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求