配置中心¶

面试追问地图¶

回答配置中心题要说明"为什么需要配置中心"而不是直接背功能，并从"配置与代码的分离演进"切入。

一、配置中心基础¶

配置中心解决了什么问题？¶

频次 ★★★ · 难度 🟢

是什么：配置中心将配置从代码中剥离，实现配置的集中管理、动态刷新、版本控制和权限审计。

从配置文件到配置中心的演进：

核心能力： - 动态刷新：修改配置 → 推送到客户端 → 应用立即可见，无需重启 - 版本管理：每次变更记录版本号，可回滚到任意历史版本 - 灰度发布：先对一小部分实例推送验证，再全量发布 - 权限控制：配置修改操作有审计日志，谁改了什么、什么时候改的都可追溯 - 环境隔离：开发/测试/生产环境各自独立，配置互不干扰

二、选型对比¶

配置中心选型对比：Nacos vs Apollo vs Disconf vs Spring Cloud Config¶

频次 ★★★★ · 难度 🟡

选型建议： - 已有 Spring Cloud Alibaba 生态 → Nacos（配置+注册一体化，生态整合好） - 需要功能最全的配置管理 → Apollo（多环境/灰度/回滚/权限最完善） - 新项目不建议用 Disconf（已停止维护）和 Spring Cloud Config（无 UI、无灰度、需配合 Bus）

三、Nacos 配置中心¶

Nacos 配置中心¶

频次 ★★★★ · 难度 🟡

是什么：Nacos 是阿里巴巴开源的动态服务发现、配置管理和服务管理平台，配置中心是其中一部分。支持长轮询检测配置变更、MD5 比对确认是否需要更新。

核心概念：

长轮询机制：

Client                          Nacos Server
  │                                  │
  │── 发起 HTTP 长轮询请求 ──────────→│
  │   (带配置的 Data ID + MD5)        │
  │                                  │ 1. 服务端收到请求，不立即返回
  │                                  │ 2. 比对客户端 MD5 与最新配置 MD5
  │                                  │ 3. 一致则挂起连接（最多 30s）
  │                                  │ 4. 配置变更时立即返回
  │←──────── 返回新配置 ─────────────│
  │  (或 30s 超时无变更返回)          │
  │                                  │
  │ 更新本地配置，回调监听器           │
  │ 发起新一轮长轮询                  │

推 vs 拉：Nacos 本质是拉模式（客户端轮询），但通过长轮询实现接近实时的推送效果。真正的推送（Server 主动发）需要 WebSocket，Nacos 客户端长轮询每秒一次，对大多数场景已经足够。

Nacos 客户端长轮询源码（Nacos 2.x ClientWorker，简化）：

// 核心：ClientWorker.checkUpdateConfigStr() 长轮询
public void checkUpdateConfigStr(String dataId, String group, String tenant, String content) {
    // 1. 拼接带 MD5 的请求
    List<ConfigKey> keys = new ArrayList<>();
    keys.add(new ConfigKey(dataId, group, tenant, content));
    // 2. 发起 HTTP POST 长轮询（默认 30s 超时）
    HttpResult result = agent.httpPost(Constants.LONGPOLLING_URL, body, CONFIG_LONGPOLL_TIMEOUT);
    // 3. 服务端返回有变更的配置列表
    List<String> changedKeys = parseChangedKeys(result.getContent());
    if (!changedKeys.isEmpty()) {
        // 4. 逐个拉取最新配置并更新本地缓存
        for (String key : changedKeys) {
            String config = getConfig(dataId, group, tenant);  // 重新拉取
            localCache.put(key, config);
            // 5. 通知监听器
            notifyListener(dataId, group, config);
        }
    }
    // 6. 立即发起下一轮长轮询（不间隔）
    checkUpdateConfigStr(dataId, group, tenant, localCache.get(key));
}

配置持久化：Nacos 配置数据支持 Derby（单机默认）或 MySQL（生产推荐）。单机模式 Derby 存在数据丢失风险，生产必须配置 MySQL 持久化。

灰度发布（Beta 发布）：Nacos 支持先对指定 IP 的实例推送配置变更，验证无误后再全量发布。灰度期间其他实例不受影响。

Nacos 配置中心 SDK 使用：

// 1. 配置监听（Spring Cloud Alibaba 自动注入，无需手动写）
@RefreshScope  // 标注需要动态刷新的 Bean
public class ApplicationConfig {
    @Value("${config.key:default}")  // 配置变更自动刷新
    private String configKey;
}

// 2. 手动配置监听（非 Spring 场景）
configService.addListener("dataId", "DEFAULT_GROUP", new Listener() {
    @Override
    public void receiveConfigInfo(String configInfo) {
        // 配置变更回调
    }
});

四、Apollo 配置中心¶

Apollo 配置中心¶

频次 ★★★ · 难度 🟡

是什么：Apollo（携程开源）是功能最完善的配置中心之一，核心优势在多环境管理和配置可视化。

四大核心模块：

Apollo 配置优先级：应用 > 环境 > 数据中心 > 默认

配置优先级从高到低：
1. 应用级别（application.properties）
2. 环境级别（dev/test/prod）
3. 数据中心级别（不同机房不同配置）
4. 公共配置（全局默认值）

Apollo vs Nacos 配置中心：

五、Disconf¶

Disconf¶

频次 ★ · 难度 🟡

是什么：Disconf（百度开源）是早期分布式配置管理框架，基于 ZooKeeper 存储配置，利用 ZK 的 Watch 机制实现实时推送。

技术特点： - 配置存储在 ZooKeeper 节点上，利用 ZK 的 Watcher 实现配置变更实时通知 - 支持全量配置下发和增量配置下发 - 配置变更时自动降级（如果本地有备份文件，优先使用本地） - 与 Spring 集成，通过 @DisconfFile 注解自动注入

为什么逐渐被淘汰： 1. 依赖 ZooKeeper：ZK 是分布式协调系统，做配置存储其实不是最优选择（配置数据一般不要求强一致，ZK 的 CP 特性是杀鸡用牛刀） 2. 配置量受限于 ZK 节点大小：ZK 单个节点数据建议不超过 1MB，大配置存不进去 3. 无灰度发布：变更推送给所有客户端，无法先验证再全量 4. 已停止维护：Disconf 的 GitHub 仓库自 2019 年后几乎没有更新，社区已转向 Nacos/Apollo

六、配置变更安全¶

配置变更如何保证安全？¶

频次 ★★★ · 难度 🟡

是什么：配置变更直接决定线上行为，改错一个配置项可能导致线上故障。核心防线如下：

1. 版本管理：每次配置变更生成新版本号，支持一键回滚到任意历史版本。Nacos/Apollo 都默认保留历史版本。

2. 灰度发布：先对一小部分实例（如 1 台或 5% 流量）推送变更，观察无异常后再全量发布。Nacos 的 Beta 发布和 Apollo 的灰度发布都是为此设计。

3. 权限控制：配置修改需要审批，变更操作有审计日志。Apollo 权限体系最完善，支持修改/发布/回滚的审批流。

4. 变更前的校验：修改配置时，系统自动校验配置格式（如 JSON/YAML 格式有效性、端口号范围等），避免语法错误导致客户端解析失败。

5. 变更后的自动化监控：配置变更后自动触发关联指标监控（如错误率、超时率），如果指标异常自动回滚或告警。

线上事故案例分析： - 改错连接池配置→数据库连接数暴增→数据库打挂 - 改错日志级别→ERROR 日志太多→磁盘打满 - 改错开关配置→功能灰度范围扩大→影响面失控

配置变更应当像代码变更一样走审批 + 灰度 + 可回滚流程。

七、配置中心与注册中心的区别¶

频次 ★★★ · 难度 🟢

是什么：Nacos 同时支持配置中心和注册中心，但两者是不同维度的能力：

为什么 Nacos 两者都能做：Nacos 内部将注册信息和配置信息分开存储，采用不同的数据模型和一致性协议。注册中心用 Distro 协议（AP，自研），配置中心用长轮询 + 本地快照（最终一致）。两者共享同一个进程和 Admin UI，但存储和传输通道是独立的。

关联篇目：ZooKeeper与注册中心（注册中心对比、ZK 原理）、SpringCloud微服务（Nacos 使用场景）、SpringBoot（配置中心集成）