Apollo配置更新的推送机制

上一篇 << 下一篇 >>>Apollo单机环境搭建

---

1.整体思路

1.用户在Portal操作配置发布
2.Portal调用Admin Service的接口操作发布
3.Admin Service发布配置后，发送ReleaseMessage给各个Config Service
4.Config Service收到ReleaseMessage后，通知对应的客户端

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

• 客户端发起一个Http请求到服务端
• 服务端会保持住这个连接60秒
• 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
• 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
• 客户端在收到服务端请求后会立即重新发起连接，回到第一步
  考虑到会有数万客户端向服务端发起长连，在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。

2.ReleaseMessage实现方式

1.Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace，参见DatabaseMessageSender
2.Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录，参见ReleaseMessageScanner
3.Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器（ReleaseMessageListener），如NotificationControllerV2，消息监听器的注册过程参见ConfigServiceAutoConfiguration
4.NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端

3.Config Service通知客户端的实现方式

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

---

推荐阅读：
<<<传统配置的缺陷与常用分布式配置中心介绍
<< << << << << << << << << << << << << << << << <<