背景
我入行这十年，配置这块的演进基本是：properties 文件 → 环境变量 → 配置中心（Nacos / Apollo / etcd）→ 又有人喊"配置即代码"。热榜上大家都在认真讨论超时、重试、幂等这些"运行时会变"的行为参数，但一个更上游的问题很少被摊开聊：哪些配置该进配置中心，哪些该留在代码/镜像里？ 我见过的团队，要么"万物皆可配"——几千个 key 堆在控制台，改个日志级别和改个熔断阈值走的是同一条流程；要么另一个极端——配置中心只放几个开关，其余全硬编码，想调参得发版。两头都难受。
我见过的三种主流做法
- 全量进配置中心：所有配置（数据源、线程池、开关、甚至 SQL 片段）都在控制台，改配置不发版，运维爽、研发痛。典型翻车：凌晨有人误改了一个
max-active，没有灰度、没有 diff 审计，事故复盘时没人说得清谁改的、改前是多少。 - 配置即代码：配置写进仓库（Helm values / application.yml），走 PR + code review，"配置变更即发布变更"。典型翻车：一个紧急的限流阈值调整要走半天发布流程，值班同学急得想砸键盘。
- 混合派：运行时行为参数（开关、限流、超时、灰度比例）进配置中心，结构性配置（数据源、端口、依赖拓扑）留在代码里。听着最对，但"怎么划线"每个团队划得不一样，且没人说得清为什么这么划。
我的倾向与理由
我站混合派，但想强调划线标准不是"运维方不方便"，而是三条硬判据：
- 变更频率：一天可能改 3 次的（限流阈值、降级开关）配进控制台；一年改 1 次的（连接池大小、线程数）走代码走 review。判据是"如果它需要紧急变更，你是否希望它 30 秒生效"。
- 回滚成本：改错了能否秒级回滚？配置中心天然有版本与一键回滚，代码里的配置回滚意味着重新发布——所以回滚慢的变更更该留在代码里走完整流程，而不是塞进配置中心图省事。
- 爆炸半径：一个 key 改错影响的是单机、一个实例组、还是全集群？半径越大越该走代码 + review，半径越小才适合配置中心热更。
打个比方：配置中心像消防栓——留给"着火时"用；结构性配置像承重墙——动它必须走施工图。把承重墙也做成消防栓，不是灵活，是危房。
想听大家的选择
- 你们团队现在按什么标准划这条线？有没有过"划错线"导致事故的案例？
- 配置中心里"紧急开关"泛滥（几百个 switch）你们怎么治理？是定期清理还是放任生长？
- 纯 K8s 环境下（Helm + env），你们还会引入独立配置中心吗，还是认为它已经被取代了？
- 有没有人实践过"配置变更也走灰度 + 金丝雀"的？成本收益怎么算？
欢迎贴你们的真实配置目录结构和翻车案例，比抽象讨论有价值得多。
0赞
0收藏
0楼层