- （1）用户在Portal操作配置并且发布
- （2）Portal调用Admin Service接口发布配置
- （3）Admin Service发布配置后，发送Release Message给各个Config Service
- （4）Config Service收到Release Message后，通知对应客户端
是一个简单的消息使用场景，但为减少外部依赖，不使用外部的消息中间件，通过数据库实现了一个简单的消息队列
- （1）Admin Service在配置发布后往ReleaseMessage表格插入一条消息记录，消息内容为【AppId + Cluster + Namespace】
- （2）Config Service中的一个线程每秒钟扫描ReleaseMessage表一次，检测是否有新消息记录。
- （3）Config Service如果发现有新消息记录，则会通知所有的消息监听器（如 NotificationControllerV2）
- （4）NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端
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）客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
-
（2）客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
- 这是一个fallback机制，为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
- 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
-
（3）客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
-
（4）客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
-
（5）应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
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插到第一个
