Apollo源码学习（二）服务端/客户端设计

一、服务端设计（实时推送配置）

1、配置发布实现流程

• （1）用户在Portal操作配置并且发布
• （2）Portal调用Admin Service接口发布配置
• （3）Admin Service发布配置后，发送Release Message给各个Config Service
• （4）Config Service收到Release Message后，通知对应客户端

2、ReleaseMessage消息实现方式

是一个简单的消息使用场景，但为减少外部依赖，不使用外部的消息中间件，通过数据库实现了一个简单的消息队列

• （1）Admin Service在配置发布后往ReleaseMessage表格插入一条消息记录，消息内容为【AppId + Cluster + Namespace】
• （2）Config Service中的一个线程每秒钟扫描ReleaseMessage表一次，检测是否有新消息记录。
• （3）Config Service如果发现有新消息记录，则会通知所有的消息监听器（如 NotificationControllerV2）
• （4）NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端

3、Config Service通知客户端方式

NotificationControllerV2在获取到配置发布之后，通知客户端的流程如下：

• （1）客户端会发起一个Http请求到Config Service的notificationcontroller/v2接口，也就是NotificationControllerV2
• （2）NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
• （3）如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端
• （4）如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置

二、客户端设计（实时获取配置）

1、实时获取配置原理

• （1）客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）

• （2）客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

  • 这是一个fallback机制，为了防止推送机制失效导致配置不更新
  • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
  • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。

• （3）客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

• （4）客户端会把从服务端获取到的配置在本地文件系统缓存一份

  • 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置

• （5）应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

2、客户端和Spring集成

Apollo除了支持API方式获取配置，也支持和Spring/Spring Boot集成，集成原理简述如下。

Spring从3.1版本开始增加了ConfigurableEnvironment和PropertySource：

• ConfigurableEnvironment
  • Spring的ApplicationContext会包含一个Environment（实现ConfigurableEnvironment接口）
  • ConfigurableEnvironment自身包含了很多个PropertySource
• PropertySource
  • 属性源
  • 可以理解为很多个Key - Value的属性配置
    
    注意：PropertySource之间是有优先级顺序的，如果有一个Key在多个property source中都存在，那么在前面的property source优先

所以，Apollo和Spring/Spring Boot集成就是：在应用启动阶段Apollo从远端获取配置并且组装成为PropertySource插到第一个