微服務架構之「 配置中心 」

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

「配置中心」，顧名思義，就是用來統一管理項目中全部配置的系統。雖然聽起來很簡單，但也不要小瞧了這個模塊。若是一箇中型互聯網項目，不採用配置中心的模式，一大堆的各種配置項，各類不定時的修改需求，必定會讓開發同窗很是頭疼且管理十分混亂。我認爲甚至能夠直接用 「一個項目中是否有無採用「配置中心」」 這一粗略的條件，來判斷一個互聯網研發團隊是否規範和成熟。

1、爲何須要「配置中心」？

咱們先來看看在沒有「配置中心」的傳統項目中，咱們是怎麼處理各種配置參數問題的：

1. 通常是靜態化配置。大多數在項目中單獨寫一個配置文件，例如 "config.conf"，而後將各種 參數配置、應用配置、環境配置、安全配置、業務配置 都寫到這個文件裏。當項目代碼邏輯中須要使用配置的時候，就從這個配置文件中讀取。這種作法雖然簡單，但若是參數須要修改，就很是的不靈活，甚至須要重啓運行中的項目才能生效。相信大多數開發同窗都深有體會。

2. 配置文件沒法區分環境。因爲配置文件是放在項目中的，可是咱們項目可能會有多個環境，例如：測試環境、預發佈環境、生產環境。每個環境所使用的配置參數理論上都是不一樣的，因此咱們在配置文件中根據不一樣環境配置不一樣的參數，這些都是手動維護，在項目發佈的時候，極其容易因開發人員的失誤致使出錯。

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

4. 配置修改沒法追溯。由於採用的靜態配置文件方式，因此當配置進行修改以後，不容易造成記錄，更沒法追溯是誰修改的、修改時間是什麼、修改前是什麼內容。既然沒法追溯，那麼當配置出錯時，更沒辦法回滾配置了。

上面只是拿配置文件的形式來舉例，有的項目會採用數據庫配置，雖然靈活一點，可是依舊不能徹底解決上述問題。既然傳統的項目配置有這麼多弊端，那咱們看看「配置中心」的方案是如何解決這些痛點的：

「配置中心」的思路就是把項目中各類配置、各類參數、各類開關，所有都放到一個集中的地方進行統一管理，並提供一套標準的接口。當各個服務須要獲取配置的時候，就來「配置中心」的接口拉取。當「配置中心」中的各類參數有更新的時候，也能通知到各個服務實時的過來同步最新的信息，使之動態更新。

那麼，按照上述思路，咱們理想中的「配置中心」應該具有以下特色：

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

• 配置與應用分離

• 實時更新

• 高可用

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

1. 採用「配置集中管理」，能夠很好的解決傳統的「配置文件過於分散」的問題。全部的配置都集中在配置中心這一個地方管理，不須要每個項目都自帶一個，這樣極大的減輕了開發成本。

2. 採用「配置與應用分離」，能夠很好的解決傳統的「配置文件沒法區分環境」的問題，配置並不跟着環境走，當不一樣環境有不一樣需求的時候，就到配置中心獲取便可，極大的減輕了運維部署成本。

3. 具有「實時更新」的功能，就是用來解決傳統的「靜態化配置」的問題。線上系統須要調整參數的時候，只須要在配置中心動態修改便可。

4. 既然配置都統一管理了，那配置中心在整個系統中的地位就很是重要了，一旦配置中心不能正常提供服務，就可能會致使項目總體故障，所以「高可用」就是配置中心又一個很關鍵的指標了。

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

經過上面的介紹，其實就能夠了解到「 配置中心 」的原理不是很複雜。其核心功能也很少，主要是：

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來實現配置變動後實時通知和生效的。

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

碼字不易啊，喜歡的話不妨轉發朋友，或點擊文章右下角的「在看」吧。😊

本文原創發佈於微信公衆號「 不止思考 」，歡迎關注。涉及 思惟認知、我的成長、架構、大數據、Web技術 等。