S17-B05 · 配置中心与热更新

适用读者：改一个超时时间就要发版的人。
前置：S17-B01。
覆盖旧文：1563（Nacos 配置中心与对比，198 点）。
覆盖扩展：E-S17-015（热更新的边界）。
上一篇：S17-B04 · 网关：统一入口与跨域
下一篇：S17-J01 · 消息模型。

1. 一句话结论

配置中心解决"改配置要重新打包发版"，但它只适合"可热更新"的配置——连接串、线程池大小这类改了就要重建的，热更新是危险的。

配置类型	能否热更新
超时/重试次数/开关	✅ 安全
限流阈值	✅
数据库连接串	⚠️ 需重建连接池
线程池大小	⚠️ 需重建
端口/证书路径	❌

判据："这个值改了，已有资源要重建吗？" 要 → 别热更新（或明确写"重启生效"）。

2. 三个能力

能力	说明
集中管理	一处改，多处生效
环境隔离	dev/test/prod 分开
版本与回滚	改错了能退回

"配置中心最值钱的能力是回滚"——不是"改得快"，而是"改错了能退"。

3. 一致性：推 vs 拉

模式	说明	代价
长轮询（Nacos）	客户端挂着等变更	服务端要维持连接
推送（WebSocket）	实时	连接管理复杂
定时拉取	简单	有延迟

"为什么不用纯推送"：客户端网络抖动会丢通知；长轮询能"兜底拉一次"。

4. 热更新的三个风险（E-S17-015）

风险	说明
半更新	多实例不同时生效 → 行为不一致
缓存失效风暴	配置变更触发大量重载
错误配置扩散	一处错，全部实例生效

缓解：灰度发布配置（先给 1 个实例）、变更审计、自动回滚。

5. 五个误区

误区	真相
"所有配置都能热更新"	连接串/线程池要重建
"推送比长轮询好"	推送易丢通知
"配置中心能替代环境变量"	敏感信息仍应走密钥管理
"改配置不用审核"	错误配置会全量扩散
"有配置中心就不用重启"	部分配置必须重启

6. 自检

哪些配置能热更新、哪些不能？
配置中心最值钱的能力？
长轮询 vs 推送的取舍？
热更新的三个风险？
敏感配置该放哪？

7. 下一篇

S17-J01 · 消息模型：Topic / 分区 / 消费组

基础层结束。进阶层从"一条消息怎么被分配"开始。

本篇属于系列《S17 · 分布式与消息队列》。旧文来源：A-1563；扩展点 E-S17-015。