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

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

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

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

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

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

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

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

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

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

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

• 配置集中管理、統一標準
• 配置與應用分離
• 實時更新
• 高可用

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

采用“配置集中管理”，可以很好的解決傳統的“配置文件過于分散”的問題。所有的配置都集中在配置中心這一個地方管理，不需要每一個項目都自帶一個，這樣極大的減輕了開發成本。

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

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

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

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

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

實現配置的記錄

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

實現配置的查看

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

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

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

• 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技術 等。

總結

以上是生活随笔為你收集整理的spring.profiles.active配置了没生效_微服务架构之「 配置中心 」的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。