第 17 章：配置中心

这是《Spring Boot 与 Spring Cloud 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 配置中心把配置从应用包和本机环境中抽离，提供集中管理、多环境隔离、动态刷新、审计和回滚能力。它是微服务治理的基础组件之一。

17.1 为什么需要配置中心

没有配置中心时：

1. 每台机器维护配置文件；
2. 发布后才能改配置；
3. 环境差异容易出错；
4. 配置变更无审计；
5. 密钥散落；
6. 多服务开关难以统一。

集中配置模型：

配置中心
  |-- dev / test / prod
  |-- order-service.yaml
  |-- inventory-service.yaml
  +-- shared-common.yaml

应用启动拉取配置
运行时订阅变更

17.2 配置分类

不是所有配置都适合动态刷新。连接类、线程池核心参数、复杂拓扑变更通常应重启验证。

17.3 常见方案

选择考虑：

1. 是否需要审批发布；
2. 是否需要灰度；
3. 多数据中心支持；
4. 权限模型；
5. 客户端复杂度；
6. 与现有平台整合；
7. 审计合规。

17.4 Spring Cloud Config

服务端：

server:
  port: 8888
spring:
  cloud:
    config:
      server:
        git:
          uri: https://git.example.com/config/order-config.git
          search-paths: '{application}'
          default-label: main

客户端：

spring:
  application:
    name: order-service
  cloud:
    config:
      uri: https://config.example.com
      label: main
      fail-fast: true

配置仓库文件：

order-service.yml
order-service-prod.yml
application.yml

Spring Cloud Config 的配置通常通过 Git 提交保留版本历史，也可通过消息总线触发刷新。

17.5 Nacos Config

依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

配置：

spring:
  application:
    name: order-service
  cloud:
    nacos:
      config:
        server-addr: nacos.example.com:8848
        namespace: prod
        group: TRADE_GROUP
        file-extension: yaml

Nacos 支持多 dataId 优先级、扩展配置和共享配置。不同版本行为有差异，应统一客户端版本并验证加载顺序。

17.6 动态刷新

启用：

@RefreshScope
@Component
public class RiskProperties {
    @Value("${risk.enabled:false}")
    private boolean enabled;
}

触发刷新：

curl -X POST http://localhost:8080/actuator/refresh

刷新流程：

配置中心变更
  -> 客户端感知
  -> Environment 重新绑定
  -> @RefreshScope Bean 销毁重建
  -> 下次访问使用新值

注意：

1. singleton Bean 中的字段不会自动重建；
2. @ConfigurationProperties 通常更适合动态更新；
3. RefreshScope Bean 中不应保存重要状态；
4. 刷新可能触发 Bean 重建开销；
5. 需要记录刷新事件。

更稳妥的业务开关可以使用内存快照：

@Component
public class FeatureFlags {
    private final AtomicReference<Map<String, Boolean>> flags =
            new AtomicReference<>(Map.of());

    public void update(Map<String, Boolean> next) {
        flags.set(Map.copyOf(next));
    }

    public boolean enabled(String key) {
        return flags.get().getOrDefault(key, false);
    }
}

17.7 配置优先级

常见顺序：

命令行
环境变量
配置中心
本地 application-{profile}.yml
application.yml
默认值

真实优先级由 PropertySource 顺序决定，配置中心客户端可能在启动早期插入。排查时应查看 Environment：

/actuator/env

团队规范：

1. 一个配置只有一个来源；
2. 环境差异放环境维度；
3. 公共默认值放共享配置；
4. 特殊覆盖显式说明；
5. 不重复配置同一个键。

17.8 灰度发布

配置灰度策略：

按实例灰度：实例 A/B 使用 beta 配置
按集群灰度：先测试集群，再全量
按用户灰度：配置平台 + 应用规则

要求：

1. 配置带版本号；
2. 可快速回滚；
3. 观察指标；
4. 限制灰度范围；
5. 记录操作人；
6. 支持一键全量或回退。

17.9 配置安全

风险：

1. 配置中心账号权限过宽；
2. 明文密码；
3. env 端点暴露；
4. Git 仓库泄露；
5. 变更无审计；
6. 谁都可以修改限流阈值。

建议：

1. 按命名空间、Group、应用授权；
2. 密钥使用 Vault、KMS 或云 Secret；
3. 配置加密传输和存储；
4. 变更审批和审计；
5. 只读账号给只读场景；
6. 生产修改双人确认；
7. 日志脱敏；
8. 定期轮转密钥。

17.10 配置治理

配置模板：

app:
  feature:
    new-order-flow: false
  ratelimit:
    create-order-qps: 100
  downstream:
    pay:
      timeout: 3s
      retry: 2

上线检查：

1. 必需键校验；
2. 默认值安全；
3. 环境隔离；
4. 版本记录；
5. 回滚脚本；
6. 监控指标；
7. 变更通知；
8. 契约文档。

本章小结

配置中心提供集中管理、环境隔离、动态刷新、审计和灰度能力。配置应分为静态、动态和密钥三类，动态配置要有明确刷新语义和安全边界。生产变更必须具备版本、审计、灰度和回滚机制，密钥应交给专门密钥系统管理。

思考题

1. 哪些配置不适合动态刷新？
2. @RefreshScope 的副作用是什么？
3. 如何确认一个配置最终来自哪里？
4. 配置灰度和服务发布灰度有什么差异？
5. 配置中心高可用如何设计？