對於配置文件，我們不陌生，它提供我們可以動態修改程序運行能力。引用別人的一句話就是：系統運行時(runtime)飛行姿態的動態調整。

我可以把我們的工作稱之為在快速飛行的飛機上修理零件。我們人類總是無法掌控和預知一切。對於我們系統來說，我們總是需要預留一些控制線條，以便在我們需要的時候做出調整，控制系統方向（如灰度控制、限流調整），這對於擁抱變化的互聯網行業尤為重要。對於單機版，我們稱之為配置（文件），對於分佈式集群系統，我們稱之為配置中心（系統）;下面聊聊我們的配置中心。

演進中的配置

當我們是一個單機服務的是，我們的配置通常寫在一個文件中的，代碼發佈的時候，把配置文件和程序推送到機器上去。

當隨著業務的用戶量增加，通常我們會把我們的服務進行多機器（集群）部署。這時候，配置的發佈就變成了如下：

業務的急劇擴張，導致單機服務無法滿業務需求。這時候需要對單體大服務進行切開，服務走向SOA(微服務化)。

這種場景中，配置文件的部署可能如上圖所示。這樣去部署配置簡直是一場噩夢，而且無法做到快速的動態的調整。失去了配置主要意義之一。這時候就需要今天說的統一配置中心。

配置中心之簡版

首先來看下我們理想中的配置中心需要具備哪些特點。

配置的增刪改查

不同環境配置隔離（開發、測試、預發佈、灰度/線上）

高性能、高可用性

請求量多、高併發

讀多寫少

我們可以設計出如下的簡版配置中心

設計說明點：

• 通過OA系統對每一條配置（每一個配置有唯一的配置ID）進行增刪改查。

• 區分不同環境的配置，每個環境同一配置ID對應不同數據庫記錄。

• 配置最終以json格式（便於編輯和理解）儲存在mysql數據庫中。

• 引入redis集群，做配置的緩存（比如可以設置配置修改後1分鐘後生效）

• 配置對外服務，多機器部署，滿足性能需要。

• 如果有必要，可以引入配置歷史修改記錄。

很多時候，這樣可以基本上滿足我們對配置系統的基本需求。

這種設計，由於所有的配置都存放在集中式緩存中，這樣集中式的緩存也會有他的性能瓶頸。而且，每次配置的訪問都需要發起rpc請求(網絡請求)，因此考慮在客戶端引入本地緩存的選擇及其原理（localCache，例如Ehcache）。

配置中心之性能改進

為了提高配置中心的可用性，減少網絡請求等因素對性能帶來的影響，我們考慮在客戶端引入localcache，來解決系統的高可用，高性能、可伸縮性。

相對於第一版的改進點是，在客戶端引入localcache。開啟線程異步調用配置服務，更新本地配置。這樣可以減少rpc調用。

這種方式較為簡單，但是存在一個問題，就是一旦用戶量大的時候，會增加很多無意義的輪詢。因為配置中心的定位就表明了他的修改並不會很多，所以大多數情況下的輪詢都是無意義的。會給緩存系統增加很多無謂的壓力。

同時，由於各個客戶端的拉取時間及網絡延遲等都不盡相同，也會存在數據一致性的問題，

配置中心之可用性改進

還好，配置通常都只會有一個入口修改，因此可以考慮在配置修改後，通知應用服務清理本地緩存和分佈式緩存。這裡可以引入mq或ZooKeeper。

感興趣的朋友可以瞭解下阿里巴巴的Diamond，他的工作原理就是這種通過推拉結合的方式，減少不必要的輪詢，並且可以降低緩存系統的負載。