Spring Cloud Config 与 Bus 实战——配置热更新、加密配置、多环境管理

适读人群：使用 Spring Cloud Config 或计划引入配置中心的后端工程师 | 阅读时长：约16分钟 | 核心价值：配置中心的完整落地方案，覆盖热更新、安全、多环境三大核心场景

---

那次让我记忆深刻的配置泄露

2021 年，我认识的一个创业公司 CTO 小赵给我打电话，语气很着急。他们公司的数据库密码被人拿到了，正在排查泄露源头。最后查清楚了：开发同学把包含数据库密码的 application.yml 提交到了 Git 仓库，而仓库是 public 的。

更糟糕的是，他们的生产、预发、测试环境用的是同一个数据库密码。一个环境泄露，所有环境全线告急。

"当时要是用了配置加密，密码就算提交上去也没事。"小赵后来复盘时说。

这个事故给我的教训很深：配置管理不只是"方便改配置"，更是安全基础设施的一部分。今天这篇，把 Spring Cloud Config + Bus 的核心能力完整过一遍，重点讲热更新、加密配置和多环境管理。

---

一、Spring Cloud Config 核心架构

Spring Cloud Config 的架构很简单：

• Config Server：统一的配置服务，从 Git/文件系统/Vault 读取配置，通过 HTTP API 对外暴露
• Config Client：各微服务作为 Config Client，启动时从 Config Server 拉取配置
• Spring Cloud Bus：基于消息中间件（RabbitMQ/Kafka）的事件总线，用于触发配置刷新通知

Git 仓库
    ↓ (存储配置文件)
Config Server（Config 服务端）
    ↓ (HTTP API 提供配置)
微服务 A、B、C（Config 客户端）
    ↑
Spring Cloud Bus（广播刷新事件）
    ↑
Webhook（Git 提交时触发）

1.1 Config Server 搭建

// Config Server 启动类
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

# Config Server 的 application.yml
server:
  port: 8888

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-org/config-repo
          username: ${GIT_USERNAME}      # 从环境变量读取，不要硬编码
          password: ${GIT_PASSWORD}
          default-label: main            # 默认分支
          search-paths:                  # 配置文件搜索路径
            - '{application}'            # 按应用名分目录
          clone-on-start: true           # 启动时克隆，而不是等到第一次请求
          force-pull: true               # 每次都强制从 Git 拉取，避免本地缓存脏数据

# Config Server 自身的安全配置（用 Spring Security 保护）
spring:
  security:
    user:
      name: ${CONFIG_SERVER_USER:admin}
      password: ${CONFIG_SERVER_PASSWORD}

---

二、配置热更新：Bus 的正确打开方式

2.1 没有 Bus 的刷新

如果不用 Bus，手动触发刷新需要调用每个服务实例的 /actuator/refresh 端点。10 个实例就要调 10 次，50 个实例就要调 50 次——完全不可维护。

2.2 引入 Bus 的自动刷新

Bus 提供了一个广播机制：任意一个服务（通常是 Config Server）接收到刷新信号后，把刷新事件发布到消息总线，所有订阅了这个 Topic 的客户端都会收到刷新通知并重新拉取配置。

<!-- Config Client 依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<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 Client 的 application.yml
spring:
  config:
    import: "configserver:http://config-server:8888"
  cloud:
    config:
      username: admin
      password: ${CONFIG_SERVER_PASSWORD}
    bus:
      enabled: true
  rabbitmq:
    host: rabbitmq-server
    port: 5672
    username: ${MQ_USERNAME}
    password: ${MQ_PASSWORD}

management:
  endpoints:
    web:
      exposure:
        include: busrefresh,health,info  # 暴露 busrefresh 端点

刷新所有服务的配置，只需要调用 Config Server 的一个端点：

# 刷新所有服务的配置
POST http://config-server:8888/actuator/busrefresh

# 只刷新特定服务
POST http://config-server:8888/actuator/busrefresh/order-service

# 只刷新特定实例
POST http://config-server:8888/actuator/busrefresh/order-service:8080

踩坑一：@RefreshScope 的 Bean 重建开销

现象：触发配置刷新后，某些接口出现短暂的延迟飙升，甚至偶发 NPE。

原因：@RefreshScope 的 Bean 在刷新时会被销毁并重新创建。如果这个 Bean 的初始化操作很重（比如创建数据库连接池、加载大量数据），重建时间会很长；如果其他 Bean 在这段时间内调用了它，可能拿到 null 或者半初始化状态。

解法：

1. 尽量只在轻量级的配置 Bean 上使用 @RefreshScope，重型 Bean 不要用
2. 对真正需要动态刷新的配置，考虑直接注入 Environment 对象而不是 @Value，Environment 本身是刷新感知的

// 更安全的动态配置获取方式
@Component
public class DynamicConfigService {
    
    @Autowired
    private Environment environment;
    
    // 不用 @Value，直接从 Environment 读取
    // 每次调用都会获取最新值，无需 @RefreshScope
    public int getRateLimit() {
        return Integer.parseInt(
            environment.getProperty("rate.limit", "100"));
    }
    
    public boolean isFeatureEnabled(String featureName) {
        return Boolean.parseBoolean(
            environment.getProperty("feature." + featureName + ".enabled", "false"));
    }
}

---

三、加密配置：把明文密码从配置文件里消灭

3.1 对称加密方案

Config Server 内置了加密/解密能力，支持对称加密（AES）和非对称加密（RSA）。

对称加密配置简单，适合小团队：

# Config Server 的 bootstrap.yml（必须是 bootstrap，加密密钥要在最早阶段加载）
encrypt:
  key: ${ENCRYPT_KEY}  # 从环境变量读取，绝对不能硬编码在配置文件里

加密一个配置值：

# 调用 Config Server 的加密端点
curl -X POST http://admin:password@config-server:8888/encrypt -d 'my-database-password'
# 返回：AQBkKJ1234567890abcdef...（加密后的密文）

在 Git 配置文件中使用加密值：

# config-repo/order-service-prod.yml
spring:
  datasource:
    password: '{cipher}AQBkKJ1234567890abcdef...'  # {cipher} 前缀告诉 Config Server 这是加密值
    username: '{cipher}AQBkKJ0987654321fedcba...'

Config Server 在把配置返回给客户端之前，会自动解密 {cipher} 前缀的值。客户端拿到的是明文。

踩坑二：加密密钥轮换问题

现象：需要轮换加密密钥（安全审计要求定期更换），但历史配置都用旧密钥加密了。

原因：旧密钥加密的配置值在新密钥下无法解密。

解法：密钥轮换必须分步进行：

1. 用旧密钥解密所有现有配置值，得到明文
2. 用新密钥重新加密所有明文，得到新的密文
3. 更新 Git 仓库中的配置文件
4. 更新 Config Server 的密钥配置并重启

这个过程最好写成自动化脚本，一次性完成，避免漏掉某个配置。

3.2 生产级安全建议

对于安全要求较高的场景，推荐使用 HashiCorp Vault 作为配置后端，而不是 Git + 加密：

spring:
  cloud:
    config:
      server:
        vault:
          host: vault-server
          port: 8200
          scheme: https
          authentication: APPROLE
          app-role:
            role-id: ${VAULT_ROLE_ID}
            secret-id: ${VAULT_SECRET_ID}

Vault 提供动态密钥（数据库密码定期自动轮换）、细粒度权限控制、完整的审计日志，是企业级配置安全的最佳实践。

---

四、多环境管理：Profile 的正确用法

4.1 配置文件命名规范

Config Server 按照以下规则查找配置文件（按优先级从高到低）：

{application}-{profile}.yml    # 最高优先级
{application}.yml              # 次优先级
application-{profile}.yml      # 公共配置（含 profile）
application.yml                # 最低优先级的公共配置

config-repo/
├── application.yml             # 所有服务公共配置（日志格式、监控端点等）
├── application-prod.yml        # 所有服务 prod 环境公共配置
├── order-service.yml           # order-service 专属配置（所有环境共用）
├── order-service-dev.yml       # order-service 开发环境配置
├── order-service-test.yml      # order-service 测试环境配置
└── order-service-prod.yml      # order-service 生产环境配置

踩坑三：配置覆盖顺序理解错误

现象：修改了 application.yml 里的一个配置，但服务读取的值没变。

原因：order-service.yml 里有相同的配置项，由于优先级更高，覆盖了 application.yml 的值。

解法：建立明确的配置分层原则：

• application.yml：全局默认值，任何服务都应该能用的基础配置
• {service}.yml：服务专属配置，与环境无关的配置（比如服务描述信息）
• {service}-{profile}.yml：服务的环境特定配置（数据库连接、密钥、功能开关）

服务特定配置不应该覆盖公共配置里的基础框架配置，避免混乱。

4.2 多 Profile 激活

# 客户端配置
spring:
  profiles:
    active: ${SPRING_PROFILES_ACTIVE:dev}  # 从环境变量读取，默认 dev
  config:
    import: "configserver:http://config-server:8888"
  cloud:
    config:
      profile: ${spring.profiles.active}   # 告诉 Config Server 要哪个 profile 的配置

---

五、高可用配置

Config Server 是所有服务的配置依赖，它宕机会影响新启动的服务。生产必须做高可用。

# 多个 Config Server 实例，通过 Nacos 注册发现
spring:
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server  # 从注册中心找 Config Server，而不是硬编码地址
      fail-fast: true              # Config Server 不可用时快速失败，而不是启动后报错
      retry:
        initial-interval: 1000
        max-interval: 5000
        max-attempts: 6            # 最多重试 6 次，给 Config Server 恢复时间

同时，客户端要配置本地兜底配置文件，防止 Config Server 不可用时服务无法启动：

# 本地 application.yml 作为兜底
spring:
  cloud:
    config:
      fail-fast: false             # 开发环境关闭 fail-fast，允许 Config Server 不可用时用本地配置

配置中心是基础设施，要像对待数据库一样认真对待它的高可用和安全性。