上圖簡要描述了Apollo客戶端的實現原理：
- 客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。（通過Http Long Polling實現）
- 客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
- 這是一個fallback機制，為了防止推送機制失效導致配置不更新
- 客戶端定時拉取會上報本地版本，所以一般情況下，對於定時拉取的操作，服務端都會返回304 - Not Modified
- 定時頻率默認為每5分鍾拉取一次，客戶端也可以通過在運行時指定System Property:
apollo.refreshInterval來覆蓋，單位為分鍾。
- 客戶端從Apollo配置中心服務端獲取到應用的最新配置后，會保存在內存中
- 客戶端會把從服務端獲取到的配置在本地文件系統緩存一份
- 在遇到服務不可用，或網絡不通的時候，依然能從本地恢復配置
- 應用程序可以從Apollo客戶端獲取最新的配置、訂閱配置更新通知
Long Polling長輪詢詳解，參考地址：https://www.jianshu.com/p/d3f66b1eb748
介紹
眾所周知，數據交互有兩種模式：Push（推模式）、Pull（拉模式）。
推模式指的是客戶端與服務端建立好網絡長連接，服務方有相關數據，直接通過長連接通道推送到客戶端。其優點是及時，一旦有數據變更，客戶端立馬能感知到；另外對客戶端來說邏輯簡單，不需要關心有無數據這些邏輯處理。缺點是不知道客戶端的數據消費能力，可能導致數據積壓在客戶端，來不及處理。
拉模式指的是客戶端主動向服務端發出請求，拉取相關數據。其優點是此過程由客戶端發起請求，故不存在推模式中數據積壓的問題。缺點是可能不夠及時，對客戶端來說需要考慮數據拉取相關邏輯，何時去拉，拉的頻率怎么控制等等。
詳解
說到Long Polling（長輪詢），必然少不了提起Polling（輪詢），這都是拉模式的兩種方式。
Polling是指不管服務端數據有無更新，客戶端每隔定長時間請求拉取一次數據，可能有更新數據返回，也可能什么都沒有。
Long Polling原理也很簡單，相比Polling，客戶端發起Long Polling，此時如果服務端沒有相關數據，會hold住請求，直到服務端有相關數據，或者等待一定時間超時才會返回。返回后，客戶端又會立即再次發起下一次Long Polling。這種方式也是對拉模式的一個優化，解決了拉模式數據通知不及時，以及減少了大量的無效輪詢次數。（所謂的hold住請求指的服務端暫時不回復結果，保存相關請求，不關閉請求連接，等相關數據准備好，寫會客戶端。）
前面提到Long Polling如果當時服務端沒有需要的相關數據，此時請求會hold住，直到服務端把相關數據准備好，或者等待一定時間直到此次請求超時，這里大家是否有疑問，為什么不是一直等待到服務端數據准備好再返回，這樣也不需要再次發起下一次的Long Polling，節省資源？
主要原因是網絡傳輸層主要走的是tcp協議，tcp協議是可靠面向連接的協議，通過三次握手建立連接。但是所建立的連接是虛擬的，可能存在某段時間網絡不通，或者服務端程序非正常關閉，亦或服務端機器非正常關機，面對這些情況客戶端根本不知道服務端此時已經不能互通，還在傻傻的等服務端發數據過來，而這一等一般都是很長時間。當然tcp協議棧在實現上有保活計時器來保證的，但是等到保活計時器發現連接已經斷開需要很長時間，如果沒有專門配置過相關的tcp參數，一般需要2個小時，而且這些參數是機器操作系統層面，所以，以此方式來保活不太靠譜，故Long Polling的實現上一般是需要設置超時時間的。
實現
Long Polling的實現很簡單，可分為四個過程：
-
發起Polling
發起Polling很簡單，只需向服務器發起請求，此時服務端還未應答，所以客戶端與服務端之間一直處於連接狀態。 -
數據推送
如果服務器端有相關數據，此時服務端會將數據通過此前建立的通道發回客戶端。 -
Polling終止
Polling終止情況有三種：
若服務端返回相關數據，此時客戶端收到數據后，關閉請求連接，結束此次Polling過程。
若客戶端等待設定的超時時間后，服務端依然沒有返回數據，此時客戶端需要主動終止此次Polling請求。
若客戶端收到網絡故障或異常，此時客戶端自然也是需要主動終止此次Polling請求。 -
重新Polling
終止上次Polling后，客戶端需要立即再次發起Polling請求。這樣才能保證拉取數據的及時性。
作者：滌生YQ
鏈接：https://www.jianshu.com/p/d3f66b1eb748
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。