前言
Apollo是當下較爲火熱的配置中心，顧名思義自然是管理配置的，那麼它是如何獲取配置的呢？本文會簡單介紹相關機制，很多東西自然解釋得不到位，後續會有單獨章節深追源碼看具體實現的。
配置獲取方式
Apollo有兩種方式獲取配置：
1)客戶端定時請求Config Service的配置讀取接口；
2)客戶端長輪詢Config Service的配置變更通知接口，當客戶端收到變更通知之後會立即輪詢Config Service的配置讀取接口。
關鍵核心類
- com.ctrip.framework.apollo.internals.RemoteConfigRepository ：實現AbstractConfigRepository抽象類，遠程配置Repository。實現從Config Service拉取配置，並緩存在內存中。並且定時+實時刷新緩存。
- com.ctrip.framework.apollo.internals.RemoteConfigLongPollService ：長輪詢的核心類，就是拼接URL請求Config Service的notifications/v2接口，等待獲取配置更新通知。
- com.ctrip.framework.apollo.biz.message.ReleaseMessageScanner ：客戶端感知配置發生變化的核心類。
客戶端如何感知配置變化？
- Admin Service在配置發佈後會往ReleaseMessage表插入一條消息記錄；
- Config Service會啓動一個線程定時掃描ReleaseMessage表（默認是1秒）查看是否有新的消息記錄；
- Config Service發現有新的消息記錄，就會通知到所有的消息監聽器；
- 消息監聽器得到配置發佈的消息後，就會通知對應的客戶端。（之後就是客戶端主動去拉取配置了）
Config Service如何通知客戶端？
通知採用基於Http長連接實現，主要分爲以下幾個步驟：
- 客戶端會發起Http請求到Config Service的notifications/v2接口；
- notifications/v2接口通過Spring DeferredResult把請求掛起，不會立即返回；
- 如果在60秒內沒有該客戶端關心的配置發佈，那麼會返回Http狀態碼304給客戶端；
- 如果發現配置有修改，則會調用DeferredResult的setResult方法，傳入有配置變化的namespace信息，同時該請求會立即返回;
- 客戶端從返回結果中獲取到配置變化的namespace後，會立即請求Config Service獲取該namespace的最新配置。
總結
咱們知道Apollo有專屬的數據庫：ApolloPortalDB、ApolloConfigDB，所以數據都是放在這些庫裏的，自然包括配置信息。所以無非就是新增配置信息（發佈）的時候，某表有新數據，與此同時客戶端定時去掃描查看這張表看看有沒有更新，如果有更新那麼就通知客戶端，告訴客戶端哪個namespace的配置更新了，然後客戶端再去主動調用拉去配置的接口獲取新的配置；當然這保證的實時性，期間可能會發生各種問題導致配置有問題，咱們客戶端還有一種拉取配置的方式那就是每5分鐘也會主動調用拉取配置的接口獲取配置，這樣就保證了配置的數據一致性。不得不提的是，Apollo還有本地文件緩存和內存緩存（默認不開啓），這就保證了Apollo服務不可用的時候短時間內也不會影響到客戶端（因爲客戶端依舊可以從緩存中讀取配置），設計非常的嚴謹與優秀！
知識Tip
上文中提到的DeferredResult，可能有的小夥伴沒有接觸過。我在這裏簡單地舉個例子，希望你能明白~
類似於，你去超市買一樣東西，但是此時這東西沒貨，那麼你留個電話給服務員，自己去做別的事情了，而服務員會不停地問倉庫有沒有貨了，當有貨的時候他會打電話告訴你（類似調用setResult方法)，這時候你就會屁顛屁顛地拿着貨走了。（比喻可能不夠恰當和嚴謹，但是一般精闢就行，希望你能領悟~)
用正式一點的技術用語來描述呢就是，DeferredResult：當一個請求到達API接口，如果該API接口的return返回值是DeferredResult，在沒有超時或者DeferredResult對象設置setResult時，接口不會返回但是Servlet容器線程會結束DeferredResult另起線程來進行結果處理（即這種操作提升了服務短時間的吞吐能力）。如此一來，這個請求不會佔用服務連接池太久，如果超時或者setResult，接口會立即返回。