第3章 Feature Flag管理平台介绍：LaunchDarkly、Split、自研平台的核心功能对比

3.1 为什么需要一个管理平台

我记得刚接触Feature Flag那会儿，团队用的是「配置文件+数据库」的土办法。每个开关都要手动改配置、重启服务，出了事故还得翻半天日志。说白了，没有管理平台，Feature Flag就是个定时炸弹。

一个成熟的管理平台，至少要帮你解决三件事：

• 开关生命周期管理 —— 创建、发布、灰度、关闭、清理，全流程可视化
• 实时性 —— 开关变更后，客户端能在秒级甚至毫秒级生效
• 权限与审计 —— 谁改了开关？什么时候改的？影响范围多大？

目前市面上的方案，基本可以分为三类：LaunchDarkly、Split，以及自研平台。下面我一个一个说。

3.2 LaunchDarkly — 行业标杆

LaunchDarkly 是目前市场份额最大的Feature Flag平台。我用它做过两个中型项目，最直观的感受是：SDK覆盖太全了。

• 30+语言SDK：从Go、Java、Python到iOS、Android、React Native，几乎你能想到的语言都有
• 实时推送 < 1s：基于Streaming长连接，开关变更后客户端几乎立即生效
• 企业级权限模型：支持RBAC、自定义角色、环境隔离，审计日志非常详细
• SaaS交付：开箱即用，运维成本极低

来个最简的Go SDK初始化示例：

import ld "github.com/launchdarkly/go-sdk-common/v3/ldcontext"
import "github.com/launchdarkly/go-server-sdk/v6"

client, _ := ld.MakeClient("sdk-key-123456", 5*time.Second)
defer client.Close()

ctx := ld.NewContext("user-abc")
flagValue, _ := client.BoolVariation("new-checkout-flow", ctx, false)
if flagValue {
    // 走新流程
}

3.3 Split — 实验驱动

Split 跟 LaunchDarkly 最大的区别在于：它把「实验分析」作为核心卖点。你想想看，Feature Flag不只是开关，更是做A/B测试的基础设施。Split在这方面确实做得深。

• 内置实验引擎：支持多指标、多臂试验，自动计算统计显著性
• 丰富的数据看板：转化率、延迟、错误率，开箱即用的报表
• 自动化流量分配：按百分比、按属性、按集群，规则灵活
• 部署方式可选：SaaS版和私有化部署都支持

Split 的分割规则定义示例：

{
  "name": "new-recommendation",
  "treatment": "on",
  "keys": ["user_id:1001-2000", "org_id:enterprise"],
  "rule": "user.tier in ['gold', 'platinum']"
}

3.4 自研平台 — 掌控一切

说实话，我在上一家公司就是自研Feature Flag平台的负责人。为什么选自研？因为安全要求和定制化需求太高了，SaaS平台满足不了。

• 完全定制化：你想怎么做就怎么做，没有平台限制
• 数据100%内网：所有流量和配置数据不出机房，适合金融、政务场景
• 与CI/CD深度集成：可以把开关变更纳入发布流水线，实现自动化审批
• 成本自主可控：没有按用户数计费的焦虑，规模越大越划算

自研平台的API设计参考：

// 创建开关
POST /api/v1/flags
{
  "key": "new-payment-v2",
  "name": "新支付流程",
  "variations": [
    {"key": "on", "name": "开启", "default": false},
    {"key": "off", "name": "关闭", "default": true}
  ]
}

// 评估开关
GET /api/v1/evaluate?flag_key=new-payment-v2&user_id=u_123&org=enterprise
→ {"variation": "on", "reason": "rule_match"}

3.5 核心功能对比

下面这张表是我在实际选型中总结的维度，覆盖了绝大多数场景：

你看，没有的「最好」，只有「最适合」。我个人习惯是这么判断的：

• 团队 < 30人，追求速度 → LaunchDarkly
• 以实验和数据驱动为核心 → Split
• 安全要求极高，或已有基础设施 → 自研