系统设计面试：如何设计一个安全的 Feature Flag 服务？

题干与适用场景

请设计一个 Feature Flag 服务，让团队无需重新部署就能开关功能，支持按环境、用户分群和百分比灰度，并在配置服务故障时保持安全默认值。面试中可进一步追问低延迟评估、配置审计、审批、回滚和多区域可用性。

这道题适合平台工程、后端和系统设计岗位。公开题库将类似题目描述为百万级每秒评估与极低延迟；公开面经则把它放在平台工程系统设计环节。回答重点应放在控制面、数据面和发布安全边界，而不是堆砌组件名称。

面试官考察点

• 能否把写少读多的配置系统拆成控制面与数据面。
• 能否定义稳定的百分比灰度，避免用户在请求间被不同版本来回切换。
• 能否设计默认值、过期时间、kill switch 与回滚，限制配置错误的爆炸半径。
• 能否说明一致性、延迟、审计和多租户隔离之间的取舍。

回答前需要澄清的问题

先确认评估是在 SDK、边缘节点还是中心服务完成；目标是每秒百万次评估还是较低吞吐；灰度维度是用户、组织、区域还是会话；配置是否允许秒级生效；失败时每个 flag 的安全默认值是什么。还要确认是否需要实验分流、强制关闭和审批流程。

30 秒回答框架

我会先给出控制面：创建 flag、规则、版本、审批和审计；再给出数据面：SDK 或边缘缓存拉取已发布版本并本地评估。规则按环境和目标群组匹配，百分比用稳定的用户标识哈希分桶。发布采用逐步扩大、指标告警自动回滚；拉不到新配置时继续使用有期限的旧版本或安全默认值。

分步骤深入解答

核心数据模型

Flag 至少包含 key、环境、默认值、规则列表、版本、发布时间、过期时间和审计元数据。规则可以按组织、区域、用户属性匹配，也可以提供百分比分桶。规则顺序必须明确，首个匹配规则胜出，并在发布前做语法、类型和语义校验。

控制面与数据面

控制面负责写入、审批、版本化、审计和发布；数据面只读取已发布快照并完成评估。客户端 SDK 优先从内存缓存读取，后台通过轮询、长连接或消息通知更新。这样配置中心短暂不可用时，业务请求不必同步等待控制面。

稳定灰度与安全发布

把 flagKey + stableSubjectId + salt 做一致哈希，再映射到 0 到 9999 的桶。百分比从 1% 扩大到 5%、25%、50%、100% 时，已进入的用户保持在同一版本。发布前验证规则和依赖，发布中观察错误率、尾延迟和业务指标；触发告警就回滚到上一个已验证版本。

~~~text evaluate(flag, context, snapshot): rules = snapshot[flag].rules[context.environment] for rule in rules: if matches(rule.targeting, context): if rule.percentage is absent: return rule.value bucket = hash(flag.key + context.stableSubject + rule.salt) % 10000 if bucket < rule.percentage * 100: return rule.value return snapshot[flag].safeDefault ~~~

关键取舍

AWS AppConfig 的公开文档采用版本、环境、部署策略和校验器，并支持按目标逐步部署；它还用监控告警自动回滚。这个事实支持“发布流程是系统的一部分”，但不意味着所有业务都必须复制 AWS 的组件形态。

高质量示范回答

我会把系统分成控制面和数据面。控制面保存 flag 定义、规则、版本和审计记录，所有变更经过校验与审批后生成不可变快照。数据面由 SDK 或边缘节点缓存快照，在本地完成规则匹配和百分比评估，避免每次请求调用中心服务。

百分比灰度使用稳定主体标识做一致哈希，因此同一用户在 1% 扩到 25% 时不会反复跳版本。每个 flag 都有安全默认值和过期策略；应用启动时若拿不到快照，应按 flag 的风险选择关闭或继续使用最后一个未过期版本。发布按小比例逐步扩大，配合错误率、P99 延迟和业务指标告警自动回滚。若需要强一致或立即关闭，我会提供短路径 kill switch，但会明确它对缓存、权限和审计的额外成本。

常见错误

• 每次请求都访问中心配置服务，把 flag 系统变成业务关键链路上的单点延迟。
• 用随机数做百分比灰度，导致同一用户在请求之间不断切换。
• 没有版本号、过期时间和审计记录，无法解释“谁在何时发布了什么”。
• 只设计开关接口，不设计回滚、默认值和配置校验。
• 把最终一致性、缓存陈旧窗口和紧急关闭的语义混在一起，没有为不同风险设置不同策略。

追问及应对

如何保证跨实例的用户体验一致？

所有实例使用同一稳定主体标识、flag key 和 salt，且快照版本可观测。不要把随机请求 ID 作为分桶输入；需要匿名流量时使用持久化会话标识，并说明其生命周期。

配置服务不可用怎么办？

数据面继续使用最后一个未过期快照；超过 TTL 后按 flag 风险回到安全默认值。SDK 需要记录快照年龄、拉取失败和评估来源，避免静默使用无限陈旧配置。

如何撤回一个危险功能？

提供受权限保护的 kill switch，并让高风险 flag 的关闭路径比普通发布更短。关闭操作仍需记录操作者、原因、版本和影响范围，防止紧急操作失去审计。

如何防止规则配置错误？

发布前做 schema、类型、互斥条件和覆盖率检查；用离线样本评估规则，确认每个目标至少命中一个预期分支。高风险变更先在影子环境或小比例环境执行。

多区域如何处理？

控制面可按区域复制已发布快照，数据面在本地读取。每个快照带版本和发布时间，监控区域间版本差距；若区域无法更新，继续使用上个安全版本并告警。

什么时候不该使用 Feature Flag？

纯静态配置、一次性迁移或需要强事务一致性的权限判断不一定适合 flag。若 flag 数量、规则和过期债务持续增长，应设置负责人、过期日期和清理指标，避免运行时规则取代正常发布流程。