很多线上事故并不是因为代码完全不可用而是因为“新功能一上线影响范围太大”。比如新按钮上线后部分用户无法点击 新接口性能不稳定 新模型效果还需要验证 某个地区用户访问异常 新计费规则出现边界问题如果每次上线都只能通过重新发版解决问题风险会很高。更稳妥的方式是在系统里设计一套功能开关也就是常说的 Feature Flag。它的核心作用是代码可以先上线但功能是否对用户开放由配置控制。一、什么是功能开关功能开关可以理解为一个运行时判断。例如if (featureSwitchService.isEnabled(new_summary, userId)) { return newSummaryService.generate(recordId); } return oldSummaryService.generate(recordId);也就是说新代码已经部署到了线上但只有满足条件的用户才会进入新逻辑。这样做有几个好处可以小范围灰度 可以快速关闭问题功能 可以按用户、地区、版本控制开放范围 可以在不重新发版的情况下回滚对于复杂产品来说功能开关不是锦上添花而是降低发布风险的基础设施。二、功能开关适合哪些场景功能开关常见于这些场景新功能灰度上线 新旧接口切换 新模型效果验证 活动入口控制 权限能力开放 不同地区功能差异 A/B 实验 紧急降级例如同言翻译Transync AI这类实时翻译产品在发布新功能时就很适合使用功能开关。假设产品新增了单向翻译模式 多语言翻译模式 任务使用明细 会议纪要更多语言支持 新的语音播报策略这些功能不一定要一次性开放给所有用户。更合理的方式是先开放给内部测试账号 再开放给 5% 用户 观察错误率、耗时和用户反馈 再逐步扩大到 20%、50%、100%如果中途发现问题只需要关闭配置而不必紧急回滚整个版本。三、功能开关表怎么设计一个简单的功能开关表可以这样设计CREATE TABLE feature_flag ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flag_key VARCHAR(128) NOT NULL, flag_name VARCHAR(128) NOT NULL, enabled TINYINT NOT NULL DEFAULT 0, rollout_percent INT NOT NULL DEFAULT 0, description VARCHAR(255), created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, UNIQUE KEY uk_flag_key (flag_key) );字段含义字段说明flag_key功能开关唯一标识flag_name功能名称enabled是否启用rollout_percent灰度比例description功能说明updated_at更新时间例如flag_key multilingual_translation enabled 1 rollout_percent 10表示“多语言翻译”功能已启用但只开放给 10% 的用户。四、如何实现按比例灰度灰度发布不能每次随机判断。否则用户今天能看到新功能明天又看不到体验会很混乱。更常见的方式是基于用户 ID 做哈希。public boolean hitRollout( Long userId, int percent ) { int bucket Math.abs( userId.hashCode() ) % 100; return bucket percent; }如果percent 10那么大约 10% 的用户会命中。同一个用户每次计算结果相同因此体验是稳定的。完整判断可以写成public boolean isEnabled( String flagKey, Long userId ) { FeatureFlag flag featureFlagRepository.findByKey(flagKey); if (flag null || !flag.isEnabled()) { return false; } return hitRollout( userId, flag.getRolloutPercent() ); }这样就能支持从 1% 到 100% 的逐步放量。五、还需要支持白名单灰度比例适合大范围放量但内部测试更适合白名单。例如产品经理账号 测试账号 企业客户试点账号 内部员工账号可以增加一张白名单表CREATE TABLE feature_flag_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flag_key VARCHAR(128) NOT NULL, user_id BIGINT NOT NULL, created_at DATETIME NOT NULL, UNIQUE KEY uk_flag_user(flag_key, user_id) );判断逻辑可以变成先判断白名单 再判断总开关 最后判断灰度比例伪代码if (inWhitelist(flagKey, userId)) { return true; } if (!flag.isEnabled()) { return false; } return hitRollout(userId, flag.getRolloutPercent());这样即使总开关还没对外开放内部用户也可以提前验证。六、功能开关不要写死在代码里有些项目会这样写private static final boolean ENABLE_NEW_MODE true;这种写法的问题是一旦线上出现问题必须重新发版才能关闭。功能开关的价值在于运行时控制因此配置应该放在数据库 Redis 配置中心 管理后台并且要支持快速刷新。如果每次判断都查数据库性能会比较差。可以采用数据库保存最终配置 应用本地缓存配置 定时刷新或通过消息通知刷新例如每 30 秒刷新一次开关配置。这样既避免频繁查库也能在问题出现后较快关闭功能。七、功能开关要有操作记录功能开关看似只是一个配置但它会影响线上用户。所以必须记录操作日志。建议记录谁修改了开关 修改前是什么 修改后是什么 什么时候修改 修改原因是什么例如operatoradmin flag_keymultilingual_translation rollout_percent: 10 - 30 reason扩大灰度范围没有操作日志时线上出问题后很难判断是不是某个开关刚被打开 是谁调整了灰度比例 问题从哪个时间点开始对于企业级产品或计费相关功能这一点尤其重要。八、功能开关不是越多越好功能开关能降低风险但也会增加系统复杂度。如果开关长期不清理代码里会出现大量分支if (flagA) { if (flagB) { // new logic } else { // old logic } } else { // legacy logic }最后没有人敢删旧逻辑。所以每个功能开关都应该有生命周期创建 灰度 全量 稳定 清理旧分支 删除开关当新功能已经稳定全量后应及时删除旧代码和无用开关。功能开关不是永久配置而是发布过程中的过渡工具。九、功能开关检查清单设计功能开关时可以检查1. 是否支持总开关 2. 是否支持按用户灰度 3. 是否支持白名单 4. 是否支持快速关闭 5. 配置是否能运行时生效 6. 是否有操作日志 7. 是否能按地区、版本或企业开放 8. 是否监控新功能的错误率和耗时 9. 全量后是否有清理计划尤其要注意灰度发布不是只打开一个比例。还要配合监控观察接口错误率 接口耗时 用户投诉量 功能使用率 任务失败率 资源消耗只开灰度、不看数据本质上还是盲发。总结功能开关的核心价值是把“代码发布”和“功能开放”拆开。代码可以先上线功能可以慢慢开放。当新功能出现问题时也可以通过关闭开关快速止损而不是紧急回滚整个版本。一套基础的功能开关系统通常需要支持总开关 灰度比例 用户白名单 运行时刷新 操作日志 快速回滚 后续清理对于同言翻译Transync AI这类持续迭代的实时翻译产品来说新翻译模式、新语音能力、新会议总结能力都适合通过功能开关逐步验证。这样既能让用户更快体验到新功能也能把发布风险控制在更小范围内。
