灰度发布基础

灰度发布（Canary Release / Gray Release）是发布工程中降低风险的核心实践。其本质是让新版本先在小范围真实用户或流量中验证，确认稳定后再逐步扩大覆盖，直至全量上线。本章从原理、对比和策略三个维度建立灰度发布的知识基础。

灰度发布原理

灰度发布的核心思想是渐进式暴露。系统在发布期间同时运行新、旧两个版本，通过流量路由或功能开关将一部分用户/请求导向新版本，其余仍使用旧版本。监控系统持续采集新版本的错误率、延迟、业务指标，当指标符合预期时逐步增加灰度比例，否则立即回滚。

全量发布与灰度发布对比

传统全量发布（Big Bang Release）一次性将所有用户切换到新版本，风险集中；灰度发布则通过分阶段放量分散风险。下表从多个维度对比两种模式：

灰度策略类型

灰度策略决定了“哪些用户/请求走新版本”。根据业务场景不同，常见的灰度策略分为三类：按用户、按地域、按比例。实际项目中常组合使用。

1. 按用户灰度

基于用户身份标识（如 UserID、邮箱、会员等级、内测白名单）决定是否进入灰度组。适用于定向邀请、内部员工验证、VIP 用户优先体验等场景。

• 白名单模式： 指定特定用户（如测试团队、核心客户）始终走新版本。
• 用户哈希取模： 对 UserID 做 hash 后取模，按模值分配灰度组，保证同一用户始终看到同一版本。
• 用户属性匹配： 根据用户标签（如“Beta 测试用户”、“付费用户”）动态路由。

2. 按地域灰度

根据用户请求的地理位置（IP 归属地、注册国家、数据中心区域）进行灰度。常用于跨国业务、合规要求、区域性功能测试。

• 典型做法： 先灰度某个内部区域（如公司所在城市），再灰度低风险区域（如非核心市场），最后灰度核心区域。
• 注意： 地域灰度需配合 DNS 或 CDN 路由，确保流量正确导向对应版本的服务集群。

3. 按比例灰度

不区分用户身份，直接将总流量的 X% 随机导向新版本。这是最通用的灰度策略，适合后端服务、API 升级、性能验证。

• 流量比例： 常见阶梯为 1% → 5% → 10% → 25% → 50% → 100%。
• 随机 vs 一致性： 纯随机可能导致同一用户在不同请求中体验不一致；建议使用一致性哈希或 sticky session 保持会话亲和性。
• 工具支持： 负载均衡器（如 Nginx、Envoy）、服务网格（如 Istio）、Feature Flag 平台均可实现比例路由。

灰度策略选择矩阵

在实际项目中，选择哪种灰度策略取决于业务场景和技术能力。下表提供快速参考：

灰度策略的 Feature Flag 实现思路

在 Feature Flag 系统中，灰度策略通过规则引擎实现。以下是一个简化的策略配置示例（伪代码）：

// Feature Flag: new_checkout_flow
{
  "flag": "new_checkout_flow",
  "default": false,
  "rules": [
    {
      "type": "user_percentage",
      "percentage": 5,
      "targeting": ["user_id_hash % 100 < 5"]
    },
    {
      "type": "user_whitelist",
      "users": ["user_001", "user_002", "internal_test_group"]
    },
    {
      "type": "geo",
      "regions": ["cn-shanghai", "cn-beijing"],
      "sub_rules": {
        "type": "user_percentage",
        "percentage": 20
      }
    }
  ]
}

规则引擎按优先级依次匹配：先检查白名单，再检查地域，最后按比例兜底。匹配到第一条规则即返回对应变体（新版本或旧版本）。