配置中心、版本与动态刷新
配置中心让多个实例从统一位置读取运行参数，并在不重新构建镜像的情况下调整行为。动态配置会直接改变生产进程，因此每次变更都需要 schema、版本、作用范围和回滚路径。
1. 区分启动配置和运行时配置
端口、存储路径和 JVM 启动参数通常在进程创建前决定；限流阈值、功能开关和部分线程池参数可以在运行时更新。
不是所有字段都适合热更新。连接池大小改变时要处理已有连接，线程池队列容量可能无法原地替换，序列化协议和数据库 schema 更不能仅靠配置同时切换。
每个配置项应标明：读取时机、缺省值、合法范围、是否动态、变更副作用和负责人。
2. 客户端使用完整快照而非零散字段
配置中心可以通过长轮询、watch 或推送通知客户端。通知可能重复、丢失或乱序，因此客户端应把它视为“有新版本”，随后取得完整配置快照并校验版本。
新快照通过解析和业务校验后再原子替换。不要逐字段修改共享配置对象，否则并发请求可能读到一半新、一半旧的组合。
应用应保留最后一份有效快照。配置中心不可用时继续运行，还是因为安全风险停止服务，要按配置类别决定。
3. schema 校验阻止错误进入运行态
配置发布前至少校验：
- 类型、必填字段和数值范围。
- 字段之间的约束，例如最小值不大于最大值。
- 引用的服务名、资源和策略是否存在。
- 新旧版本是否兼容当前应用版本。
- 变更是否超过预设安全幅度。
客户端仍需再次校验，因为旧客户端可能不理解新字段，或者控制面与数据面版本并不一致。校验失败时拒绝新版本并上报原因，不能带着部分默认值悄悄生效。
4. 版本和审计让变更可追踪
每次发布生成不可变版本，记录内容摘要、作者、时间、审批、作用环境和变更原因。运行实例应暴露当前生效版本，日志和指标也携带它。
发生故障时，团队才能回答哪些实例已经收到新版本、错误率从哪个版本开始变化，以及回滚是否覆盖全部实例。
版本号必须由配置系统统一产生，不能只使用客户端本地时间判断先后。
5. 灰度配置先限制作用范围
动态配置可以按环境、集群、区域、租户、用户或实例标签逐步生效。灰度过程中需要稳定分组，避免同一用户在新旧配置之间来回跳动。
先在内部或小流量组验证，再扩大比例。每一步都绑定错误率、延迟、业务结果和资源使用等观察窗口；达到停止条件时自动暂停或回滚。
同时修改多个配置会让效果难以归因。高风险变更应一次只改变一个主要变量。
6. 回滚重新发布旧内容的新版本
回滚不应篡改历史版本，而是把已验证的旧内容作为一个新的发布版本再次分发。这样能保持全局版本单调，并留下完整审计记录。
配置回滚只能恢复进程行为，不能撤销已经写入的数据、已经发送的消息和外部副作用。涉及数据格式或工作流的开关，需要正向修复、补偿和兼容读取。
7. 密钥不与普通配置同等处理
密码、私钥和 API token 应存入专门的 secret manager，使用最小权限、加密传输、访问审计和轮换机制。配置中心只保存引用，或提供与普通配置隔离的密钥能力。
日志、诊断端点和配置 diff 都不能输出明文密钥。轮换时要允许新旧凭据短期重叠，并验证所有实例已经切换后再撤销旧凭据。
8. 动态刷新需要观测和退出条件
配置系统应记录发布成功率、实例应用延迟、拒绝原因、当前版本分布和长时间离线实例。业务指标需能按配置版本切分。
某些对象刷新失败后，进程可能处于未知状态。此时应继续使用旧对象、标记 readiness 失败，或按预定义策略重启，而不是只打印一条日志继续运行。
9. 常见问题
9.1 配置中心不可用时应用应启动吗
取决于是否有本地有效快照和配置风险。普通性能参数可以使用最后有效值；认证公钥、吊销策略等安全配置过期后可能需要拒绝服务。策略要按配置类型定义，不能用统一的 fail-open 或 fail-closed。
9.2 动态线程池参数可以随意调整吗
不能。核心线程、最大线程、队列、拒绝策略相互影响，某些队列也不能动态改变容量。发布前应校验关系，限制单次幅度，并观察 active、queue、reject 和任务耗时后逐步调整。
10. 面试题
10.1 动态配置如何安全生效并支持回滚
出现公司：美团、阿里巴巴
考察重点
- 完整快照、版本与原子替换。
- schema、客户端校验和最后有效配置。
- 灰度、审计、回滚与不可逆副作用。
相关内容：第 1 节“区分启动配置和运行时配置”至第 8 节“动态刷新需要观测和退出条件”。
参考回答
先把配置分成启动期和可动态更新两类，并为每项定义类型、范围、兼容版本和变更副作用。客户端收到通知后拉取带全局版本的完整快照，在本地完成 schema 和业务校验，再原子替换；失败时继续使用最后有效版本并上报，不能逐字段写出中间状态。
发布按环境、集群或稳定用户组灰度，业务指标关联配置版本，并设置停止条件。回滚通过重新发布旧内容形成新版本，保留审计和版本单调。它只能恢复后续行为，不能撤销已经产生的数据变化，因此高风险配置还要有兼容与补偿方案。