在微服務架構的系列文章中，前面已經通過文章《微服務架構之「服務閘道器 」》介紹過了在微服務中服務閘道器的原理和應用，今天這篇文章我們繼續來聊一聊微服務中另外一個重要模組：「 配置中心 」。後面還會繼續介紹 服務框架、服務監控、服務治理等。還是那句話，只有將這些基礎設施弄清楚了，微服務實踐的道路才能走的穩、走的遠。

「配置中心」，顧名思義，就是用來統一管理專案中所有配置的系統。雖然聽起來很簡單，但也不要小瞧了這個模組。如果一箇中型網際網路專案，不採用配置中心的模式，一大堆的各類配置項，各種不定時的修改需求，一定會讓開發同學非常頭疼且管理十分混亂。我認為甚至可以直接用 “一個專案中是否有無採用「配置中心」” 這一粗略的條件，來判斷一個網際網路研發團隊是否規範和成熟。

一、為什麼需要「配置中心」？

我們先來看看在沒有「配置中心」的傳統專案中，我們是怎麼處理各類配置引數問題的：

1. 一般是靜態化配置。大多數在專案中單獨寫一個配置檔案，例如 "config.conf"，然後將各類 引數配置、應用配置、環境配置、安全配置、業務配置 都寫到這個檔案裡。當專案程式碼邏輯中需要使用配置的時候，就從這個配置檔案中讀取。這種做法雖然簡單，但如果引數需要修改，就非常的不靈活，甚至需要重啟執行中的專案才能生效。相信大多數開發同學都深有體會。

2. 配置檔案無法區分環境。由於配置檔案是放在專案中的，但是我們專案可能會有多個環境，例如：測試環境、預釋出環境、生產環境。每一個環境所使用的配置引數理論上都是不同的，所以我們在配置檔案中根據不同環境配置不同的引數，這些都是手動維護，在專案釋出的時候，極其容易因開發人員的失誤導致出錯。

3. 配置檔案過於分散。如果一個專案中存在多個邏輯模組獨立部署，每個模組所使用的配置內容又不相同，傳統的做法是會在每一個模組中都放一個配置檔案，甚至不同模組的配置檔案格式還不一樣。那麼長期的結果就是配置檔案過於分散混亂，難以管理。

4. 配置修改無法追溯。因為採用的靜態配置檔案方式，所以當配置進行修改之後，不容易形成記錄，更無法追溯是誰修改的、修改時間是什麼、修改前是什麼內容。既然無法追溯，那麼當配置出錯時，更沒辦法回滾配置了。

上面只是拿配置檔案的形式來舉例，有的專案會採用資料庫配置，雖然靈活一點，但是依舊不能完全解決上述問題。既然傳統的專案配置有這麼多弊端，那我們看看「配置中心」的方案是如何解決這些痛點的：

「配置中心」的思路就是把專案中各種配置、各種引數、各種開關，全部都放到一個集中的地方進行統一管理，並提供一套標準的介面。當各個服務需要獲取配置的時候，就來「配置中心」的介面拉取。當「配置中心」中的各種引數有更新的時候，也能通知到各個服務實時的過來同步最新的資訊，使之動態更新。

那麼，按照上述思路，我們理想中的「配置中心」應該具備如下特點：

• 配置集中管理、統一標準

• 配置與應用分離

• 實時更新

• 高可用

具有上述特性的「配置中心」是如何解決上面傳統配置所面臨的問題的呢？

1. 採用“配置集中管理”，可以很好的解決傳統的“配置檔案過於分散”的問題。所有的配置都集中在配置中心這一個地方管理，不需要每一個專案都自帶一個，這樣極大的減輕了開發成本。

2. 採用“配置與應用分離”，可以很好的解決傳統的“配置檔案無法區分環境”的問題，配置並不跟著環境走，當不同環境有不同需求的時候，就到配置中心獲取即可，極大的減輕了運維部署成本。

3. 具備“實時更新”的功能，就是用來解決傳統的“靜態化配置”的問題。線上系統需要調整引數的時候，只需要在配置中心動態修改即可。

4. 既然配置都統一管理了，那配置中心在整個系統中的地位就非常重要了，一旦配置中心不能正常提供服務，就可能會導致專案整體故障，因此“高可用”就是配置中心又一個很關鍵的指標了。

二、「配置中心」的原理與應用？

通過上面的介紹，其實就可以瞭解到「 配置中心 」的原理不是很複雜。其核心功能也不多，主要是：

1. 實現配置的記錄

2. 實現配置的讀取、更新、取消

3. 實現配置的檢視

但是圍繞著這幾個核心功能，我們還需要保障高可行、要實現實時更新、要能方便的使用，還希望有許可權管理的功能、操作審計的功能等等，加上這些周邊輔助功能之後，一個完善的「 配置中心 也就不那麼簡單了。

我們再來看一下在實際專案中如何去選型和應用：

雖然配置中心的核心原理並不複雜，我們可以根據原理自己去實現一個配置中心，但是如果沒有特殊需求，還是不建議重複造輪子了，畢竟業內已經有很多成熟的開源方案可以直接選用了。下面就列舉幾個比較熱門的配置中心開源元件給大家參考：

• Apollo

  Apollo是由攜程開源的分散式配置中心。

  Apollo的特點有很多，比如：配置更新之後可以實時生效，還可以支援灰度釋出功能。並且能對所有的配置進行版本管理、操作審計等功能，提供開放平臺API。另外由於Apollo使用的人很多，所以網上的資料也非常的豐富，並且github上資料也寫的很詳細。

  上面即是Apollo的基礎模型，看結構很簡單。但是其功能很多，之前說過配置中心對高可用的要求很高。下面可以繼續看一下Apollo的架構：

• 更多的Apollo資料可以直接去github上檢視，可以說官方文件是非常體貼的。

• Spring Cloud Config

  看名字就知道，這是Spring Cloud中帶的配置中心元件。也正是這個原因，所以它和Spring是無縫整合，使用起來非常方便。並且它的配置儲存支援Git，不過它沒有視覺化的操作介面，配置的生效也不是實時的，需要重啟或去重新整理。所以比較適用於小型專案快速上手。

  Spring Cloud Config包含了Config Client和Config Server兩部分，Config Server 實現配置檔案的儲存，對外以介面的形式提供獲取配置檔案，然後Config  Client通過這些介面獲取資料。

• Disconf

  Disconf是由百度開源的分散式配置中心。其實很多一線大廠都有開源自己的配置中心元件，這裡挑出百度的Disconf也是因為網上比較火熱，易用性也還不錯，專案也是託管在github上很容易找到。它是基於Zookeeper來實現配置變更後實時通知和生效的。

  

以上，就是對微服務架構中「 配置中心」的一些思考。

碼字不易啊，喜歡的話不妨轉發朋友，或點選文章右下角的“在看”吧。