最近在看配置中心的一些設計，好像基本都是五花八門，主要看的是還是攜程的 Apollo 這個開源的配置中心項目。一直以來都覺得配置中心很重要，因為這對于灰度發布，線上實施干預都有非常重大的作用。但是嘛，你們都知道我有多懶，所以又一直沒去好好了解一下，今天趁這個時間跟大家聊聊配置一個合格的配置中心應有的素養。

• 首先什么是配置？
• 配置有什么獲取方式？
• 為什么需要實時變更配置？
• 為什么需要配置中心
• 配置中心的分層有必要嗎？
• 實時變更配置的方式有幾種？
• 配置中心還有什么其他基本的素養？
• 一個實時推送的配置中心架構是怎樣的？

[[216216]]

01、首先什么是配置？

我的理解是，配置是同一個程序在不同場景不同環境下做出不同表現的一個可變動頻繁的點。配置在啟動的時候通過各種形式進行獲取，在整個生命流程中配置一般來說，是只讀的，程序是不會主動去變更的，只有其他地方變更了之后才會觸發程序的變更。

最經典的配置有兩類，一類是數值型，比如客戶的授信額度比例。一類是 Bool 型，用來對某些功能做禁用或啟用。

public class configuration { 
 
    private int NUMBER_CONFIG  = 5; 
    private boolean SWITCH_CONFIG = true; 
 
    public void config(){ 
        if(SWITCH_CONFIG){ 
            System.out.println("YES"); 
        } 
        System.out.println("print YES" + NUMBER_CONFIG); 
    } 
} 

02、配置有什么獲取方式？

配置的獲取方式不外乎5種。Hard Code、配置文件、環境變量、數據庫獲取、啟動參數，外部 server 獲取。

喇喇喇。上面我寫的那堆玩意就是 Hard Code 的。什么叫 Hard Code，就是代碼寫得跟鐵似的硬邦邦的你敲一下還會叮的一生那種。

配置文件，吶，平時用的比較多還是配置文件，比如 Spring 的 application.xml 啊，someFool.properties。

環境變量，嗯，比如 JAVA_HOME 之類的在操作系統上的環境變量。

數據庫獲取，就是啟動的時候或者定時去數據庫撈一下。

啟動參數，就是作為啟動的時候帶的參數。比如 java -jar start.jar big。最后的 big 就是啟動參數，也是配置項的一種。

外部 server 獲取，意思就是這個配置項呢，是其他系統維護的，比如說存款準備金，就是一個央媽這個超級中心維護的配置項，所有的中小企業都要去央媽獲取。

03、為什么需要實時變更配置？

人都是善變的，別問我為什么。。。老板昨天說咱有錢，就給客戶爸爸們發錢吧，一單 15% 。今天發現銀包撐不住了，跟我說大蕉同學我不管你怎么搞你趕緊把這個功能下了，我又不想發版本，所以就需要實時變更配置了。就這么簡單，人都是善變的。

04、為什么需要配置中心？

一個應用兩個應用還行，要是有100個應用，還真不知道怎么管理，實時推送配置項也成了一大難題。現在傳統的比較主流的配置項管理做法有這么幾種。

改代碼重新打包（真特么傻逼）

改配置項重啟。（說實話蠻那啥的）

改數據庫重啟。（一樣）

改數據庫定時獲取。（浪費資源，一直在輪詢，還需要一定時間才生效）

只能說，時間太長了，太浪費了，少則30秒多則60分鐘（不要問我為什么是60分鐘，因為有一些傻逼應用啟動起來就特么要這么久）。

所以有個配置中心來幫你管理這些東西，不亦說乎？

05、配置中心的分層有必要嗎？

現在主流的配置中心都會進行分層，五花八門，有的恨不得一臺機器一臺機器管理，有的又特么的一個集群只能統一配置。其實只需要下面幾個維度就夠了，應用維度，集群維度，機器維度。有了這三個維度基本可以滿足99.9999%的需求，如果發現還不能滿足，那么你所說的不在我這個范圍。（偷笑ing）

06、實時變更配置的方式有幾種？

從廣義來說，就兩種，一是定時拉取，而是實時推送。

定時拉取的有：定時從數據庫拉取，定時從外部 server 拉取，定時從共享配置文件讀取。

實時推送的有：用 kafka 等消息隊列作為消費端消費，用 webSocket、 http 或者 rpc 接口 作為服務端接收推送。

07、配置中心還有什么其他基本的素養？

• 可分區推送

           可以作為 A/B Test 的一種手段，也可以用來預防配置出錯。

• 審批

一般來說配置變更是一件不小的事情，還是要有審批鏈的。

• 環境識別

對于 DEV 開發環境，STG 測試環境，PRD 生產環境要能做到針對環境不同讀取不同的配置項。

• 持久化

有時候配置中心會掛了，而這時候是不應該影響應用的，所以應該要有持久化的機制來保證服務恢復后的數據問題。

• 監控

用戶能實時知道發布到什么哪了，哪些機器是新配置哪些機器是舊配置，以及基于版本的實實時回滾功能。

• 操作審計

對配置的一切操作都會有操作記錄，以便后期監控和審計用。

08、一個實時推送的配置中心架構是怎樣的？

一個配置中心最樸素的架構就是上面這樣。用戶發布配置修改，配置中心通知應用進行更新，應用獲取最新配置。

再細一點呢，分為客戶端和配置中心兩路來講。

• 客戶端

客戶端在應用啟動的同事，要啟動一個服務專門用來接收來自配置中心的通知，這個服務可以是 kafka 、RocketMQ、WebSocket、RPC、DUBBO 等能作為服務提供給外部的接口，并主動向配置中心注冊自己。

服務提供完之后，開始掃描自己所需要的配置項，并根據配置主動從本地讀取（本地開發模式）或從配置中心獲取相應環境的配置項。

讀取完成后放在內存中，所有對于配置的讀取都從內存中讀取，對于JAVA來說可能就是一個 static 變量或者一個 HashMap 。

如果配置中心通知變更了，那么直接讀取新的值，然后替換內存中的配置項，就 ok 了。

• 配置中心

配置中心要做的事情，就是根據用戶的操作，對配置項進行發布，通過調用客戶端提供的接口或者發送消息，通知客戶端來更新消息，或者直接把更新的配置項推過去。非常樸素但是非常好用。