云原生应用采用 OpenFeature 时如何隔离旗标评估与业务代码

云原生应用接入 OpenFeature 后，最稳妥的隔离方式不是把所有调用都换成另一个 SDK，而是把旗标评估固定在一条边界内：业务层只依赖自己的 FlagReader 接口，OpenFeature Client 和 Provider 只出现在适配层与应用启动的组合根。这样既能替换底层旗标平台，也能限制评估上下文中哪些数据可以离开业务模块。

官方地址：https://openfeature.dev/

先划分业务层、旗标适配层和 Provider 组合根

OpenFeature 的 Evaluation API 面向应用作者，Provider 负责把它翻译成底层旗标系统可以理解的调用。隔离的第一步是把这两个角色放在应用边界之外：启动代码负责注册 Provider，适配层负责调用 Client，领域服务只询问“是否允许新结算流程”。

这张边界图是文章的静态说明图，不是运行截图。关键判断很简单：如果业务单元测试必须启动某个厂商的旗标服务，说明依赖方向已经反了。

用窄接口承接 OpenFeature Evaluation API

不要让业务方法接收一个通用的 OpenFeature Client。可以在应用内部定义窄接口，再由适配器集中处理 flag key、默认值和上下文。下面的 TypeScript 结构代码只表达依赖关系，具体 SDK 包名按项目使用的 OpenFeature SDK 选择。

// 中文注释：业务层只看到自己的语义接口，不感知 OpenFeature 或具体 Provider
export interface CheckoutFlags {
  allowNewCheckout(user: { id: string; plan: string }): Promise;
}

// 中文注释：适配层统一设置默认值，并只映射评估所需的字段
export class OpenFeatureCheckoutFlags implements CheckoutFlags {
  constructor(private readonly client: { getBooleanValue: Function }) {}

  async allowNewCheckout(user: { id: string; plan: string }) {
    // 中文注释：false 是 Provider 异常或旗标缺失时的保守业务默认值
    return this.client.getBooleanValue(
      'checkout-v2',
      false,
      { targetingKey: user.id, plan: user.plan },
    );
  }
}

// 中文注释：组合根负责注入适配器，业务服务不负责选择 Provider
const flags = new OpenFeatureCheckoutFlags(openFeatureClient);
const checkoutService = new CheckoutService(flags);

窄接口还有一个实际收益：当团队把 Provider 从远程服务换成本地缓存或测试实现时，业务测试只需替换 CheckoutFlags。如果某个旗标开始影响支付、库存等多个领域，优先增加语义方法和测试，不要把通用 Client 再向下传一层。

限定 Evaluation Context 与 Hook 的数据边界

Evaluation Context 可以包含 targeting key 和自定义字段，但“能传”不等于“应该传”。适配层应建立白名单，只放用户分群、租户和区域等确实参与定向的字段；身份证号、完整邮箱、订单明细和访问令牌不应因为方便调试就塞进上下文。

Hook 更适合做评估前后的横切工作：在 before 阶段补充经过脱敏的上下文，在 after 阶段记录结果，在 error 与 finally 阶段完成异常和耗时记录。它不应该偷偷改变订单状态，也不应该把原始上下文写入日志。若多个 Provider 共存，还要确认某个 Provider 的上下文变更不会污染另一个 Provider。

建议给日志保留四项：flagKey、结果类型、Provider 名称和脱敏后的错误码；把用户标识做不可逆摘要，并设置采样率。这样审计能回答“哪个旗标、哪种结果、哪个 Provider”，却不会暴露评估输入。

建立默认值、故障和灰度切换的防护线

旗标系统不可用时，默认值必须是业务明确选择的降级策略，而不是随手写的 false。例如新结算流程可能需要默认关闭，展示类推荐可能允许默认开启；这个决策应由适配器的语义方法表达，并在评审记录中说明影响。

至少演练三种情况：Provider 超时，检查超时是否被归一化为可观测错误；缺少 targetingKey，确认不会误把所有用户判成同一分组；替换 Provider，确认只改组合根配置，业务包和接口测试不变。Provider 注册是全局影响点，启动与关闭顺序也要纳入服务生命周期。

• 依赖方向：业务包不能直接依赖厂商 SDK。
• 输入边界：每个旗标记录允许的上下文字段和脱敏规则。
• 结果边界：每个语义方法写清默认值、超时和错误后的业务动作。
• 变更边界：Provider、flag key 和灰度规则变更都能回溯到负责人。

相关问题

OpenFeature Provider 能不能直接放进业务服务里？

可以由业务服务启动时注册，但不应让领域对象持有 Provider。把注册和配置留在组合根，业务只依赖语义接口，替换和测试的成本更低。

Evaluation Context 是否应该在每次调用时完整传入？

不需要。只传递当前旗标规则真正使用的最小字段，并避免把敏感数据当作调试信息送入 Provider；字段变化也应有明确的审计记录。

Hook 能不能承担业务降级逻辑？

不建议。Hook 适合观测、校验和上下文处理，默认值与降级动作应由适配层的语义方法决定，否则业务结果会隐藏在横切代码中。