轉載自?統一配置中心的設計方案

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

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

演進中的配置

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

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

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

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

配置中心之簡版

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

配置的增刪改查

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

高性能、高可用性

請求量多、高并發

讀多寫少

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

設計說明點：

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

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

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

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

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

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

• 
  

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

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

配置中心之性能改進

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

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

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

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

配置中心之可用性改進

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

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

總結

以上是生活随笔為你收集整理的统一配置中心的设计方案的全部內容，希望文章能夠幫你解決所遇到的問題。

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