之前聊了客戶端的一些功能，例如融入 spring， @value 註解的自動重新整理實現，長輪詢等，這次從客戶端的整體設計來聊聊。
上圖是 client 專案的包結構。
其中，核心包就是 internals 包，包含了客戶端的主要功能邏輯。主要有以下功能： 0. 獲取 configservice 服務的遠端配置。
長輪詢/定時輪詢 configservice。
監聽機制——更新後，立即通知應用程式。
相容 spring 各個版本（這個是在 spring 包中，但我認為也算重要功能^_^）。
首先說第乙個功能：獲取 configservice 服務的遠端配置：
實現此功能的類為：remoteconfigrepository。該類有以下幾個重要的方法：
構造方法：該方法裡包含了很多初始化的過程，雖然我覺得應該放在 init 之類的方法中
getconfig() 根據 namespace 獲取配置
onlongpollnotified() 當收到長連線通知時觸發響應
addchangelistener() 新增***
removechangelistener() 刪除***
注意：setupstreamrepository 是空的。看注釋，是個 fallback 設計。
其中，getconfig 方法是獲取這個 namespace 的配置，返回的是 properties 物件（就是個 map）。然後，從這個物件中取出對應的值，就 ok 了。
第二個功能：長輪詢/定時輪詢 configservice。
這個功能的主要實現類是：remoteconfiglongpollservice。
每乙個 namespace 在乙個應用中，都對應乙個 remoteconfigrepository，所有的 remoteconfigrepository 都歸屬 remoteconfiglongpollservice 長輪詢服務管理，當長輪詢得到通知，便通知對應的 remoteconfigrepository 進行服務請求以便執行更新本地快取和通知***操作。
通知，作為 fallback 方案—— 定時輪詢也充當了長輪詢失效的最後屏障。
第三個功能：監聽機制——更新後，立即通知應用程式。
從上圖可以看出，輪詢之後，如果有更新響應，則立即通知 remoteconfigrepository，然後，remoteconfigrepository 再次從配置中心拉取配置，從而更新本地 config 物件的內容。
更新完畢後，則通知 config 的「配置變化***」。也就是 configchangelistener 的 onchange 方法。這個***是監聽 config 物件的。
實際上，每個 config 物件在初始化的時候，都會往 remoteconfigrepository 物件裡新增乙個***，實際上就是新增自己。
當 remoteconfigrepository 發生變化的時候，觸發 onrepositorychange 方法，onrepositorychange 又會觸發 onchange 方法。大概的設計圖就是下面這個樣子：
上圖中，紫色的 defaultconfig 是核心，他依賴了 remoteconfigrepository， 而 remoteconfigrepository 反過來組合了他，同時 defaultconfig 也聚合了使用者實現的*** configchangelistener 的子類。
那麼，當遠端 repository 變化的時候，就可以通知 client 的快取 config 物件，而 config 快取物件變化的時候，就可以通知使用者的程式（***）。實現整體的監聽機制。
總的來說，就是通過兩層監聽機制來實現的。其中 defaultconfig 實現了兩個角色，既是觀察者，也是被觀察者。
第四個功能：相容 spring 各個版本
首先，如果沒有這個功能，apollo 也會能夠正常執行的，不過，你只能使用 api 的方式，不能使用註解，標籤等 spring 應用熟悉的方式。
如果想用 spring 的方式使用 apollo ，那麼就得遵守 spring 的約定，實現 spring 的介面，將自己融入到 spring 中。
其中，主要解決的問題就是，如何在 spring 初始化的時候，apollo 也初始化？這點我們在之前的文章中說了，也就是 spring 的 3 個入口。在這些入口裡初始化。
另外，將配置放置到 spring 的環境中，也是乙個工作，因為，如果不放到環境中，spring 初始時需要的那些引數就無法取到了。
所以，要將 config 物件包裝成 spring 熟悉的 configpropertysource 物件，算是乙個介面卡模式吧。
在初始化配置的時候，會從遠端配置中心拿到配置，包裝成 configpropertysource 物件，再利用 compositepropertysource 組合屬性配置（多個 namespace）聚合所有 config 物件。
compositepropertysource 最後會新增到 configurableenvironment 環境物件中，spring 就可以從這個物件 中取出配置進行初始化。
並且，在 springboot 環境下，apollo 可以優先載入指定的配置，這些配置在 springcontext 容器初始化的時候就開始被注入到環境中，這樣就可以將一些系統初始化的配置也放到配置中心了，盡量讓本地少一點配置。這個功能的啟用需要引數：apollo.bootstrap.enabled=true，配置的namespace 則是apollo.bootstrap.namespaces = ***。
並且，該配置的優先順序是最高的，apollo 將這個配置放在了 spring 環境物件中的第乙個位置，當迴圈獲取配置的時候，優先獲取這個配置。
好了，關於 apollo 客戶端的設計，大概就是這些，總體來講比較簡單， 4 個功能：
獲取遠端配置
長輪詢/定時輪詢
配置更新監聽機制。
相容 spring。
丟擲乙個問題：
apollo 似乎沒有給使用者留擴充套件介面？如果能像 spring，mybatis 一樣，留乙個或者多個切面給使用者，讓使用者能夠在載入配置的時候，做一些事情啥的，或許更好。
Python版apollo客戶端
python apollo客戶端封裝 介面自動化專案有場景需要呼叫公司內部的apollo，但是網上搜尋了一遍，沒有發現有很好用的python客戶端，有些只能查，不能改 有些能改但不支援token傳入。所以自己通過官方的介面文件做了個客戶端的封裝，並且支援二次開發 python3.x 獲取apollo...
客戶端SDK測試思路
網易雲社群 客戶端sdk是為第三方開發者提供的軟體開發工具包，包括sdk介面 開發文件和demo示例等。sdk和應用之間是什麼關係呢？以雲信即時訊息服務為例，如下圖所示，應用客戶端通過呼叫雲信sdk介面，進行訊息等資料查詢儲存等操作，或通過協議與雲信伺服器間進行通訊。1.客戶端sdk測試的物件 客戶...
客戶端防重放設計
客戶端通道早在1.1版本中便實現了伺服器防重放攻擊功能，但始終沒有實現客戶端防重放攻擊。這樣會使得客戶端存在被重放攻擊的危險，如使用者在轉賬時被重放了轉賬失敗頁面，導致使用者重複轉賬。為此，我們需要在客戶端通道中實現客戶端防重放功能。我們需要實現以下需求 在伺服器響應中增加序列號，實現客戶端防重放功...