配置中心發展背景

隨著程序功能的日益復雜，程序的配置日益增多：

各種功能的開關、參數的配置、服務器的地址……

對程序配置的期望值也越來越高：

配置修改后實時生效，灰度發布，分環境、分集群管理配置，完善的權限、審核機制……

在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求。

Apollo客戶端設計

上圖簡要描述了Apollo客戶端的實現原理：

客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。（通過Http Long Polling實現）

客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。

這是一個fallback機制，為了防止推送機制失效導致配置不更新

客戶端定時拉取會上報本地版本，所以一般情況下，對于定時拉取的操作，服務端都會返回304 - Not Modified

定時頻率默認為每5分鐘拉取一次，客戶端也可以通過在運行時指定System Property: apollo.refreshInterval來覆蓋，單位為分鐘。

客戶端從Apollo配置中心服務端獲取到應用的最新配置后，會保存在內存中

客戶端會把從服務端獲取到的配置在本地文件系統緩存一份

在遇到服務不可用，或網絡不通的時候，依然能從本地恢復配置

應用程序從Apollo客戶端獲取最新的配置、訂閱配置更新通知

之前提到了Apollo客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。長連接實際上是通過Http Long Polling實現的，具體而言：

• 客戶端發起一個Http請求到服務端
• 服務端會保持住這個連接60秒
• 如果在60秒內有客戶端關心的配置變化，被保持住的客戶端請求會立即返回，并告知客戶端有配置變化的namespace信息，客戶端會據此拉取對應namespace的最新配置
• 如果在60秒內沒有客戶端關心的配置變化，那么會返回Http狀態碼304給客戶端
• 客戶端在收到服務端請求后會立即重新發起連接，回到第一步

考慮到會有數萬客戶端向服務端發起長連，在服務端使用了async servlet(Spring DeferredResult)來服務Http Long Polling請求。

注：DeferredResult可以允許容器線程快速釋放以便接受更多的請求提升吞吐量，讓真正的業務邏輯在其他的工作線程中完成。

在實現上，考慮到Apollo的實際使用場景，以及為了盡可能減少外部依賴，Apollo沒有采用外部的消息中間件，而是通過數據庫實現了一個簡單的消息隊列。

?

總結

以上是生活随笔為你收集整理的Apollo配置中心原理简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。