3. 灰度发布架构设计
Level2 行情灰度发布的核心在于：在不中断现有全量用户服务的前提下，逐步将新版本行情（如新的计算逻辑、新的数据字段或新的传输协议）开放给特定用户群体。本章从整体架构出发，明确数据源、灰度网关、路由层、消费端四个核心模块的职责，并定位灰度策略引擎在架构中的关键位置。
3.1 整体架构图
下图展示了 Level2 行情灰度发布的四层架构。数据从交易所源站流入，经过灰度网关的流量识别与策略匹配，由路由层分发至不同的消费端集群，最终送达终端用户。
3.2 核心模块职责
| 模块 | 职责 | 关键组件 |
|---|---|---|
| 数据源 | 对接交易所 Level2 行情源，完成协议解析、数据校验、时钟同步 | 行情网关、解码器、时钟同步模块 |
| 灰度网关 | 接收原始行情，调用策略引擎判断灰度规则，为行情数据注入灰度标签 | 流量拦截器、策略客户端、标签注入器 |
| 路由层 | 根据灰度标签将行情分发至对应集群（灰度/稳定），支持动态路由切换 | 消息队列（Kafka/Pulsar）、路由分发器 |
| 消费端 | 灰度用户与全量用户分别消费不同版本的行情，支持实时对比与回滚 | 行情 SDK、监控 Agent、AB 实验 SDK |
3.3 灰度策略引擎位置
灰度策略引擎是灰度发布的“大脑”，它不直接处理行情数据，而是为灰度网关提供决策依据。其位置在架构中具有以下特点：
- 独立部署：策略引擎与行情主链路分离，避免策略变更影响行情吞吐。
- 旁路查询：灰度网关通过本地缓存或远程 RPC 查询策略结果，查询超时则默认走稳定版本（降级保护）。
- 动态生效：策略引擎支持热更新，修改灰度比例或白名单后无需重启网关。
架构要点： 灰度策略引擎不阻塞行情主链路。灰度网关在收到行情后，先并行查询策略引擎（或本地缓存），再决定是否注入灰度标签。若策略引擎不可用，网关自动降级为全量稳定版本，保证系统高可用。
3.4 灰度策略引擎内部结构
策略引擎内部通常包含三个核心模块，它们协同完成灰度决策：
3.5 灰度策略决策流程
灰度网关与策略引擎的交互遵循以下步骤，确保每次行情分发都经过策略校验：
- 流量到达：灰度网关收到行情数据，提取用户标识（如 user_id、设备 ID）。
- 策略查询：网关向策略引擎发起查询请求，携带用户标识与行情版本号。
- 画像匹配：用户画像模块判断用户是否在白名单、灰度实验组或特定地域。
- 规则计算：规则引擎根据灰度比例（如 5%）、用户 hash 值计算是否命中灰度。
- 结果缓存：策略结果写入本地缓存（TTL 30s），避免重复查询。
- 标签注入：网关根据策略结果在行情消息头中注入
X-Gray-Tag: v2.1.0或X-Gray-Tag: stable。 - 路由分发：路由层根据标签将行情投递至对应消费端集群。
性能优化： 灰度网关与策略引擎之间采用异步非阻塞通信（如 gRPC Stream 或 Redis Pub/Sub），单次策略查询延迟控制在 1ms 以内。对于高频行情（如逐笔成交），网关优先使用本地缓存，策略变更通过版本号增量同步。
3.6 架构设计要点总结
| 设计原则 | 说明 |
|---|---|
| 主链路无阻塞 | 策略引擎旁路部署，网关降级策略保证行情不中断 |
| 标签驱动路由 | 灰度标签作为唯一路由依据，消费端无感知版本切换 |
| 策略热更新 | 灰度比例、白名单支持动态下发，无需重启网关或消费端 |
| 可观测性 | 灰度网关与策略引擎均暴露 Prometheus 指标，便于监控灰度流量占比 |
避坑提醒： 灰度网关不要将策略引擎的查询结果直接写入行情消息体，应使用消息头（Header）传递标签。避免污染行情数据格式，导致消费端解析异常。