如何利用功能标志来实现安全、渐进式的功能推出

当哈希值低于当前累计值时，用户就会获得相应的变体。例如，在权重分别为50、variant_a: 25、variant_b: 25的情况下，如果哈希值为60，那么用户就会得到variant_a（此时累计权重为75）；而如果哈希值为30，用户就会得到“control”变体（累计权重为50）。由于哈希值是确定性的，因此同一用户对于相同的标志总是会获得相同的变体，他们的体验不会在不同的请求中发生变化。

在调用处，switch语句会将每个变体名称映射到相应的组件。control用于呈现现有的体验，这样就可以作为基准进行对比；而variant_a和variant_b则用于呈现正在测试的替代方案。你可以针对每种变体来收集数据指标，等到有足够的流量时再进行比较，从而得出具有统计意义的结果。

import { z } from "zod";

const VariantSchema = z.object({
  name: z.string(),
  weight: z.number().min(0).max(100),
});

const MultiVariantConfigSchema = z
  .object({
    variants: z.array(VariantSchema).min(1),
  })
  .refine(
    (config) => {
      const total = config.variants.reduce((sum, v) => sum + v.weight, 0);
      return total === 100;
    },
    { message: "各变体的权重之和必须为100" }
  );

// 在配置加载时进行验证——无效的配置根本无法进入评估阶段
const config = MultiVariantConfigSchema.parse(rawConfig);

标志的生命周期

那些不再具有实际用途的标志就会变成“技术债务”。为了避免这种情况，你可以为这些标志建立一套生命周期管理机制：

1. 创建阶段

每个标志都应该包含元数据：

interface FlagMetadata {
  name: string;
  owner: string;           // 负责该标志的团队或个人
  createdAt: Date;
  expectedRemovalDate: Date; // 强制要求提前规划清除计划
  type: "release" | "experiment" | "ops" | "permission";
  description: string;
  jiraTicket?: string;      // 链接到相应的跟踪问题
}

expectedRemovalDate这一字段只有在其受到强制执行时才会发挥作用。下面是一种具体的实现方法：设置一个每天运行的定时任务，当标志过期时，就创建相应的清除任务：

// 通过cron或定时的CI任务每天运行此函数
async function auditStaleFlags(flags: FlagMetadata[]) {
  const now = new Date();
  const staleFlags = flags.filter(
    (f) =>
      f.type === "release" && f.expectedRemovalDate < now
  );

  for (const flag of staleFlags) {
    const daysOverdue = Math.floor(
      (now.getTime() - flag.expectedRemovalDate.getTime()) / 86_400_000
    );

    // 在实际操作中，需要先检查是否已经存在相关的跟踪任务，避免重复创建。
    // 可以使用标志名称作为键来执行更新操作；如果已经存在标记为“Stale Flag”的任务，则直接跳过创建新任务的步骤。
    await createJiraTicket({
      title: `[Stale Flag] 删除 "${flag.name}"（逾期${daysOverdue}天）`,
      assignee: flag.owner,
      priority: daysOverdue > 30 ? "high" : "medium",
      labels: ["tech-debt", "feature-flag-cleanup"],
    });

    // 可选操作：将相关信息发送到Slack，阻止相关部署的进行，或记录警告信息
    logger.warn(`标志 "${flag.name}"已经逾期${daysOverdue}天未被清除`);
  }
}

有些团队采取更为严格的措施：如果某个发布标志在应被移除之后仍然存在，就会拒绝执行持续集成流程。这种做法虽然较为严厉，但非常有效，因为它能确保这些标志永远不会意外地变成永久性的配置项。

2. 主动管理

在功能发布过程中，需要密切监控这些标志的使用情况：

• 错误率：比较被标记的组与未被标记的组之间的差异

• 性能影响：新的代码路径是否会导致系统运行效率下降？

• 业务指标：各组的转化率、用户参与度以及收入情况

• 标志检查频率：这些标志是否在预期的位置被定期检查？

3. 清理工作

这其实是整个流程中最困难的部分——过时的标志会迅速积累起来。

如果你使用的是基于数据库的标志管理系统（或者能够通过你的管理平台的API进行查询），那么一个简单的查询就能找出需要清理的标志。假设我们有一个名为`feature_flags`的表格，其中包含以下列：每个标志当前的启用比例、达到该比例的具体日期以及其类型：

-- 查找那些已经处于100%启用状态超过30天的标志
-- 这些标志就需要被清理了
SELECT name, enabled_at
FROM feature_flags
WHERE percentage = 100
  AND enabled_at < NOW() - INTERVAL '30 days'
  AND type = 'release';

你可以自动化设置提醒机制，比如在某个发布标志处于100%启用状态超过两周时自动发出警报，或者自动创建Jira工单。这样就能确保人们会及时采取相应的行动来进行清理工作。

应避免的错误做法

标志之间的嵌套依赖关系

// 不要这样做
if (flags.newCheckout) {
  if (flags.newPaymentProcessor) {
    if (flags.newFraudDetection) {
      // 最终测试的是哪种组合呢？
    }
  }
}

三个布尔型标志可以产生八种不同的状态，而其中大多数状态根本就没有被测试过。如果这些标志之间存在依赖关系，那么应该将它们合并为一个标志，或者明确记录下所有有效的组合方式。

基于标志的架构设计

// 不要这样做
function calculatePrice(item: Item, flags: FeatureFlags) {
  let price = item.basePrice;

  if (flags.newTaxCalculation) price = applyNewTax(price);
  else price = applyOldTax(price);

  if (flags.loyaltyDiscount) price = applyLoyalty(price);

  if (flags.bulkPricing && flags.newBulkTiers) {
    price = applyNewBulkPricing(price);
  } else if (flagsbulkPricing) {
    price = applyOldBulkPricing(price);
  }

  return price;
}

如果你的业务逻辑看起来像是一个用于检查各种标志的状态的引擎，那么这就说明你的设计存在问题。应该将标志配置放在系统的边界层，然后根据不同的标志状态来调用不同的实现逻辑，而不是在代码中到处使用条件语句。

// 相反，应该这样做——将标志检查放在边界层
interface PricingStrategy {
  calculate(item: Item): number;
}

const legacyPricing: PricingStrategy = {
  calculate(item) {
    return applyOldTax(applyOldBulkPricing(item.basePrice));
  },
};

const newPricing: PricingStrategy = {
  calculate(item) {
    return applyNewTax(applyLoyalty(applyNewBulkPricing(item.basePrice)));
  },
};

// 在入口处只进行一次标志检查——业务逻辑中不要使用条件语句
const pricing = flags.newPricingEngine ? newPricing : legacyPricing;
const finalPrice = pricing.calculate(item);

不提供默认回退方案

function getFlag(name: string, defaultValue: boolean): boolean {
  try {
    return flagService.evaluate(name);
  } catch {
    // 如果标志服务无法使用，就采用默认值
    logger.warn(`标志服务不可用，因此使用 ${name} 的默认值`);
    return defaultValue;
  }
}

使用功能标志进行测试

describe("结账流程", () => {
  it("在新结账功能启用时能够正常工作", () => {
    setFlag("newCheckout", true);
    // 测试新路径下的功能是否正常
  });

  it("在新结账功能禁用时能够正常工作", () => {
    setFlag("new Checkout", false);
    // 测试旧路径下的功能是否正常
  });

  // 只测试那些实际会被部署的组合
  it("新结账功能 + 新支付方式同时启用时能否正常工作", () => {
    setFlag("newCheckout", true);
    setFlag("newPaymentProcessor", true);
    // 测试这两种功能同时启用时的流程是否正常
  });
});

选择合适的标志系统

结论

1. 将部署与发布过程分离： 将代码通过配置标志来控制，只有在确认无误时才进行发布。

2. 使用“粘性哈希”机制： 这样用户能够获得一致的体验。

3. 提前规划后续处理步骤： 每个配置标志都应设置有效期。

4. 避免出现嵌套的依赖关系： 这种复杂的依赖结构会导致代码难以测试。

5. 默认采用安全状态： 当配置标志相关的服务出现故障时，系统应自动切换到安全状态。

6. 将配置标志放在系统的边界层： 应该通过这些标志来引导系统选择不同的实现路径，而不要在代码中随意添加条件判断语句。

7. 同时监控两组测试对象： 需要对比它们的错误率、延迟时间以及各项业务指标。

所有这些模式都有一个共同点：特征标志其实是一种风险管理工具，而非用于组织代码的工具。使用它们应该是为了控制某些功能的启用状态，而不是用来构建逻辑结构。

首先部署该特征标志，然后逐步扩大其应用范围，接着监测相关指标数据，最后再将其移除。一旦某个特征标志不再服务于这一流程，它就会变成一种“累赘”或“负担”。