配置中心：让改动"秒级生效"

系列七：基础设施篇 · 第3篇

你有没有经历过这样的场景：为了改一个超时时间，需要重新打包、重新部署、重新上线？一个简单的参数调整，却要折腾半小时甚至更久？

配置中心就是为了解决这个问题而生的。它让配置变更从"发布级"变成"秒级"，让运维从"重启大法"变成"一键生效"。

今天我们来聊聊配置中心的设计原理，看看它是如何让改动"秒级生效"的。

一、配置管理的演进

1.1 硬编码时代

最原始的方式，配置直接写死在代码里：

const int MAX_RETRY = 3;
const int TIMEOUT_MS = 5000;

这种方式最简单，但问题也最明显：

• 改一个数字就要改代码、重新编译、重新部署
• 不同环境需要不同的值，怎么处理？
• 敏感信息（密码、密钥）直接暴露在代码仓库里

🎯 真实案例：某电商团队为了改一个支付超时时间，经历了代码提交 → Code Review → 打包 → 测试环境验证 → 预发布验证 → 生产发布，整整折腾了 2 天。结果超时时间从 5 秒改成 8 秒，就这一行改动。

1.2 配置文件时代

把配置抽离到外部文件：

# config.properties
max.retry=3
timeout.ms=5000
db.url=jdbc:mysql://localhost:3306/mydb

进步了一点，但还是有问题：

• 配置文件打包在应用里，修改还是要重新部署
• 多个服务需要同步同一份配置怎么办？
• 配置文件散落在各处，难以统一管理

1.3 环境变量时代

用环境变量注入配置：

export MAX_RETRY=3
export TIMEOUT_MS=5000
export DB_URL=jdbc:mysql://prod-db:3306/mydb

配合容器化部署，灵活了很多。但：

• 环境变量数量有限制（通常几 KB 到几十 KB）
• 复杂的嵌套配置难以表达
• 修改后仍需重启容器才能生效

1.4 配置中心时代

配置中心的核心理念：配置也是一种服务。

• 配置集中存储、统一管理
• 配置变更实时推送、无需重启
• 支持多环境、多版本、多租户
• 提供审计、回滚、权限控制

这就像从"每个人自己做饭"进化到"中央厨房统一配送"——标准化、高效率、可追溯。

二、配置中心的核心设计原理

2.1 整体架构

配置中心采用分层架构设计：

┌─────────────────────────────────────────────────────────┐
│                    配置管理控制台                        │
│              (Web UI / API)                             │
│    ┌─────────────┬─────────────┬─────────────┐         │
│    │  配置编辑    │  版本管理    │  权限管理    │         │
│    └─────────────┴─────────────┴─────────────┘         │
└────────────────────────┬────────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────────┐
│                  配置服务层                              │
│              (Config Server Cluster)                    │
│    ┌─────────────┬─────────────┬─────────────┐         │
│    │  配置读写    │  变更推送    │  SDK 接入    │         │
│    └─────────────┴─────────────┴─────────────┘         │
└────────────────────────┬────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│  MySQL 集群    │ │  Redis 集群   │ │  备份存储     │
│ (配置存储)     │ │ (变更通知)    │ │ (版本控制)    │
└───────────────┘ └───────────────┘ └───────────────┘
        │                │                │
        └────────────────┴────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐      ┌─────────┐      ┌─────────┐
   │ 应用 A  │      │ 应用 B  │      │ 应用 C  │
   │ SDK     │      │ SDK     │      │ SDK     │
   └─────────┘      └─────────┘      └─────────┘

2.2 核心组件详解

配置服务端是整个系统的大脑，负责：

• 配置管理：提供 RESTful API 接口，处理配置的 CRUD 操作
• 变更推送：管理客户端连接，实时推送配置变更
• 权限控制：验证客户端身份，授权配置访问
• 高可用保障：集群部署，故障自动切换

// 配置服务端核心接口示例
@RestController
@RequestMapping("/api/v1/configs")
public class ConfigController {
    
    // 获取配置
    @GetMapping("/{appId}/{env}/{namespace}")
    public ConfigResponse getConfig(
        @PathVariable String appId,
        @PathVariable String env,
        @PathVariable String namespace,
        @RequestHeader("Authorization") String token) {
        
        // 1. 验证权限
        if (!authService.hasPermission(token, appId, env)) {
            throw new ForbiddenException("No permission");
        }
        
        // 2. 获取配置（带缓存）
        Config config = configService.getConfig(appId, env, namespace);
        
        // 3. 返回配置内容和版本号
        return ConfigResponse.builder()
            .config(config.getContent())
            .version(config.getVersion())
            .releaseKey(config.getReleaseKey())
            .build();
    }
    
    // 发布配置
    @PostMapping("/{appId}/{env}/{namespace}/release")
    public ReleaseResponse releaseConfig(
        @PathVariable String appId,
        @PathVariable String env,
        @PathVariable String namespace,
        @RequestBody ReleaseRequest request) {
        
        // 1. 生成新版本号
        long newVersion = versionGenerator.next();
        
        // 2. 持久化配置
        configService.release(appId, env, namespace, 
            request.getConfigs(), newVersion, request.getOperator());
        
        // 3. 通知所有订阅的客户端
        notificationService.notify(appId, env, namespace, newVersion);
        
        return ReleaseResponse.success(newVersion);
    }
}

客户端 SDK 嵌入到业务应用中，是配置中心的触角：

// 客户端 SDK 使用示例
public class ConfigClientExample {
    
    public static void main(String[] args) {
        // 初始化配置客户端
        ConfigService configService = ConfigService.getAppConfig(
            "my-app",                    // 应用 ID
            "prod",                      // 环境
            new ConfigChangeListener() { // 变更监听器
                @Override
                public void onChange(ConfigChangeEvent event) {
                    // 配置变更回调
                    for (String key : event.changedKeys()) {
                        ConfigChange change = event.getChange(key);
                        System.out.println(String.format(
                            "配置 %s 从 %s 变更为 %s",
                            key, change.getOldValue(), change.getNewValue()));
                        
                        // 动态调整连接池大小
                        if ("db.pool.size".equals(key)) {
                            int newSize = Integer.parseInt(change.getNewValue());
                            connectionPool.resize(newSize);
                        }
                    }
                }
            });
        
        // 获取配置值
        int timeout = configService.getIntProperty("request.timeout", 5000);
        String dbUrl = configService.getProperty("db.url", "localhost:3306");
    }
}

存储层是配置中心的基石：

• 配置数据：存储在 MySQL（易查询、易备份）
• 变更通知：使用 Redis PubSub（实时推送）
• 版本历史：定期备份到对象存储（审计追溯）

2.3 配置模型设计

一个灵活的配置模型需要考虑多个维度：

配置中心
├── 命名空间（Namespace）
│   ├── dev（开发环境）
│   │   ├── 应用 A
│   │   │   ├── application.yml（主配置）
│   │   │   ├── db.yml（数据库配置）
│   │   │   └── redis.yml（缓存配置）
│   │   └── 应用 B
│   ├── test（测试环境）
│   ├── uat（预发布环境）
│   └── prod（生产环境）

# 配置项示例
db:
  url: jdbc:mysql://prod-db:3306/mydb
  username: app_user
  password: ${DB_PASSWORD}  # 支持占位符
  pool:
    max_size: 100
    min_idle: 10
    
cache:
  type: redis
  hosts:
    - redis-1:6379
    - redis-2:6379
    - redis-3:6379
  timeout_ms: 3000

三、配置的热更新机制

配置中心最核心的能力：配置变更后，应用无需重启即可生效。我们实现了 3 秒内配置生效 的能力。这是如何实现的？

3.1 推拉结合模式

配置同步采用推拉结合的最佳实践：

┌─────────┐                        ┌─────────┐
│  Client │                        │  Server │
└────┬────┘                        └────┬────┘
     │                                  │
     │  1. 建立长连接                    │
     │ ═════════════════════════════> │
     │                                  │
     │  2. 收到变更通知（只通知版本号）    │
     │ <══════════════════════════════ │
     │                                  │
     │  3. 主动拉取最新配置              │
     │ ──────────────────────────────> │
     │                                  │
     │        4. 返回完整配置内容        │
     │ <────────────────────────────── │
     │                                  │

1. 通知轻量化：推送只发送版本号，数据量极小
2. 可靠性保障：即使长连接断开，客户端可以定时轮询兜底
3. 负载可控：客户端收到通知后主动拉取，服务端无需维护推送队列
4. 3秒生效：从配置发布到客户端生效，全程不超过 3 秒

3.2 长连接的实现方案

// 长轮询实现示例
@GetMapping("/notifications")
public DeferredResult<ConfigNotification> longPollNotification(
    @RequestParam String appId,
    @RequestParam String env,
    @RequestParam long currentVersion) {
    
    // 设置超时时间 30 秒
    DeferredResult<ConfigNotification> result = 
        new DeferredResult<>(30000L, "No changes");
    
    // 注册监听器
    notificationRegistry.register(appId, env, currentVersion, notification -> {
        // 有变更时立即返回
        result.setResult(notification);
    });
    
    // 超时或完成时移除监听器
    result.onCompletion(() -> {
        notificationRegistry.unregister(appId, env);
    });
    
    return result;
}

3.3 配置更新的原子性保证

配置更新必须保证原子性：要么全部生效，要么全部不生效。

假设需要同时更新数据库连接地址和密码：

# 原配置
db:
  url: jdbc:mysql://old-db:3306/mydb
  password: old_password

# 目标配置
db:
  url: jdbc:mysql://new-db:3306/mydb
  password: new_password

如果只更新了 url，密码还是旧的 → 连接失败！ 如果只更新了密码，url 还是旧的 → 同样失败！

public class ConfigManager {
    
    private volatile ConfigSnapshot currentConfig;
    private final AtomicLong configVersion = new AtomicLong(0);
    
    // 配置更新（原子操作）
    public void updateConfig(ConfigSnapshot newSnapshot) {
        // 1. 校验版本号（防止乱序）
        if (newSnapshot.getVersion() <= configVersion.get()) {
            return; // 忽略旧版本
        }
        
        // 2. 加载新配置到临时变量
        Map<String, String> newConfigs = newSnapshot.getConfigs();
        
        // 3. 验证配置完整性
        if (!validateConfig(newConfigs)) {
            throw new ConfigValidationException("Invalid config");
        }
        
        // 4. 原子替换（volatile 保证可见性）
        currentConfig = newSnapshot;
        configVersion.set(newSnapshot.getVersion());
        
        // 5. 触发回调通知
        notifyConfigChange(newSnapshot);
    }
    
    // 获取配置（线程安全）
    public String getConfig(String key) {
        return currentConfig.get(key);
    }
}

1. 版本号机制：每次发布生成新版本，客户端按版本号整体替换
2. 双缓冲切换：先加载到新 buffer，验证通过后一次性切换指针
3. volatile 保证可见性：确保所有线程立即看到新配置

3.4 灰度发布与回滚

配置变更也有风险，需要支持灰度和回滚。

┌────────────────────────────────────────────────────────┐
│                    灰度发布流程                         │
└────────────────────────────────────────────────────────┘
                         │
                         ▼
        ┌────────────────────────────────┐
        │  1. 选择灰度实例（按 IP/标签）   │
        │     例如：web-server-[01-03]   │
        └────────────────┬───────────────┘
                         ▼
        ┌────────────────────────────────┐
        │  2. 发布新配置到灰度实例         │
        │     观察监控指标 5-10 分钟      │
        └────────────────┬───────────────┘
                         ▼
              ┌──────────┴──────────┐
              │                     │
              ▼                     ▼
        ┌──────────┐          ┌──────────┐
        │  异常？   │          │  正常？   │
        └────┬─────┘          └────┬─────┘
             │                     │
             ▼                     ▼
    ┌────────────────┐    ┌────────────────┐
    │  立即回滚       │    │  扩大灰度范围   │
    │  分析原因       │    │  或全量发布     │
    └────────────────┘    └────────────────┘

@Service
public class GrayReleaseService {
    
    // 灰度发布
    public ReleaseResult grayRelease(GrayReleaseRequest request) {
        String appId = request.getAppId();
        String env = request.getEnv();
        List<String> grayInstances = request.getGrayInstances();
        long newVersion = request.getNewVersion();
        
        // 1. 标记灰度实例
        for (String instance : grayInstances) {
            instanceRegistry.markGray(appId, env, instance, newVersion);
        }
        
        // 2. 推送新配置到灰度实例
        notificationService.notifyInstances(appId, env, grayInstances, newVersion);
        
        // 3. 创建灰度监控任务
        monitorService.createGrayMonitor(appId, env, newVersion, 
            grayInstances, request.getMonitorDuration());
        
        return ReleaseResult.grayStarted(newVersion, grayInstances);
    }
    
    // 全量发布（灰度验证通过后）
    public ReleaseResult fullRelease(String appId, String env, long version) {
        // 1. 清除灰度标记
        instanceRegistry.clearGray(appId, env);
        
        // 2. 全量推送
        notificationService.notifyAll(appId, env, version);
        
        return ReleaseResult.fullReleased(version);
    }
    
    // 一键回滚
    public ReleaseResult rollback(String appId, String env, long targetVersion) {
        // 1. 获取目标版本配置
        ConfigSnapshot targetConfig = configRepository.getVersion(appId, env, targetVersion);
        
        // 2. 发布为最新版本
        long newVersion = versionGenerator.next();
        configRepository.release(appId, env, targetConfig.getConfigs(), newVersion);
        
        // 3. 全量推送
        notificationService.notifyAll(appId, env, newVersion);
        
        // 4. 记录回滚操作
        auditService.log(AuditAction.ROLLBACK, appId, env, newVersion, 
            "Rollback to version " + targetVersion);
        
        return ReleaseResult.rolledBack(newVersion, targetVersion);
    }
}

四、多环境管理方案

一个应用通常要经历多个环境：开发、测试、预发布、生产。每个环境的配置都不尽相同。

4.1 环境隔离策略

┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│  Dev Config     │   │  Test Config    │   │  Prod Config    │
│  Cluster        │   │  Cluster        │   │  Cluster        │
│                 │   │                 │   │                 │
│  configcenter   │   │  configcenter   │   │  configcenter   │
│  -dev           │   │  -test          │   │  -prod          │
└─────────────────┘   └─────────────────┘   └─────────────────┘
        │                     │                     │
        ▼                     ▼                     ▼
   ┌─────────┐          ┌─────────┐          ┌─────────┐
   │ Dev App │          │Test App │          │Prod App │
   └─────────┘          └─────────┘          └─────────┘

• 完全隔离，配置泄露风险最小
• 可以针对不同环境定制部署策略
• 生产环境独立，性能不受测试影响

• 运维成本高（3 套集群）
• 配置同步困难（公共配置需要复制 3 份）

┌────────────────────────────────────────────────────────┐
│                 统一配置中心集群                        │
│                                                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐            │
│  │  dev     │  │  test    │  │  prod    │            │
│  │ namespace│  │ namespace│  │ namespace│            │
│  └──────────┘  └──────────┘  └──────────┘            │
└────────────────────────────────────────────────────────┘

• 运维成本低（1 套集群）
• 公共配置易于共享

• 需要严格的权限控制
• 生产环境配置可能被误改

┌─────────────────────────────────┐   ┌─────────────────┐
│  Non-Prod Config Cluster        │   │  Prod Config    │
│  (Dev + Test + UAT)             │   │  Cluster        │
│                                 │   │                 │
│  ┌──────────┐  ┌──────────┐    │   │  ┌──────────┐  │
│  │  dev     │  │  test    │    │   │  │  prod    │  │
│  │  ns      │  │  ns      │    │   │  │  ns      │  │
│  └──────────┘  └──────────┘    │   │  └──────────┘  │
└─────────────────────────────────┘   └─────────────────┘

• 生产环境独立部署，安全可控
• 非生产环境共享资源，降低成本
• 公共配置通过 CI/CD 同步

4.2 配置继承与覆盖

不同环境的配置有大量相同部分，如何避免重复？

# base.yml - 基础配置（所有环境共享）
app:
  name: my-service
  version: 1.0.0

logging:
  level: INFO
  format: "%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n"

features:
  enable_cache: true
  enable_metrics: true

---
# dev.yml - 开发环境配置（继承 base.yml）
extends: base.yml

overrides:
  logging:
    level: DEBUG  # 开发环境开启 DEBUG
  
  db:
    url: jdbc:mysql://localhost:3306/mydb_dev
    username: dev_user
    password: dev_password

---
# prod.yml - 生产环境配置（继承 base.yml）
extends: base.yml

overrides:
  logging:
    level: WARN  # 生产环境只记录 WARN 以上
  
  db:
    url: jdbc:mysql://prod-db-master:3306/mydb
    username: prod_user
    password: ${DB_PASSWORD}  # 从环境变量读取
    
  db:
    slaves:
      - url: jdbc:mysql://prod-db-slave-1:3306/mydb
      - url: jdbc:mysql://prod-db-slave-2:3306/mydb

环境特定配置 > 环境基础配置 > 全局默认配置

这样，公共配置只需维护一份，环境差异配置单独覆盖。

4.3 配置同步策略

当公共配置变更时，如何同步到所有环境？

简单但容易遗漏，适合小型团队。

# .github/workflows/sync-config.yml
name: Sync Base Config

on:
  push:
    paths:
      - 'configs/base.yml'

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      - name: Sync to all environments
        run: |
          # 读取 base.yml
          BASE_CONFIG=$(cat configs/base.yml)
          
          # 同步到开发环境
          curl -X PUT "https://configcenter.dev.internal/api/v1/configs/my-app/base" \
            -H "Authorization: ${{ secrets.CONFIG_CENTER_TOKEN_DEV }}" \
            -d "$BASE_CONFIG"
          
          # 同步到测试环境
          curl -X PUT "https://configcenter.test.internal/api/v1/configs/my-app/base" \
            -H "Authorization: ${{ secrets.CONFIG_CENTER_TOKEN_TEST }}" \
            -d "$BASE_CONFIG"
          
          # 同步到生产环境（需要审批）
          # 生产环境同步在单独的 workflow 中

configcenter 支持配置克隆和同步功能：

// 配置克隆示例
public void cloneConfig(String sourceEnv, String targetEnv, String appId) {
    // 1. 读取源环境配置
    Config sourceConfig = configService.getConfig(appId, sourceEnv, "application");
    
    // 2. 克隆到目标环境
    configService.createConfig(appId, targetEnv, "application", sourceConfig);
    
    // 3. 记录审计日志
    auditService.log(AuditAction.CLONE, appId, targetEnv, 
        "Cloned from " + sourceEnv);
}

五、高可用设计

配置中心是微服务架构的关键依赖，必须保证高可用。一旦配置中心宕机，可能导致所有服务无法启动或配置无法更新。

5.1 多层次容错机制

┌────────────────────────────────────────────────────────┐
│                    高可用架构                          │
└────────────────────────────────────────────────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐      ┌─────────┐      ┌─────────┐
   │Server-1 │      │Server-2 │      │Server-3 │
   │(Active) │      │(Active) │      │(Standby)│
   └────┬────┘      └────┬────┘      └────┬────┘
        │                │                │
        └────────────────┼────────────────┘
                         │
                         ▼
        ┌────────────────────────────────┐
        │      负载均衡（Nginx/SLB）      │
        └────────────────┬───────────────┘
                         │
        ┌────────────────┼────────────────┐
        ▼                ▼                ▼
   ┌─────────┐      ┌─────────┐      ┌─────────┐
   │ Client  │      │ Client  │      │ Client  │
   │ Local   │      │ Local   │      │ Local   │
   │ Cache   │      │ Cache   │      │ Cache   │
   └─────────┘      └─────────┘      └─────────┘

5.2 客户端容错设计

public class ConfigClient {
    
    private final ConfigServerProxy serverProxy;
    private final LocalConfigCache localCache;
    private final AtomicReference<ConfigSnapshot> currentConfig;
    
    // 获取配置（带容错）
    public String getConfig(String key) {
        // 1. 优先使用内存缓存
        ConfigSnapshot snapshot = currentConfig.get();
        if (snapshot != null && snapshot.contains(key)) {
            return snapshot.get(key);
        }
        
        // 2. 尝试从服务端获取
        try {
            ConfigSnapshot newSnapshot = serverProxy.fetchConfig();
            currentConfig.set(newSnapshot);
            localCache.persist(newSnapshot); // 持久化到本地
            return newSnapshot.get(key);
        } catch (Exception e) {
            log.warn("Failed to fetch config from server, use local cache", e);
            
            // 3. 服务端失败，使用本地文件缓存
            ConfigSnapshot cachedSnapshot = localCache.load();
            if (cachedSnapshot != null) {
                currentConfig.set(cachedSnapshot);
                return cachedSnapshot.get(key);
            }
            
            // 4. 完全失败，返回默认值
            return getDefaultConfig(key);
        }
    }
}

// 本地缓存实现
public class LocalConfigCache {
    
    private final String cacheDir = System.getProperty("user.home") + "/config-cache";
    
    // 持久化配置到本地
    public void persist(ConfigSnapshot snapshot) {
        String cacheFile = String.format("%s/%s-%s-%d.cache",
            cacheDir, snapshot.getAppId(), snapshot.getEnv(), snapshot.getVersion());
        
        try (ObjectOutputStream oos = new ObjectOutputStream(
                new FileOutputStream(cacheFile))) {
            oos.writeObject(snapshot);
        } catch (IOException e) {
            log.error("Failed to persist config cache", e);
        }
    }
    
    // 从本地加载配置
    public ConfigSnapshot load() {
        File[] cacheFiles = new File(cacheDir).listFiles((dir, name) -> 
            name.startsWith(appId + "-" + env) && name.endsWith(".cache"));
        
        if (cacheFiles == null || cacheFiles.length == 0) {
            return null;
        }
        
        // 加载最新的缓存文件
        Arrays.sort(cacheFiles, (a, b) -> extractVersion(b) - extractVersion(a));
        
        try (ObjectInputStream ois = new ObjectInputStream(
                new FileInputStream(cacheFiles[0]))) {
            return (ConfigSnapshot) ois.readObject();
        } catch (Exception e) {
            log.error("Failed to load config cache", e);
            return null;
        }
    }
}

public class ConfigClientWithFallback {
    
    // 获取配置（多级降级）
    public String getConfigWithFallback(String key, String defaultValue) {
        // Level 1: 内存缓存（最快）
        String value = memoryCache.get(key);
        if (value != null) {
            return value;
        }
        
        // Level 2: 服务端（实时）
        try {
            value = fetchFromServer(key);
            if (value != null) {
                memoryCache.put(key, value);
                return value;
            }
        } catch (Exception e) {
            log.warn("Server unavailable", e);
        }
        
        // Level 3: 本地文件缓存（容错）
        value = localCache.get(key);
        if (value != null) {
            return value;
        }
        
        // Level 4: 默认值（兜底）
        return defaultValue;
    }
}

5.3 服务端高可用设计

# docker-compose.yml - 配置中心集群部署
version: '3.8'

services:
  config-server-1:
    image: configcenter:latest
    environment:
      - SERVER_ID=1
      - CLUSTER_NODES=config-server-1:8080,config-server-2:8080,config-server-3:8080
      - DB_URL=jdbc:mysql://mysql-master:3306/config_center
      - REDIS_URL=redis://redis:6379
    ports:
      - "8081:8080"
    depends_on:
      - mysql-master
      - redis
      
  config-server-2:
    image: configcenter:latest
    environment:
      - SERVER_ID=2
      - CLUSTER_NODES=config-server-1:8080,config-server-2:8080,config-server-3:8080
      - DB_URL=jdbc:mysql://mysql-master:3306/config_center
      - REDIS_URL=redis://redis:6379
    ports:
      - "8082:8080"
    depends_on:
      - mysql-master
      - redis
      
  config-server-3:
    image: configcenter:latest
    environment:
      - SERVER_ID=3
      - CLUSTER_NODES=config-server-1:8080,config-server-2:8080,config-server-3:8080
      - DB_URL=jdbc:mysql://mysql-master:3306/config_center
      - REDIS_URL=redis://redis:6379
    ports:
      - "8083:8080"
    depends_on:
      - mysql-master
      - redis
      
  nginx:
    image: nginx:latest
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    ports:
      - "80:80"
    depends_on:
      - config-server-1
      - config-server-2
      - config-server-3

@RestController
public class HealthController {
    
    @GetMapping("/health")
    public HealthStatus health() {
        return HealthStatus.builder()
            .status("UP")
            .dbConnection(checkDbConnection())
            .cacheConnection(checkCacheConnection())
            .activeConnections(getActiveConnectionCount())
            .build();
    }
}

// Nginx 健康检查配置
upstream config_servers {
    server config-server-1:8080 max_fails=3 fail_timeout=30s;
    server config-server-2:8080 max_fails=3 fail_timeout=30s;
    server config-server-3:8080 max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://config_servers;
        proxy_next_upstream error timeout http_502 http_503 http_504;
    }
}

5.4 数据层高可用

┌──────────────┐        ┌──────────────┐
│ MySQL Master │───────>│ MySQL Slave  │
│ (读写)        │        │ (只读)        │
└──────────────┘        └──────────────┘
       ▲                       │
       │                       │
       └───────────────────────┘
         故障切换（VIP 或 Proxy）

// 数据库读写分离配置
public class DataSourceConfig {
    
    @Bean
    @Primary
    public DataSource masterDataSource() {
        return DataSourceBuilder.create()
            .url("jdbc:mysql://mysql-master:3306/config_center")
            .username("root")
            .password("${DB_PASSWORD}")
            .build();
    }
    
    @Bean
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create()
            .url("jdbc:mysql://mysql-slave:3306/config_center")
            .username("readonly")
            .password("${DB_PASSWORD}")
            .build();
    }
    
    @Bean
    public RoutingDataSource routingDataSource(
            @Qualifier("masterDataSource") DataSource master,
            @Qualifier("slaveDataSource") DataSource slave) {
        
        Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put("master", master);
        targetDataSources.put("slave", slave);
        
        RoutingDataSource routingDataSource = new RoutingDataSource();
        routingDataSource.setDefaultTargetDataSource(master);
        routingDataSource.setTargetDataSources(targetDataSources);
        
        return routingDataSource;
    }
}

# redis-sentinel.conf
sentinel monitor configcenter-redis redis-master 6379 2
sentinel down-after-milliseconds configcenter-redis 5000
sentinel failover-timeout configcenter-redis 60000
sentinel parallel-syncs configcenter-redis 1

六、配置安全

配置中往往包含敏感信息：数据库密码、API 密钥、证书等。安全是配置中心的重中之重。

6.1 传输安全

所有配置传输必须加密，防止中间人攻击：

# application.yml - 服务端 TLS 配置
server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:keystore.p12
    key-store-password: ${KEYSTORE_PASSWORD}
    key-store-type: PKCS12
    key-alias: configcenter

// 客户端证书验证
@Configuration
public class MutualTLSConfig {
    
    @Bean
    public ServletWebServerFactory servletWebServerFactory() {
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory();
        tomcat.addAdditionalTomcatConnectors(createSslConnector());
        return tomcat;
    }
    
    private Connector createSslConnector() {
        Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
        Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler();
        
        connector.setScheme("https");
        connector.setSecure(true);
        connector.setPort(8443);
        
        // 服务端证书
        protocol.setSSLEnabled(true);
        protocol.setKeystoreFile("/path/to/server-keystore.jks");
        protocol.setKeystorePass("password");
        
        // 客户端证书验证
        protocol.setTruststoreFile("/path/to/truststore.jks");
        protocol.setTruststorePass("password");
        protocol.setClientAuth("want"); // 可选验证
        // protocol.setClientAuth("true"); // 强制验证
        
        return connector;
    }
}

6.2 存储安全

// 配置加密服务
@Service
public class ConfigEncryptionService {
    
    private final EncryptionProvider encryptionProvider;
    
    // 加密配置值
    public String encrypt(String plainText) {
        return encryptionProvider.encrypt(plainText);
    }
    
    // 解密配置值
    public String decrypt(String cipherText) {
        return encryptionProvider.decrypt(cipherText);
    }
    
    // 加密整个配置文件
    public ConfigSnapshot encryptSensitiveConfigs(ConfigSnapshot config, 
            List<String> sensitiveKeys) {
        
        Map<String, String> encryptedConfigs = new HashMap<>();
        
        for (Map.Entry<String, String> entry : config.getConfigs().entrySet()) {
            if (isSensitive(entry.getKey(), sensitiveKeys)) {
                encryptedConfigs.put(entry.getKey(), encrypt(entry.getValue()));
            } else {
                encryptedConfigs.put(entry.getKey(), entry.getValue());
            }
        }
        
        return new ConfigSnapshot(config.getVersion(), encryptedConfigs);
    }
    
    private boolean isSensitive(String key, List<String> sensitiveKeys) {
        return sensitiveKeys.stream()
            .anyMatch(pattern -> key.matches(pattern));
    }
}

// 敏感配置 Key 的匹配规则
List<String> sensitivePatterns = Arrays.asList(
    ".*password.*",
    ".*secret.*",
    ".*token.*",
    ".*key.*",
    ".*credential.*"
);

// KMS 集成示例
@Service
public class KMSConfigEncryption implements ConfigEncryptionService {
    
    private final KmsClient kmsClient;
    private final String keyId;
    
    @Override
    public String encrypt(String plainText) {
        EncryptRequest request = EncryptRequest.builder()
            .keyId(keyId)
            .plaintext(ByteBuffer.wrap(plainText.getBytes()))
            .build();
        
        EncryptResult result = kmsClient.encrypt(request);
        return Base64.getEncoder().encodeToString(
            result.ciphertextBlob().array());
    }
    
    @Override
    public String decrypt(String cipherText) {
        ByteBuffer ciphertextBlob = ByteBuffer.wrap(
            Base64.getDecoder().decode(cipherText));
        
        DecryptRequest request = DecryptRequest.builder()
            .ciphertextBlob(ciphertextBlob)
            .build();
        
        DecryptResult result = kmsClient.decrypt(request);
        return new String(result.plaintext().array());
    }
}

6.3 访问控制

// 权限模型设计
public enum Permission {
    CONFIG_READ,        // 读取配置
    CONFIG_WRITE,       // 修改配置
    CONFIG_PUBLISH,     // 发布配置
    CONFIG_ROLLBACK,    // 回滚配置
    NAMESPACE_CREATE,   // 创建命名空间
    NAMESPACE_DELETE,   // 删除命名空间
}

public enum Role {
    VIEWER(Permission.CONFIG_READ),
    DEVELOPER(Permission.CONFIG_READ, Permission.CONFIG_WRITE),
    ADMIN(Permission.values());
    
    private final Set<Permission> permissions;
    
    Role(Permission... permissions) {
        this.permissions = EnumSet.copyOf(Arrays.asList(permissions));
    }
    
    public boolean hasPermission(Permission permission) {
        return permissions.contains(permission);
    }
}

// 权限检查拦截器
@Aspect
@Component
public class PermissionAspect {
    
    @Autowired
    private UserService userService;
    
    @Before("@annotation(requirePermission)")
    public void checkPermission(JoinPoint joinPoint, RequirePermission requirePermission) {
        // 获取当前用户
        String userId = SecurityContextHolder.getCurrentUserId();
        User user = userService.getUser(userId);
        
        // 检查权限
        Permission required = requirePermission.value();
        if (!user.getRole().hasPermission(required)) {
            throw new ForbiddenException(
                "User " + userId + " does not have permission: " + required);
        }
        
        // 记录审计日志
        auditService.log(userId, required, joinPoint.getSignature().toShortString());
    }
}

// 使用示例
@RestController
@RequestMapping("/api/v1/configs")
public class ConfigController {
    
    @RequirePermission(Permission.CONFIG_READ)
    @GetMapping("/{namespace}/{app}")
    public ConfigResponse getConfig(@PathVariable String namespace, 
                                    @PathVariable String app) {
        return configService.getConfig(namespace, app);
    }
    
    @RequirePermission(Permission.CONFIG_PUBLISH)
    @PostMapping("/{namespace}/{app}/release")
    public ReleaseResponse releaseConfig(@PathVariable String namespace,
                                         @PathVariable String app,
                                         @RequestBody ReleaseRequest request) {
        return configService.release(namespace, app, request);
    }
}

6.4 审计与监控

// 审计日志实体
@Entity
public class AuditLog {
    @Id
    @GeneratedValue
    private Long id;
    
    private String userId;          // 操作人
    private String action;          // 操作类型
    private String resourceType;    // 资源类型（配置/命名空间/应用）
    private String resourceId;      // 资源 ID
    private String detail;          // 操作详情
    private String clientIp;        // 客户端 IP
    private Instant timestamp;      // 操作时间
    
    // 敏感字段自动打码
    public String getDetail() {
        return maskSensitiveInfo(detail);
    }
    
    private String maskSensitiveInfo(String text) {
        return text.replaceAll("(password|secret|token)=[^&\\s]+", "$1=***");
    }
}

// 审计服务
@Service
public class AuditService {
    
    @Autowired
    private AuditLogRepository auditLogRepository;
    
    public void log(String userId, String action, String resourceType, 
                   String resourceId, String detail) {
        
        AuditLog log = new AuditLog();
        log.setUserId(userId);
        log.setAction(action);
        log.setResourceType(resourceType);
        log.setResourceId(resourceId);
        log.setDetail(detail);
        log.setClientIp(getCurrentClientIp());
        log.setTimestamp(Instant.now());
        
        auditLogRepository.save(log);
        
        // 敏感操作实时告警
        if (isSensitiveOperation(action)) {
            alertService.sendAlert(log);
        }
    }
    
    private boolean isSensitiveOperation(String action) {
        return Arrays.asList("CONFIG_PUBLISH", "CONFIG_DELETE", "ROLLBACK")
            .contains(action);
    }
}

# 告警规则配置
alert:
  rules:
    - name: 生产环境配置变更
      condition:
        env: prod
        action: CONFIG_PUBLISH
      channels:
        - type: feishu
          webhook: ${FEISHU_WEBHOOK_URL}
          at_users: ["ou_xxx", "ou_yyy"]
      
    - name: 敏感配置修改
      condition:
        config_key_pattern: ".*(password|secret|token).*"
        action: CONFIG_WRITE
      channels:
        - type: email
          recipients: ["security@company.com"]
        - type: sms
          phones: ["13800138000"]
    
    - name: 非工作时间变更
      condition:
        time_range: "22:00-08:00"
        action: CONFIG_PUBLISH
      severity: HIGH
      channels:
        - type: phone_call
          phones: ["13800138000"]

七、实战案例：电商平台配置中心落地

7.1 业务背景

某电商平台有 50+ 微服务，配置管理面临以下挑战：

• 配置散乱：每个服务自己管理配置，格式不统一
• 变更困难：改个超时时间要重启服务，影响线上业务
• 环境混乱：开发、测试、生产环境配置经常搞混
• 安全隐患：数据库密码明文存储在配置文件中

7.2 解决方案

基于自研的 configcenter 服务搭建配置中心，理由：

• 自主可控：完全掌握核心代码，快速响应业务需求
• 高性能：优化推送机制，实现 3 秒内配置生效
• 安全可靠：内置完善的容错和缓存机制

┌────────────────────────────────────────────────────────┐
│                    生产环境                            │
│  ┌────────────────────────────────────────────────┐   │
│  │          configcenter 服务                      │   │
│  │    ┌──────────┐  ┌──────────┐  ┌──────────┐  │   │
│  │    │ Portal   │  │ Admin    │  │ Config   │  │   │
│  │    │ Server   │  │ Service  │  │ Service  │  │   │
│  │    └──────────┘  └──────────┘  └──────────┘  │   │
│  └────────────────────────────────────────────────┘   │
│                        │                              │
│  ┌─────────────────────┴────────────────────────┐    │
│  │            MySQL Master-Slave                │    │
│  └──────────────────────────────────────────────┘    │

└────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────┐
│                  非生产环境（共享）                     │
│  ┌────────────────────────────────────────────────┐   │
│  │          configcenter 服务                      │   │
│  │    ┌──────────┐  ┌──────────┐  ┌──────────┐  │   │
│  │    │ Portal   │  │ Admin    │  │ Config   │  │   │
│  │    │ Server   │  │ Service  │  │ Service  │  │   │
│  │    └──────────┘  └──────────┘  └──────────┘  │   │
│  └────────────────────────────────────────────────┘   │
│         命名空间：dev / test / uat                    │
└────────────────────────────────────────────────────────┘

# 原来的散乱配置
# order-service/application.properties
db.url=jdbc:mysql://localhost:3306/order_db
db.username=root
db.password=123456
redis.host=localhost
timeout.ms=5000
feature.new_ui=true
logging.level=DEBUG

# 迁移后的结构化配置
# order-service/application.yml（公共配置）
spring:
  datasource:
    url: ${db.url}
    username: ${db.username}
    password: ${db.password}

# order-service/db.yml（数据库配置）
db:
  url: jdbc:mysql://${DB_HOST}:3306/order_db
  username: order_user
  password: cipher:encrypted_password_here  # 加密存储
  pool:
    max_size: 100
    min_idle: 10

# order-service/feature-flags.yml（功能开关）
features:
  new_ui: true
  new_payment: false
  recommendation_v2: true

# order-service/timeout.yml（超时配置）
timeout:
  db_query_ms: 1000
  external_api_ms: 5000
  cache_ms: 100

// 原来的配置读取方式
@Configuration
public class OldConfig {
    @Value("${timeout.ms}")
    private int timeout;
    
    @Value("${db.url}")
    private String dbUrl;
}

// 改造后：使用配置中心 SDK
@Configuration
@EnableConfigCenterConfig({"application", "db", "feature-flags", "timeout"})
public class NewConfig {
    
    @Autowired
    private Config dbConfig;
    
    @Autowired
    private Config featureConfig;
    
    @ConfigChangeListener("db")
    private void onDbConfigChange(ConfigChangeEvent event) {
        // 数据库配置变更，动态调整连接池
        if (event.isChanged("db.pool.max_size")) {
            int newSize = dbConfig.getIntProperty("db.pool.max_size", 100);
            dataSourcePool.resize(newSize);
            log.info("Database pool size changed to: {}", newSize);
        }
    }
    
    @Bean
    @RefreshScope  // 支持配置热更新
    public DataSource dataSource() {
        return DataSourceBuilder.create()
            .url(dbConfig.getProperty("db.url", ""))
            .username(dbConfig.getProperty("db.username", ""))
            .password(dbConfig.getProperty("db.password", ""))
            .build();
    }
}

# 1. 在配置中心修改配置
# 2. 选择灰度实例（3 台中的 1 台）
# 3. 发布到灰度实例
# 4. 观察监控指标 10 分钟
# 5. 如果正常，全量发布
# 6. 如果异常，一键回滚

7.3 落地效果

• 配置变更时间：从 30 分钟 → 3 秒
• 服务重启次数：减少 80%
• 配置错误率：降低 90%

• 敏感配置加密存储
• 配置变更全程可追溯
• 权限细粒度控制

• 统一管理 50+ 服务配置
• 多环境配置隔离清晰
• 支持自动化流程

7.4 最佳实践总结

1. 配置分类管理：将配置按功能模块拆分（数据库、缓存、业务规则等）
2. 敏感配置加密：所有密码、密钥必须加密存储
3. 灰度发布：配置变更必须灰度验证
4. 本地缓存：客户端必须实现本地缓存，保证高可用
5. 权限最小化：应用只读取自己需要的配置
6. 审计完整：所有配置变更必须记录审计日志

八、总结

配置中心是现代微服务架构的基础设施之一，它的核心价值在于：

• 配置变更从"小时级"变成"秒级"（我们实现了 3 秒生效）
• 无需重启服务，降低变更风险
• 统一管理，告别配置散乱

• 敏感配置集中加密管理
• 完整的审计追溯能力
• 灰度发布降低变更风险

• 配置与服务解耦，更灵活
• 支持多环境、多租户
• 为 Feature Toggle、A/B Test 提供基础能力

• 容错机制：客户端本地缓存、服务端集群部署、数据层主从复制
• 缓存策略：多级缓存提升性能，降级策略保证可用性
• 实时推送：推拉结合模式，3 秒内配置生效
• 安全优先：传输加密、存储加密、权限控制、审计日志

配置中心不仅仅是一个工具，更是一种配置管理的理念。它让配置成为一等公民，让配置管理从"手工时代"进化到"工业时代"。

• 系列七 · 第1篇：服务注册与发现
• 系列七 · 第2篇：负载均衡
• 系列七 · 第3篇：配置中心（本文）
• 系列七 · 第4篇：服务网关（待续）

• 《微服务设计》- Sam Newman 豆瓣链接
• 《Release It!》- Michael T. Nygard
• 配置中心设计最佳实践（内部技术文档）