Feature Flag在变更冻结闸口自动化中的场景应用 - 第2节

2.1 Flag 类型：从布尔到多变量的能力演进

Feature Flag 的核心在于通过一个可动态切换的开关，控制代码路径的选择。根据业务复杂度的不同，Flag 主要分为三种类型，每种类型对应不同的变更控制粒度。

布尔 Flag：最基础的 Kill Switch

布尔 Flag 是最简单的开关形式，通常对应一个 true 或 false 值。在变更冻结期间，当闸口检测到违规变更时，可以立即将布尔 Flag 置为 false，实现秒级回滚。

// 布尔 Flag 示例：冻结期间禁用新支付通道
if (featureFlag.isEnabled("new-payment-gateway")) {
    // 新支付逻辑
} else {
    // 回退到稳定支付逻辑
}

百分比 Flag：渐进式放量与风险控制

百分比 Flag 允许按用户 ID、请求 ID 或随机数进行流量分配。在冻结闸口场景中，即使需要上线紧急修复，也可以先设置为 1% 流量，观察无异常后再逐步提升。

// 百分比 Flag 示例：仅 5% 流量走新推荐算法
if (featureFlag.getPercentage("recommend-v2", userId) < 5) {
    // 新推荐算法
} else {
    // 旧推荐算法
}

多变量 Flag：复杂路由与实验管理

多变量 Flag 支持返回多个预定义值，适用于 A/B 测试、多版本共存等场景。在冻结闸口自动化中，可用于控制不同环境或不同用户群体的行为分支。

// 多变量 Flag 示例：根据用户分组返回不同 UI 版本
String uiVersion = featureFlag.getVariant("checkout-ui", userId);
switch (uiVersion) {
    case "v1": // 旧版 UI
    case "v2": // 新版 UI
    case "control": // 对照组
}

2.2 Flag 生命周期：从创建到退役的完整管理

Feature Flag 并非一次性配置，而是有完整的生命周期管理。在变更冻结闸口场景中，理解 Flag 生命周期有助于避免“僵尸 Flag”和配置混乱。

生命周期各阶段的关键动作

• 创建阶段：必须填写 Flag 描述、负责人、预期退役日期，并关联变更请求（CR）编号。
• 发布阶段：闸口自动检查 Flag 规则是否与当前冻结策略冲突（如冻结期间禁止 >5% 的放量）。
• 稳定阶段：当 Flag 达到 100% 且运行稳定超过 7 天，系统自动发起清理工单。
• 清理阶段：闸口扫描代码仓库，检测 Flag 引用是否已移除，未移除则阻断合并请求。
• 退役阶段：从配置中心删除后，闸口执行最终验证，确保无运行时依赖。

2.3 评估引擎架构：Flag 决策的核心枢纽

评估引擎是 Feature Flag 系统的核心组件，负责接收请求上下文（用户、环境、设备等），根据配置规则计算出最终的 Flag 值。在变更冻结闸口场景中，评估引擎的架构设计直接影响决策延迟和可靠性。

评估引擎的核心职责

• 规则解析：读取 Flag 配置中的规则树（布尔值、百分比、用户群、自定义条件）。
• 上下文匹配：将请求上下文（userId、region、platform 等）与规则条件进行匹配。
• 结果缓存：对高频评估结果进行本地缓存，降低配置中心压力。
• 降级策略：当配置中心不可用时，使用本地缓存或默认值继续提供服务。

架构分层设计

评估引擎的决策流程

1. 请求进入：应用通过 SDK 发起 Flag 评估请求，携带上下文（userId、环境、IP 等）。
2. 本地缓存查询：SDK 首先查询本地缓存，若命中且未过期，直接返回结果。
3. 远程拉取：缓存未命中时，SDK 向配置中心发起远程请求，获取最新 Flag 配置。
4. 规则匹配：规则引擎按优先级依次匹配：用户白名单 > 百分比 > 默认值。
5. 结果返回：将评估结果返回给应用，同时更新本地缓存。
6. 异步上报：SDK 异步上报评估事件到分析系统，用于监控和审计。