【180425】統一配置中心

對於配置文件，咱們不陌生，它提供咱們能夠動態修改程序運行能力。引用別人的一句話就是：

系統運行時(runtime)飛行姿態的動態調整

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

他山之石

• 配置中心Lion：yeming.me/2017/11/27/…
• Apollo配置中心介紹：github.com/ctripcorp/a…
• QConf搭建配置中心：segmentfault.com/a/119000000…
• 動態調整的基礎 —— 配置中心：pingguohe.net/2016/03/18/…
• 一篇好TM長的關於配置中心的文章：jm.taobao.org/2016/09/28/…

演進中的配置

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

當隨着業務的用戶量增長，一般咱們會把咱們的服務進行多機器（集羣）部署。這時候，配置的發佈就變成了以下：

行，這樣發配置也能接受 業務的急劇擴張，致使單機服務沒法滿業務需求。這時候須要對單體大服務進行切開，服務走向SOA(微服務化)。

這樣去部署配置簡直是一場噩夢，並且沒法作到快速的動態的調整。失去了配置主要意義之一。這時候就須要今天說的統一配置中心。

配置中心之簡版

配置中心的特色

• 配置的增刪改查
• 不一樣環境配置隔離（開發、測試、預發佈、灰度/線上）
• 高性能、高可用性
• 請求量多、高併發
• 讀多寫少

咱們能夠設計出以下的簡版配置中心

設計說明點：

• 經過OA系統對每一條配置（每個配置有惟一的配置ID）進行增刪改查。
• 區分不一樣環境的配置，每一個環境同一配置ID對應不一樣數據庫記錄。
• 配置最終以json格式（便於編輯和理解）儲存在mysql數據庫中。
• 引入redis集羣，作配置的緩存（好比能夠設置配置修改後1分鐘後生效）
• 配置對外服務，多機器部署，知足性能須要。
• 若是有必要，能夠引入配置歷史修改記錄。

不少時候，這樣能夠基本上知足咱們對配置系統的基本需求，對配置的增刪改查，能容忍一段時間的數據不一致性。

這種設計，因爲全部的配置都存放在集中式緩存中，這樣集中式的緩存也會有他的性能瓶頸。並且，每次配置的訪問都須要發起rpc請求(網絡請求)，所以考慮在客戶端引入本地緩存（localCache，例如Ehcache）。

本地緩存能夠參考我以前文章：【180409】本地緩存的選擇及其原理

配置中心之性能可用性改進

考慮到，減小網絡請求的因素，在客戶端引入localcache，來解決系統的高可用，高性能、可伸縮性。

相對於初版的改進點是，在客戶端引入localcache。開啓線程異步調用配置服務，更新本地配置。 這樣能夠減小rpc調用。

基於數據的CAP原理，該方式只作到了AP，這裏會存在數據的一段時間的不一致性，但最終會保證是配置的最終一致性。如何解決這個數據不一致性問題？

配置中心之數據一致性改進

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

最後經過，推拉相結合的方式，完成數據的一致性。

我的

歡迎關注個人技術博客，咱們一塊兒成長一塊兒進步。

林灣村龍貓：www.jianshu.com/u/5a327aab7…