Feature Flag 和配置滚动发布怎么设计

Feature Flag 和配置滚动发布的价值，在于把“代码上线”和“功能放量”拆开。系统真正稳不稳，很多时候不取决于有没有灰度，而取决于开关和配置能不能快速止损。

先说结论

• 发布代码不等于立刻放量，功能开关要独立于部署节奏
• 配置变更要能灰度、回退、审计，不能直接全量覆盖
• 开关是治理工具，不是长期债务，必须定期清理

核心边界

Feature Flag 适合控制什么

适合控制新功能启停、灰度用户范围、AB 实验、降级开关和兜底策略切换。它解决的是“同一份代码，在不同用户或不同时间点表现不同”。

配置滚动发布解决什么

它更适合控制连接池参数、阈值、黑白名单、限流值、推荐权重等运行参数。目标是降低一次性全量变更的风险。

两者为什么要分开

功能开关偏业务语义，配置发布偏运行参数。混在一起后，容易出现“一个 YAML 里既有业务策略又有基础参数”，最后谁改都心里没底。

一套实用设计

先做最小粒度

开关要明确到功能点，配置要明确到配置项。粒度过粗时，一次回滚会误伤很多无关改动。

再做灰度范围

至少支持按环境、实例、用户组或流量比例控制。没有范围控制，所谓滚动发布其实只是“慢一点全量”。

最后做回滚路径

上线前要提前验证两件事：开关关闭后是否真的止血，旧配置回滚后是否会触发兼容问题。真正出事故时，你没有时间现场设计回退方案。

常见误区

把 Feature Flag 当永久配置中心

开关越来越多却不清理，半年后没人知道哪些还能删，复杂度会持续上升。

配置改动不做灰度

很多事故不是代码引起的，而是线程池、超时、连接数、路由规则这类配置一次改太多。

只支持开，不支持关

如果开关打开很容易，关闭却要重新发布，那它就不算真正的发布治理能力。

一句话总结

Feature Flag 管“功能何时放量”，配置滚动发布管“参数如何稳妥生效”，两者配合好，发布风险会明显下降。