4. 灰度策略模型设计
灰度发布的核心在于策略模型——即“如何精准地决定哪些流量走新版本、哪些流量走老版本”。一个健壮的自助上线平台需要支持多种策略维度，并能灵活组合。本章详细拆解四种最常用的灰度策略模型：基于用户ID、基于地域/IP、基于流量比例、基于标签。
设计原则：策略模型应具备“正交性”与“可叠加性”。正交性指各维度互不依赖；可叠加性指多个策略可同时生效（如“上海地域 + 10%比例 + 标签为VIP”），最终取交集或并集由平台配置决定。
4.1 基于用户ID的灰度
这是最精准的灰度方式，适用于定向邀请、内部员工验证、特定客户先行体验等场景。平台维护一个“白名单用户ID列表”，命中该列表的请求被路由至新版本。
| 特性 | 说明 |
|---|---|
| 匹配粒度 | 单个用户，精确到UID |
| 典型场景 | 内部员工尝鲜、核心客户提前验证、A/B测试小范围 |
| 数据来源 | LDAP/SSO系统、CRM客户表、手动导入CSV |
| 路由实现 | 网关层解析JWT或Header中的UID，查Redis/本地缓存白名单 |
| 优点 | 可追溯、可审计、用户体验一致（同一用户始终走同一版本） |
| 缺点 | 白名单维护成本高，大规模场景下不适用 |
避坑指南：用户ID灰度必须考虑“会话一致性”。如果用户在一次会话中多次请求，必须保证所有请求都路由到同一版本，否则会出现数据不一致或前端报错。建议在网关层使用一致性哈希或会话粘滞（Sticky Session）。
4.2 基于地域/IP的灰度
适用于区域灰度发布、合规性要求、CDN边缘节点验证。通过解析请求来源IP，判断其所属国家、省份、城市甚至运营商，从而决定路由目标。
- IP库依赖：需要维护一份高精度的IP地理数据库（如GeoIP2），并定期更新。
- 匹配模式：支持精确IP、CIDR网段、国家代码、省份名称、运营商白名单。
- 典型场景：新版本先在上海区域上线，验证稳定后再开放全国；或针对海外用户使用独立部署集群。
- 风险点：VPN/代理IP会导致误判；移动端用户IP频繁切换，可能造成路由抖动。
注意：地域灰度不能作为唯一的安全隔离手段。IP可伪造，且CDN回源IP可能掩盖真实客户端IP。建议结合用户ID或做二次校验。
4.3 基于流量比例的灰度
这是最“经典”的灰度策略，通过随机权重分配将一定比例的流量切到新版本。通常用于性能压测、容量评估、错误率监控等场景。
| 比例设置 | 典型用途 | 监控关注点 |
|---|---|---|
| 1% ~ 5% | 冒烟测试、基础功能验证 | 错误率、延迟P99、CPU/内存 |
| 10% ~ 30% | 功能回归、业务指标对比 | 转化率、下单成功率、DAU影响 |
| 50% ~ 100% | 全量放量前最终验证 | 全链路监控、告警阈值 |
实现方式通常有两种：
- 网关层随机采样：对每个请求生成0-100的随机数，若小于设定比例则路由至新版本。简单但无状态，同一用户可能在不同请求中命中不同版本。
- 一致性哈希分桶：对用户ID或设备ID做哈希，将哈希空间划分为100个桶，按桶分配版本。保证同一用户始终落在同一桶内，实现“用户级一致性”。
推荐做法：生产环境优先使用“一致性哈希分桶”实现比例灰度。虽然实现稍复杂，但能避免用户在不同版本间反复横跳导致的体验问题。分桶数建议为100或1000，便于精确控制百分比。
4.4 基于标签的灰度
标签灰度是最灵活、最强大的策略，允许运维或开发人员为请求打上任意维度的标签（如“渠道来源”、“设备型号”、“会员等级”、“操作系统版本”），然后根据标签匹配规则路由。
- 标签来源：请求Header、Cookie、JWT Claims、客户端SDK上报、业务参数。
- 匹配规则：支持精确匹配、正则匹配、范围匹配、多标签组合（AND/OR）。
- 典型场景：
- 仅对“iOS 15以上 + 会员等级≥V3”的用户开放新功能。
- 针对“渠道来源=抖音广告”的流量进行A/B测试。
- 对“设备指纹命中黑名单”的请求强制走老版本。
组合策略示例：某电商平台上线新版结算页，策略配置为“地域=北京 AND 流量比例=20% AND 标签=金牌会员”。最终只有同时满足三个条件的请求才会命中新版本。这种组合策略在自助上线平台中通过可视化规则引擎配置。
4.5 四种策略对比总览
| 策略类型 | 匹配维度 | 用户一致性 | 运维复杂度 | 适用规模 | 典型延迟 |
|---|---|---|---|---|---|
| 用户ID | UID白名单 | 强 | 低（维护列表） | 小规模（<1000人） | 毫秒级（缓存） |
| 地域/IP | IP库/网段 | 中（IP可能变） | 中（需更新IP库） | 中大规模 | 毫秒级（本地库） |
| 流量比例 | 随机/哈希桶 | 弱（随机）或强（哈希） | 低 | 任意规模 | 微秒级（本地计算） |
| 标签 | 任意请求属性 | 取决于标签来源 | 高（规则配置） | 任意规模 | 毫秒级（规则引擎） |
4.6 策略组合与优先级
在实际自助上线平台中，单一策略往往不够用。平台需要支持策略组合，并定义清晰的优先级规则：
- 黑名单优先：如果请求命中任何黑名单策略（如IP黑名单、用户黑名单），直接路由至老版本，不再继续匹配。
- 白名单次之：如果请求命中白名单策略（如内部员工ID），直接路由至新版本，跳过后续比例/标签判断。
- 标签与比例并行：对于既不在白名单也不在黑名单的请求，先进行标签匹配，再在匹配结果内进行比例灰度。
- 默认兜底：所有策略均未命中时，走老版本。
平台设计建议：在自助上线平台的策略配置页面，将策略分为“强制策略”（黑/白名单）和“柔性策略”（比例/标签）。强制策略优先级高于柔性策略，且不可被用户自行关闭，确保平台管控能力。
4.7 策略模型的可观测性
无论采用哪种策略，都必须提供实时可观测性，否则灰度发布就是“盲人摸象”。建议在网关层或Sidecar代理中输出以下指标：
| 指标名称 | 标签维度 | 用途 |
|---|---|---|
| 灰度请求总数 | 策略类型、版本号、地域 | 监控灰度流量是否符合预期比例 |
| 灰度命中率 | 策略类型、用户ID哈希 | 检测策略是否生效，是否存在漏命中 |
| 版本错误率对比 | 版本号、错误码 | 快速发现新版本引入的异常 |
| 版本延迟对比 | 版本号、P50/P95/P99 | 评估新版本性能退化 |
最佳实践：在灰度策略配置中，自动绑定一个“监控Dashboard”链接。开发人员在提交灰度上线单时，即可一键跳转到实时监控页面，观察策略命中情况和版本对比数据。这能极大降低上线风险。