引言
配置中心在微服務架構體系中是非常重要的基礎設施服務，承擔著分散式配置集中管理、配置熱釋出以及審計等重要的職責。本文主要探討Apollo配置中心的配置熱釋出特性如何實現。
配置熱釋出如何實現
1、配置釋出主流程
如上圖所示，配置釋出的主流程如下：
（1）使用者透過Portal向AdminService釋出配置資訊；
（2）AdminService在配置釋出後會往ReleaseMessage表插入一條訊息記錄；
（3）ConfigService中包含了一個定時執行緒，該定時執行緒每秒掃描一次ReleaseMessage表，檢查表中是否有新的訊息記錄；
（4）如果存在配置更新，ConfigService就會通知所有的訊息監聽器；
（5）通知Controller會根據釋出的配置資訊通知對應的客戶端；
客戶端與配置中心的大致互動如下所示:
這裡的配置更新推送其實並不是真正進行資訊推送，而是透過長輪詢來實現配置的更新。實際上並不是配置的更新推送，而是配置更新通知的推送，客戶端拿到通知後需要進一步獲取具體的變化的配置資訊。
2、長輪詢
（1）如果使用Push方式推送資料會有什麼問題？
服務端需要與客戶端建立長連線，服務端有資料更新的時候可以進行資料推送，資料更新比較及時。但是服務端無法感知客戶端的處理能力，可能會造成資料積壓。另外叢集情況下部分節點不線上會通知失敗，等客戶端又線上後需要進行補償推送，節點還有可能存在擴容等各種情況。對於配置中心這種業務場景來說，透過Push方式實現資料推動顯得複雜了。
（2）如果使用Pull方式拉取資料會有什麼問題？
Pull模式主要是透過客戶端主動向配置中心進行資料請求，拉取對應的配置資訊。由於是客戶端主動拉取，因此不會出現資料堆積的問題。但是資料如何去拉，什麼時間去拉，拉的頻率如何控制，這些都是問題。如果頻率過高，而配置並未更新，那麼就會對服務端造成不必要的連線壓力。如果頻率過低，那麼配置更新就會存在延時的問題。因此同樣不適合配置中心的業務場景。
（3）長輪詢
客戶端向配置中心進行請求，配置中心不會立即返回響應，而是會hold住這個請求直到指定時間超時後進行返回。如果沒有配置變更，則返回Http狀態碼304給客戶端。超時返回後，客戶端將再次發起請求。
如果存在配置變更，將返回對應的namespace資訊，客戶端根據namespace資訊獲取對應的配置資訊。
另外為了保證配置的有效性，客戶端也會定時請求配置資訊，防止配置更新可能出現的異常情況，是一種資料保證的兜底fallback機制。另外當獲取到配置後，會同步到本地配置檔案中 。這樣即便客戶端與配置中心無法通訊，客戶端也可以從本地配置檔案中獲取配置資訊。
那麼問題來了，為什麼不直接在長輪詢的響應中直接回復配置資訊呢？主要是由於本身已經存在了定時拉取配置的步驟，那麼為了保證單一原則以及程式碼上的簡潔以及複用。所以透過這種獲取配置更新後再進行資料拉取的方式。
3、客戶端獲取配置資訊
我們一起看下客戶端如何工作流程，如下圖：
（1）ConfigServiceLocator：主要負責向Eruka註冊中心獲取ConfigService地址列表資訊；
（2）RemoteConfigLongPollService：從ConfigServiceLocator獲取到地址列表資訊後，透過長輪詢的方式獲取配置變更資訊；
（3）RemoteConfigReposity：從ConfigService獲取變更的配置資料；
（4）LocalFileConfigReposity：把配置資料固化到本地，同時作為本地配置資料的來源；
（5）DefaultConfig：主要和業務方進行互動，提供配置獲取方法，同時可以註冊配置變更事件。
總結
本文主要探討了Apollo配置中心配置熱釋出的相關內容，分析了為什麼長輪詢是比較適合配置中心的資料互動方式。在今後的架構設計中我們也可以以此來作為參考。另外客戶端的設計中，也體現了了分層以及職責單一的程式碼風格，我們自己在實際專案開發中也比較有借鑑的意義
————————————————————————————————————————————————
©著作權歸作者所有：來自51CTO部落格作者慕楓技術筆記的原創作品，請聯絡作者獲取轉載授權，否則將追究法律責任
Apollo配置中心如何實現配置熱釋出
https://blog.51cto.com/u_15474618/4905554
————————————————————————————————————————————————
可參考：
微服務架構~攜程Apollo配置中心架構剖析
官方文件