一、配置中心的必要性

當代碼中有一些變數可能會動態變化時，或者一些變數使用的地方比較多，此時就可以採用配置的方式來動態讀取，而不是將變數的值寫死在程式碼裡，否則難以維護，所以應用程式就有了配置檔案。單機應用程式的配置通常就是配置檔案，叢集程式的配置就需要配置中

心。如果沒有配置中心，那麼在以下場景就會帶來不便。

場景一：程式執行時修改配置

採用配置檔案的方式，程式啟動時讀取配置檔案並將配置讀取賦值到程式變數中，此時修改配置檔案已經無法修改程式中的變數值，只能重啟應用程式才可以修改

場景二：叢集部署修改配置

採用配置檔案的方式，如果需要修改配置檔案，那麼在叢集模式下就需要依次修改所有叢集節點的配置檔案，當叢集規模較大時，修改配置檔案的工作量會很大

場景三：多環境下修改配置

專案從開發到釋出，會依次經歷開發->測試->預發->生產等環境，不同環境的配置不盡相同，採用配置檔案的話就需要同時維護多份配置檔案或者頻繁修改配置檔案，無論哪一種都比較繁瑣。

總結：

採用配置中心可以保證配置的安全性、時效性和動態擴充套件性。所以有一套能夠服務於叢集部署、多環境部署、能動態調整的配置中心就顯得尤為重要，雖然不能給程式帶來效能提升，但是能夠大大提高專案執行的靈活性以及提高開發和運維的工作效率。

二、配置中心的功能

配置中心基本功能

1、配置維護：配置的增刪改查

2、配置持久化：配置中心儲存配置資訊，需要保證新增的配置不會丟失，通常會儲存在資料庫

3、環境隔離：不同環境的配置之間相互隔離，互不影響

4、視覺化管理：通過管理後臺方便的進行配置管理

配置中心高階功能

5、版本管理：配置有不同版本，可隨時查詢不同版本的配置

6、實時更新：配置更新後，應用程式及時感知並更新本地快取

7、資料一致性：當配置中心是叢集部署時，需要保證資料的一致性

8、高可用性：配置中心需要保證高效能、高穩定性，確保應用程式隨時獲取配置

三、配置中心整體架構

配置中心整體架構比較簡單，只需要提供API給客戶端，然後採用資料庫儲存配置資訊即可。而基於配置的實時更新可以採用客戶端長輪訓查詢的方式，也可以採用配置中心伺服器推送的方式。

對於獲取配置是pull還是push的方式，兩種方式都各有利弊，所以需要看具體的配置中心是如何權衡來實現。

基於pull方式：實時性不高，需要客戶端不斷輪訓查詢最新配置，決定權在於客戶端，伺服器可以採用叢集提供效能；

基於push方式：實時性高，但是客戶端需要和伺服器保持長連線，當伺服器叢集部署時，客戶端需要和每一臺伺服器保持長連線，連線的維護比較複雜；

四、配置中心選型

目前開源的配置中心有很多，如Diamond、XDiamond、disconf、springcloud config、apollo、nacos等等，而目前熱門的有disconf、springcloud config、apollo、nacos，這幾種配置中心對比如下：

綜合來看，apollo和nacos從實現邏輯和功能支援上都比較類似，比disconf、springcloud config而已功能更豐富，生態支援要更好。所以選用時可以優先選擇apollo或nacos。

apollo比nacos功能支援更多，但是使用和運維比nacos要更復雜，而nacos除了可以當作配置中心，還可以用於服務註冊與發現，nacos使用和部署簡單，且讀寫效能要更好。

具體應用時選擇哪種配置中心可以根據專案的實際情況進行選擇，如果是需要功能支援更豐富的專業的配置中心就可以選用apollo；如果是需要高效能，部署簡單且同時使用到服務釋出與訂閱時就可以考慮採用nacos。