4. 灰度发布核心概念：灰度组、灰度策略、灰度流量比例、灰度监控指标
灰度发布（Canary Release / Gray Release）是高频行情回放验证体系中，从离线仿真过渡到在线验证的关键环节。其核心目标是以可控风险将新版本行情处理逻辑逐步引入生产环境，通过真实流量验证系统正确性与稳定性。本节围绕四个核心概念展开：灰度组、灰度策略、灰度流量比例、灰度监控指标。
概念定位：灰度组定义“谁先验证”，灰度策略定义“如何选择”，灰度流量比例定义“放多少量”，灰度监控指标定义“如何判断成败”。四者构成灰度发布的完整闭环。
4.1 灰度组（Gray Group）
灰度组是灰度发布的最小执行单元，代表一组接收灰度流量的实例或用户。在高频行情场景中，灰度组通常按行情源、交易对或机房划分。
| 灰度组类型 | 划分依据 | 典型场景 |
|---|---|---|
| 按行情源 | 交易所 / 数据源 ID | 仅对 Binance 行情启用新解码器 |
| 按交易对 | 交易对哈希取模 | BTC/USDT 走灰度，ETH/USDT 走基线 |
| 按机房 | 物理机房 / 可用区 | 北京机房灰度，上海机房基线 |
| 按实例 ID | Pod / 进程编号 | K8s 中 10% Pod 升级为新版本 |
灰度组设计原则：
- 隔离性：灰度组与基线组之间无共享状态（如共享内存、数据库写冲突）。
- 代表性：灰度组应覆盖主要行情类型（快照、增量、心跳），避免仅测试单一数据流。
- 可回滚：灰度组应支持一键切回基线版本，无需重启整个集群。
4.2 灰度策略（Gray Strategy）
灰度策略决定“哪些流量进入灰度组”。常见策略包括：
- 随机采样策略：按请求 ID 或行情序列号哈希取模，随机分配灰度组。适用于无状态行情处理节点。
- 白名单策略：指定特定交易对、特定用户或特定数据源进入灰度。适用于定向验证新功能。
- 地域/机房策略：按客户端 IP 或机房标识路由。适用于多机房部署场景。
- 时间窗口策略：仅在指定时间段（如非交易高峰）开启灰度。适用于风险控制。
注意：灰度策略必须与灰度组定义一致。例如，若灰度组按交易对划分，则策略应基于交易对哈希路由，而非随机采样，否则会导致同一交易对的部分行情进入灰度、部分进入基线，造成数据不一致。
4.3 灰度流量比例（Gray Traffic Ratio）
灰度流量比例指分配给灰度组的流量占总流量的百分比。比例选择需平衡验证充分性与风险暴露面。
| 阶段 | 推荐比例 | 目的 |
|---|---|---|
| 初始验证 | 1% – 5% | 验证基本功能无崩溃、无数据丢失 |
| 功能验证 | 5% – 20% | 验证行情正确性、延迟、吞吐量 |
| 压力验证 | 20% – 50% | 验证高负载下的稳定性与资源消耗 |
| 全量发布 | 100% | 灰度组替换基线组，完成发布 |
比例调整策略：
- 阶梯递增：每次比例翻倍或固定增量（如 1% → 5% → 20% → 50% → 100%），每阶段观察 10-30 分钟。
- 自动回滚：当监控指标触发阈值时，自动将比例降回 0%，并告警。
- 比例粒度：建议支持 1% 粒度调整，避免跳变过大。
4.4 灰度监控指标（Gray Monitoring Metrics）
灰度监控指标是判断灰度发布成败的量化依据。高频行情场景下，核心指标分为四类：
| 指标类别 | 具体指标 | 对比方式 | 告警阈值 |
|---|---|---|---|
| 正确性 | 行情字段一致性、序列号连续性、校验和匹配率 | 灰度组 vs 基线组逐笔对比 | 不一致率 > 0.01% |
| 延迟 | 端到端延迟 P50/P99/P999 | 灰度组 vs 基线组延迟分布 | P99 延迟增加 > 20% |
| 吞吐量 | 每秒处理行情数、每秒推送数 | 灰度组 vs 基线组吞吐量 | 吞吐量下降 > 10% |
| 资源消耗 | CPU 使用率、内存占用、GC 暂停时间 | 灰度组 vs 基线组资源曲线 | CPU 增加 > 30% 或 OOM |
关键对比原则：灰度组与基线组必须运行在相同时间窗口、相同行情源下进行对比。避免因行情波动导致误判。建议使用滑动窗口（如 5 分钟窗口）计算指标差异。
4.5 灰度发布核心概念总结
| 概念 | 定义 | 关键设计点 |
|---|---|---|
| 灰度组 | 接收灰度流量的实例集合 | 隔离性、代表性、可回滚 |
| 灰度策略 | 流量分配规则 | 随机/白名单/地域/时间窗口 |
| 灰度流量比例 | 灰度组流量占总流量的百分比 | 阶梯递增、自动回滚、粒度 1% |
| 灰度监控指标 | 判断灰度成败的量化依据 | 正确性/延迟/吞吐量/资源消耗 |
实践建议：在首次搭建灰度发布体系时，建议先以“单交易对 + 5% 流量 + 正确性指标”作为最小验证闭环，跑通后再逐步扩展策略与指标维度。避免一开始就追求全量指标覆盖，导致监控噪声过大。