腳本之家服務器常用軟件

快捷導航

Spring Cloud Config配置詳解

更新時間：2026年05月23日 09:27:51 作者：Jul1en_

這篇文章主要介紹了Spring Cloud Config配置詳解,Spring Cloud Config簡化了配置管理的整個流程,包括配置的存放、獲取、變更通知、自動刷新和安全保護,需要的朋友可以參考下

Spring Cloud Config 解決的是微服務項目中“配置分散、環(huán)境復雜、修改成本高”的問題。單體項目里，配置通常寫在本地 application.yml 中，應用啟動時直接讀取即可。但微服務項目會拆出多個服務，每個服務又會區(qū)分開發(fā)、測試、生產(chǎn)等環(huán)境。如果每個服務都自己維護一份配置，時間久了就會出現(xiàn)配置重復、版本混亂、修改困難的問題。

配置中心的思路就是把配置從服務代碼里抽出來，交給一個統(tǒng)一的服務管理。Spring Cloud Config 中，承擔統(tǒng)一管理角色的是 Config Server，真正使用配置的業(yè)務服務是 Config Client。Config Server 從 Git、本地文件系統(tǒng)、Vault、JDBC 等后端讀取配置，再通過 HTTP 接口提供給各個客戶端。Config Client 啟動時訪問 Config Server，拉取屬于自己的配置并加載到 Spring Environment 中。

為什么需要 Spring Cloud Config

微服務拆分之后，配置數(shù)量會快速增加。比如一個電商系統(tǒng)可能有用戶服務、訂單服務、商品服務、網(wǎng)關服務，每個服務又可能有 dev、test、prod 三套環(huán)境。如果所有配置都放在各自服務內部，修改數(shù)據(jù)庫地址、緩存地址、開關配置時，就需要分別進入多個服務修改，甚至重新打包發(fā)布。

Spring Cloud Config 把配置統(tǒng)一放到遠程配置倉庫中，服務本身只保留“我是誰、我要去哪里拉配置”這類最基礎的信息。這樣一來，配置的維護位置就從“每個微服務內部”變成了“統(tǒng)一配置倉庫”，配置讀取入口也從“服務本地文件”變成了“Config Server”。

這種變化帶來兩個直接好處。第一，配置可以集中管理，避免同一個配置在多個服務中重復維護。第二，配置可以通過 Git 追蹤歷史，誰改了什么、什么時候改的，都有記錄。對于團隊協(xié)作和多環(huán)境管理來說，這比散落在各個服務里的配置更可靠。

Config Server 與 Config Client 的關系

Config Server 是配置中心服務端，它不一定直接保存配置文件，而是連接一個配置后端。入門階段最常見的是 Git 倉庫。Git 倉庫中可以存放類似 user-service-dev.yml、order-service-prod.yml 這樣的配置文件。Config Server 啟動后，會讀取這些配置，并通過 HTTP 接口提供給客戶端。

Config Client 是具體業(yè)務服務，例如 user-service、order-service、gateway-service。這些服務啟動時會主動訪問 Config Server。訪問時，客戶端會告訴服務端三個關鍵信息：應用名、環(huán)境和配置版本。Config Server 根據(jù)這三個信息找到對應配置，再返回給客戶端。

這里的三個信息非常重要。application 表示應用名，通常來自 spring.application.name。profile 表示環(huán)境，例如 dev、test、prod。label 通常表示 Git 分支或標簽，例如 main、master、v1.0。所以 Config Server 本質上是在回答一個問題：某個應用在某個環(huán)境下，需要讀取哪個版本的配置。

如果 user-service 啟動時指定了應用名為 user-service，環(huán)境為 dev，配置倉庫分支為 main，那么它訪問 Config Server 時，Config Server 就會嘗試查找和 user-service-dev 相關的配置，并把結果組合成 Spring 可以識別的 PropertySource 返回給客戶端。

Config Server 簡單部署

搭建 Config Server 的第一步是創(chuàng)建一個普通 Spring Boot 服務，并添加 Config Server 依賴。這個依賴讓當前服務具備從配置倉庫讀取配置并對外暴露配置接口的能力。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

然后在啟動類上添加 @EnableConfigServer。這個注解的作用是開啟 Config Server 功能，讓這個 Spring Boot 應用不再只是普通服務，而是可以作為配置中心服務端工作。

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

接下來需要告訴 Config Server 配置倉庫在哪里。最常見的是配置 Git 倉庫地址。

server:
  port: 8888
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://example.com/config-repo.git
          default-label: main

server.port 決定 Config Server 的訪問端口，常見示例端口是 8888。spring.cloud.config.server.git.uri 指向遠程配置倉庫地址。default-label 表示默認讀取哪個分支或標簽。

啟動 Config Server 后，如果配置倉庫中存在 user-service-dev.yml，客戶端或瀏覽器可以通過類似 http://localhost:8888/user-service/dev/main 的路徑訪問配置。這個路徑中的 user-service 對應應用名，dev 對應環(huán)境，main 對應 Git 分支。

本地學習時也可以使用 native 模式，把配置倉庫放在本地目錄中。它的好處是簡單，不需要先準備遠程 Git 倉庫，但真實項目中更常用 Git，因為 Git 更適合團隊協(xié)作、版本回退和變更審計。

spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          search-locations: file:///D:/config-repo

Config Client 簡單部署

Config Client 是業(yè)務服務。它的目標不是管理配置，而是在啟動時從 Config Server 拿到自己的配置?？蛻舳诵枰砑?spring-cloud-starter-config 依賴。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

新版本更推薦使用 spring.config.import 的方式導入遠程配置。這樣寫的含義很明確：當前應用啟動時，除了讀取本地配置，也會從 Config Server 導入配置。

spring:
  application:
    name: user-service
  profiles:
    active: dev
  config:
    import: optional:configserver:http://localhost:8888

這里的因果關系要理解清楚。spring.application.name 決定應用名，所以它影響 Config Server 查找哪個服務的配置。spring.profiles.active 決定當前環(huán)境，所以它影響讀取 dev、test 還是 prod 配置。spring.config.import 決定配置來源，所以它告訴 Spring Boot：請到這個 Config Server 地址拉取遠程配置。

如果配置倉庫中有 user-service-dev.yml，內容如下：

user:
  level: vip

那么 user-service 啟動后，就可以像讀取本地配置一樣讀取到 user.level。從業(yè)務代碼角度看，它不需要關心這個配置原本來自 Git 還是本地文件，因為配置最終都會進入 Environment。

@RestController
public class UserController {
    @Value("${user.level:normal}")
    private String userLevel;
    @GetMapping("/level")
    public String level() {
        return userLevel;
    }
}

到這里，Spring Cloud Config 的第一條主線就完整了：配置放在 Git 中，Config Server 讀取 Git，Config Client 啟動時從 Config Server 拉取配置。

刷新機制

Config Client 啟動時會拉取配置，但服務啟動完成后，它不會自動每秒去檢查配置倉庫有沒有變化。也就是說，如果你修改了 Git 倉庫中的配置，已經(jīng)運行中的服務通常不會立即感知。

這就產(chǎn)生了一個新問題：配置中心解決了“配置放在哪里、啟動時怎么讀取”的問題，但還沒有完全解決“運行時配置變化后怎么生效”的問題。

最基礎的方式是手動刷新。比如通過 Actuator 的 /actuator/refresh 端點讓某個服務重新加載配置。這個方式在單個服務、單個實例時還能接受，但在真實微服務場景中很快會變得麻煩。

假設系統(tǒng)有 5 個服務，每個服務部署 3 個實例，那么一次配置變化可能需要處理 15 個實例。如果人工逐個調用刷新接口，不僅低效，還容易漏掉某個實例。為了讓配置變更自動傳播，就需要 Webhook 和 Spring Cloud Bus 配合。

Webhook 的概念

Webhook 是一種事件回調機制。它和輪詢正好相反。輪詢是服務不斷去問配置倉庫有沒有變化；Webhook 是配置倉庫發(fā)生變化后，主動通知指定地址。

以 Git 倉庫為例，當開發(fā)者修改配置并 push 到 GitHub、GitLab 或 Gitee 后，倉庫平臺可以向 Config Server 的某個接口發(fā)送 HTTP POST 請求。這個請求的意義不是傳輸完整配置，而是告訴 Config Server：配置倉庫已經(jīng)發(fā)生變化，你需要處理刷新。

在 Spring Cloud Config 中，Config Server 引入 spring-cloud-config-monitor 后，可以開啟 /monitor 端點。Webhook 通常就配置到這個 /monitor 端點上。于是配置變化后的鏈路變成：開發(fā)者修改配置，push 到倉庫，倉庫觸發(fā) Webhook，Webhook 請求 Config Server 的 /monitor，Config Server 獲知配置變化。

Webhook 只解決了“誰來告訴 Config Server 倉庫變了”的問題。但 Config Server 知道配置變了以后，還要通知所有相關微服務實例刷新。這個廣播能力就是 Spring Cloud Bus 要解決的問題。

Spring Cloud Bus 自動刷新機制

Spring Cloud Bus 可以理解為分布式系統(tǒng)中的消息總線。它把多個微服務實例通過消息代理連接起來，例如 RabbitMQ 或 Kafka。Config Server 收到配置變化通知后，可以把刷新事件發(fā)送到 Bus 上，再由 Bus 廣播給相關的 Config Client 實例。

有了 Spring Cloud Bus，配置刷新鏈路就從“人工逐個刷新實例”變成了“觸發(fā)一次事件，消息總線自動廣播”。這個變化的關鍵價值是降低運維成本，并減少遺漏實例的風險。

完整流程可以按因果順序理解。首先，配置倉庫發(fā)生變化。然后，Webhook 把變化通知給 Config Server 的 /monitor。Config Server 收到通知后，不直接逐個調用服務，而是發(fā)布一個 RefreshRemoteApplicationEvent。接著，Spring Cloud Bus 通過 RabbitMQ 或 Kafka 把這個事件廣播出去。最后，Config Client 收到事件后刷新本地 Environment，并重新創(chuàng)建或刷新帶有 @RefreshScope 的 Bean。

@RefreshScope 很關鍵。配置刷新不是讓所有對象都自動變成新值。只有那些被納入刷新范圍的 Bean，才會在刷新事件到來后重新讀取配置。因此，運行時可能變化的配置類，通常會配合 @RefreshScope 使用。

Webhook + Bus 簡單配置

Config Server 側需要具備兩個能力：接收倉庫變更通知，以及把刷新事件發(fā)布到消息總線。因此需要添加 monitor 和 bus 相關依賴。以 RabbitMQ 為例：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-monitor</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

Config Client 側也需要接入 Bus，因為客戶端要能從消息總線接收刷新事件。同時還需要 Actuator 參與刷新相關能力。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Config Server 和 Config Client 要連接同一個消息代理。如果使用 RabbitMQ，可以配置連接信息。

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

如果某個配置類需要運行時刷新，可以使用 @RefreshScope。

@Component
@RefreshScope
@ConfigurationProperties(prefix = "app")
public class AppProperties {
    private String name;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

配置倉庫的 Webhook 地址通常指向 Config Server 的 /monitor。本地測試時，也可以手動向 /monitor 發(fā)送請求，模擬倉庫觸發(fā)通知。

curl -X POST http://localhost:8888/monitor \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "path=user-service"

這里的 path=user-service 表示和 user-service 相關的配置發(fā)生變化，Config Server 會嘗試將刷新事件發(fā)送給匹配的應用。

加密環(huán)境

配置中心集中管理配置后，新的問題出現(xiàn)了：敏感配置也會集中起來。數(shù)據(jù)庫密碼、Redis 密碼、第三方接口密鑰如果直接以明文形式存入 Git 倉庫，一旦倉庫權限配置不當、人員誤操作、日志暴露或歷史提交泄露，就可能造成安全問題。

所以，配置中心不僅要解決“配置統(tǒng)一管理”，還要解決“敏感配置如何安全存儲”。Spring Cloud Config 的加密機制就是為這個問題服務的。

它的基本思路是：Git 倉庫里不直接保存明文密碼，而是保存以 {cipher} 開頭的密文。Config Server 讀取配置時識別到 {cipher} 前綴，就在返回給 Config Client 前完成解密。這樣，倉庫里是密文，業(yè)務服務拿到的是正常可用的明文配置。

加密與解密端點

Config Server 提供 /encrypt 和 /decrypt 兩個端點。/encrypt 用來把明文變成密文，/decrypt 用來驗證密文是否可以正確還原。

例如，把一個明文密碼加密：

curl localhost:8888/encrypt -s -d mysecret

返回的密文需要加上 {cipher} 前綴后寫入配置文件。

spring:
  datasource:
    username: appuser
    password: '{cipher}682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda'

如果使用 .properties 文件，加密值不要再額外加引號，否則可能影響解密。

spring.datasource.password={cipher}682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

/decrypt 常用于本地驗證密文是否正確。

curl localhost:8888/decrypt -s -d 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda

如果 Config Server 解密失敗，它不會簡單地把錯誤密文當成密碼繼續(xù)使用，而是可能生成帶 invalid 前綴的屬性。這種設計是為了避免密文被誤當成真實密碼傳給客戶端。

對稱加密

對稱加密的特點是加密和解密使用同一個密鑰。它的優(yōu)點是配置簡單，非常適合學習和本地 demo。Config Server 只需要知道這個共享密鑰，就能完成 /encrypt 和 /decrypt。

encrypt:
  key: mysecretkey

也可以用環(huán)境變量保存密鑰，避免把密鑰寫死在配置文件中。

ENCRYPT_KEY=mysecretkey

對稱加密的風險也來自這個“同一個密鑰”。因為加密和解密都依賴它，一旦密鑰泄露，別人就可以解密所有使用這個密鑰生成的配置密文。所以對稱加密雖然方便，但在生產(chǎn)環(huán)境中要非常重視密鑰的存放和權限控制。

非對稱加密

非對稱加密使用一對密鑰：公鑰和私鑰。通?？梢杂霉 €加密，用私鑰解密。它比對稱加密更適合正式環(huán)境，因為加密能力和解密能力可以分離，密鑰管理也更規(guī)范。

在 Spring Cloud Config 中，非對稱加密通常通過 keystore 配置?？梢杂?JDK 自帶的 keytool 創(chuàng)建測試密鑰庫。

keytool -genkeypair -alias mytestkey -keyalg RSA \
  -keystore server.jks

更完整的測試命令可以包含密碼和證書信息。

keytool -genkeypair -alias mytestkey -keyalg RSA \
  -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" \
  -keypass changeme -keystore server.jks -storepass letmein

把生成的 server.jks 放到 Config Server 的 classpath 下，然后配置 keystore 信息。

encrypt:
  keyStore:
    location: classpath:/server.jks
    password: letmein
    alias: mytestkey
    secret: changeme

這里的 location 指向密鑰庫位置，password 用于打開密鑰庫，alias 指定使用哪個密鑰，secret 是密鑰自身的密碼。相比對稱加密，非對稱加密配置更復雜，但安全邊界更清晰。

復習總結

Spring Cloud Config 的知識鏈路可以從“配置管理”一路推到“自動刷新”和“安全加密”。

最開始的問題是微服務配置太分散，所以引入 Config Server 和 Config Client。Config Server 統(tǒng)一讀取配置，Config Client 啟動時拉取配置。配置集中之后，又會遇到運行時變更不生效的問題，所以引入刷新機制。手動刷新在多實例場景下成本高，于是使用 Webhook 發(fā)現(xiàn)配置倉庫變化，再通過 Spring Cloud Bus 把刷新事件廣播給所有相關客戶端。配置集中管理后，敏感信息也被集中存儲，因此還需要加密機制。Config Server 通過 {cipher}、/encrypt、/decrypt、對稱密鑰或非對稱密鑰庫來保護敏感配置。

簡化記憶如下：