設計實現
在配置中心中，一個重要的功能就是配置發布后實時推送到客戶端。
上圖簡要描述了配置發布的主要過程：
1. 用戶在Portal操作配置發布
2. Portal調用Admin Service的接口操作發布
3. Admin Service發布配置后，發送ReleaseMessage給各個Config Service
4. Config Service收到ReleaseMessage后，通知對應的客戶端
發送ReleaseMessage
Admin Service在配置發布后，需要通知所有的Config Service有配置發布，從而Config Service可以通知對應的客
戶端來拉取最新的配置。
從概念上來看，這是一個典型的消息使用場景，Admin Service作為producer（生產者）發出消息，各個Config
Service作為consumer（消費者）消費消息。通過一個消息隊列組件（Message Queue）就能很好的實現Admin
Service和Config Service的解耦。
在實現上，考慮到Apollo的實際使用場景，以及為了盡可能減少外部依賴，我們沒有采用外部的消息中間件，而是
通過數據庫實現了一個簡單的消息隊列。
具體實現方式如下：
1. Admin Service在配置發布后會往ReleaseMessage表插入一條消息記錄，消息內容就是配置發布的
AppId+Cluster+Namespace
1 消息發送類
Config Service有一個線程會每秒掃描一次ReleaseMessage表，看看是否有新的消息記錄
2 消息掃描類：ReleaseMessageScanner
3. Config Service如果發現有新的消息記錄，那么就會通知到所有的消息監聽器
然后調用消息監聽類的handleMessage方法：NotificationControllerV2
4. NotificationControllerV2得到配置發布的AppId+Cluster+Namespace后，會通知對應的客戶端
Config Service通知客戶端
上一節中簡要描述了NotificationControllerV2是如何得知有配置發布的，那NotificationControllerV2在得知有配
置發布后是如何通知到客戶端的呢？
實現方式如下：
1. 客戶端會發起一個Http請求到Config Service的 notifications/v2 接口NotificationControllerV2
客戶端發送請求類：RemoteConfigLongPollService
2. NotificationControllerV2不會立即返回結果，而是把請求掛起。考慮到會有數萬客戶端向服務端發起長連，
因此在服務端使用了async servlet(Spring DeferredResult)來服務Http Long Polling請求。
3. 如果在60秒內沒有該客戶端關心的配置發布，那么會返回Http狀態碼304給客戶端。
4. 如果有該客戶端關心的配置發布，NotificationControllerV2會調用DeferredResult的setResult方法，傳入有
配置變化的namespace信息，同時該請求會立即返回。客戶端從返回的結果中獲取到配置變化的namespace
后，會立即請求Config Service獲取該namespace的最新配置
客戶端讀取設計
除了之前介紹的客戶端和服務端保持一個長連接，從而能第一時間獲得配置更新的推送外，客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
1 這是一個備用機制，為了防止推送機制失效導致配置不更新
2 客戶端定時拉取會上報本地版本，所以一般情況下，對於定時拉取的操作，服務端都會返回304 - NotModified
3 定時頻率默認為每5分鍾拉取一次，客戶端也可以通過在運行時指定System Property:apollo.refreshInterval 來覆蓋，單位為分鍾