目錄

Spring Cloud Config（一）：聊聊分散式配置中心 Spring Cloud Config
Spring Cloud Config（二）：基於Git搭建配置中心
Spring Cloud Config（三）：基於JDBC搭建配置中心
Spring Cloud Config（四）：配置資訊動態重新整理
Spring Cloud Config（五）：配置中心服務端Config Server原始碼解析
Spring Cloud Config（六）：配置中心客戶端Client原始碼解析
Spring Cloud Config（七）：配置中心自定義擴充套件
Spring Cloud Config（八）：Client 端覆蓋Server端配置屬性
Spring Cloud Config（九）：Config Server 端配置檔案安全保護
Spring Cloud Config（十）：快速響應失敗和重試機制

1、Spring Cloud Config 定義

Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments. The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications, but can be used with any application running in any language. As an application moves through the deployment pipeline from dev to test and into production you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate. The default implementation of the server storage backend uses git so it easily supports labelled versions of configuration environments, as well as being accessible to a wide range of tooling for managing the content. It is easy to add alternative implementations and plug them in with Spring configuration.

Spring Cloud Config 為分散式系統中的外部化配置提供伺服器和客戶端支援。 使用Config Server，您可以在所有環境中管理應用程式的外部屬性。客戶端和伺服器上的概念與Spring Environment和PropertySource抽象相同，因此它們非常適合Spring應用程式，但可以與任何語言執行的任何應用程式一起使用。當應用程式通過部署管道從開發到測試並進入生產時，您可以管理這些環境之間的配置，並確保應用程式具有遷移時需要執行的所有內容。他預設的伺服器儲存後端實現使用git，因此它可以輕鬆支援配置環境的標籤版本，並且可以訪問各種用於管理內容的工具。 基於spring配置可以很方便的實現擴充套件。

2、為什麼選擇 Spring Cloud Config

那麼有人可能會問了，業界關於分散式配置中心有多種開源的元件，如攜程開源的 Apollo、 百度的 Disconf、淘寶的 Diamond 等，已經不少了，為啥還會誕生Spring Cloud Config呢？

應用服務除了實現系統功能，還需要連線資源和其它應用，經常需要調整服務的配置來改變應用的行為，如切換不同資料庫，設定功能開關等。隨著微服務數量的不斷增加，需要系統具備可伸縮性和可擴充套件性，除此之外就是需要管理服務例項的配置資料。在開發階段配置資訊由各個服務自己管理，但是到了生產環境會給運維帶來很多不便。因此係統需要建立一個統一的配置管理中心，常見配置中心的實現方法有：

• 硬編碼，缺點就是需要修改程式碼

• 放在xml等配置檔案中和應用一起打包，缺點就是配置修改需要重新打包和重啟

• 放在檔案系統中，缺點就是依賴作業系統

• 配置到系統環境變數，缺點是需要大量的配置工作，不方便管理

個人看來，Spring Cloud Config 在以下幾方面還是有比較明顯的優勢，所以可能是為什麼要再造一個輪子的原因吧：

1、基於應用、環境、版本三個維度管理

應用（application）

每個配置都是屬於某一個應用的

環境（profile）

每個配置都是區分環境的，如dev, test, prod等

版本（label）

這個可能是一般的配置中心所缺乏的，就是對同一份配置的不同版本管理
Spring Cloud Config提供版本的支援，也就是說對於一個應用的不同部署例項，可以從服務端獲取到不同版本的配置，這對於一些特殊場景如：灰度釋出，A/B測試等提供了很好的支援。

2、多種儲存方式

基於Git儲存，一方面程式設計師非常熟悉，另一方面在部署上會非常簡單，而且藉助於Git天生就能非常好的支援版本，同時它還支援其它的儲存如本地檔案、SVN、jdbc等

3、Spring無縫整合

它無縫支援Spring裡面Environment和PropertySource的介面
所以對於已有的Spring應用程式的遷移成本非常低，在配置獲取的介面上是完全一致的

3、Spring Cloud Config 簡介

上圖簡要描述了一個普通Spring Cloud Config應用的場景。其中主要有以下幾個元件：

• Config Client

Client很好理解，就是使用了Spring Cloud Config的應用
Spring Cloud Config提供了基於Spring的客戶端，應用只要在程式碼中引入Spring Cloud Config Client的jar包即可工作

• Config Server

Config Server是需要獨立部署的一個web應用，它負責把git上的配置返回給客戶端

• Remote Git Repository

遠端Git倉庫，一般而言，我們會把配置放在一個遠端倉庫，通過git客戶端來管理配置

• Local Git Repostiory

Config Server接到來自客戶端的配置獲取請求後，會先把遠端倉庫的配置clone到本地的臨時目錄，然後從臨時目錄讀取配置並返回

4、總結

Spring Cloud Config 專案

• 提供 服務端 和 客戶端 支援

• 集中式 管理分散式環境下的應用配置

• 基於 Spring 環境，無縫 與 Spring 應用整合

• 可用於 任何 語言開發的程式

• 預設實現基於 git 倉庫，可以進行 版本管理

• 可替換 自定義實現

Spring Cloud Config Server 作為配置中心服務端

• 拉取配置時更新 git 倉庫副本，保證是最新結果

• 支援資料結構豐富，yml, json, properties 等

• 配合 eureke 可實現服務發現，配合 cloud bus 可實現配置推送更新

• 配置儲存基於 git 倉庫，可進行版本管理

• 簡單可靠，有豐富的配套方案

Spring Cloud Config Client 預設客戶端實現

SpringBoot 專案不需要改動任何程式碼，加入一個啟動配置檔案指明使用 ConfigServer 上哪個配置檔案即可