4. 回放引擎设计：核心模块与架构选型
回放引擎是风控网关回放对比系统的计算核心，负责将生产流量按指定规则重新注入被测系统，并完成结果比对。本章从模块划分、架构视图、部署选型三个维度展开，帮助读者建立从单机原型到分布式集群的完整设计认知。
4.1 回放引擎核心模块
一个通用的回放引擎包含四个职责清晰的模块：读取（Reader）、匹配（Matcher）、执行（Executor）、比对（Comparator）。各模块之间通过内存队列或消息通道解耦，形成可水平扩展的流水线。
| 模块 | 职责 | 输入 | 输出 |
|---|---|---|---|
| Reader | 从存储层（Kafka / HDFS / 本地文件）拉取录制流量，反序列化为统一请求对象 | 原始录制数据（ProtoBuf / JSON / 二进制） | 标准化请求上下文（RequestContext） |
| Matcher | 根据回放策略（比例、标签、时间窗口）筛选并匹配待回放的请求 | 请求上下文 + 回放策略配置 | 匹配结果列表（MatchResult） |
| Executor | 将匹配后的请求重新发送到被测网关或服务，收集响应与上下文 | MatchResult + 目标地址 | 回放响应（ReplayResponse） |
| Comparator | 对比录制响应与回放响应，生成差异报告 | 录制响应 + 回放响应 + 比对规则 | 差异明细（DiffReport） |
设计要点：Reader 与 Executor 是 IO 密集型模块，建议使用异步非阻塞模型；Matcher 与 Comparator 是 CPU 密集型模块，可结合本地缓存与规则引擎提升吞吐。
4.2 引擎架构图
下图展示了回放引擎的内部模块协作关系与数据流。四个核心模块通过两个内部队列串联，形成“读取 → 匹配 → 执行 → 比对”的标准化流水线。
数据流说明：录制数据从存储层进入 Reader 反序列化后，经请求队列进入 Matcher 进行策略筛选；匹配通过的请求进入执行队列，由 Executor 发送到被测系统；最后 Comparator 将录制响应与回放响应进行字段级比对，输出差异报告。
4.3 单机与分布式回放选型
回放引擎的部署形态直接影响系统的吞吐能力、资源消耗与运维复杂度。下表从关键维度对比单机模式与分布式模式，帮助团队根据自身场景做出合理选择。
| 对比维度 | 单机回放 | 分布式回放 |
|---|---|---|
| 适用场景 | 日均回放量 < 10 万条，单服务回归验证 | 日均回放量 > 100 万条，全链路压测 |
| 吞吐能力 | 受单机 CPU / 内存 / 网络限制，通常 < 500 QPS | 可水平扩展，理论无上限（依赖集群规模） |
| 数据一致性 | 本地队列，无分布式一致性问题 | 需引入分布式协调（如 ZooKeeper / Etcd） |
| 运维复杂度 | 低，单进程部署，日志集中 | 高，需管理任务调度、节点注册、故障转移 |
| 资源成本 | 单台服务器即可运行 | 需要多台服务器 + 消息中间件 + 共享存储 |
| 典型选型 | 开发自测、CI 流水线快速验证 | 生产全量回放、大促前容量评估 |
选型建议：不要一开始就追求分布式。建议先以单机模式跑通回放流程，验证比对逻辑的正确性；当单机吞吐成为瓶颈时，再通过拆分 Reader 与 Executor 为独立进程，逐步演进为分布式架构。
4.4 分布式回放架构示意
当单机无法满足吞吐需求时，分布式回放引擎通过引入消息队列与任务调度器，将四个核心模块分散到多个节点上并行执行。下图展示了一种典型的分布式回放架构。
分布式关键设计：
- 分片读取：Reader 节点按录制数据的分区（Partition）并行拉取，避免重复读取。
- 无状态执行：Executor 节点不保存状态，通过消息队列获取任务，支持弹性伸缩。
- 异步比对：Comparator 采用异步消费模式，将比对结果写入共享存储（如 Elasticsearch），支持离线分析与可视化。
4.5 选型决策流程
在实际项目中，建议按照以下步骤快速确定回放引擎的部署形态：
- 评估回放规模：统计日均录制流量条数与峰值 QPS。
- 设定性能目标：明确回放任务需要在多长时间内完成（如 30 分钟）。
- 单机压测：使用单机模式运行小规模回放，记录实际吞吐与资源消耗。
- 瓶颈判断：若单机吞吐 < 目标吞吐的 60%，或 CPU / 内存持续超过 80%，则考虑分布式。
- 渐进式演进：先拆分 Reader 与 Executor 为独立进程，再引入消息队列，最后加入调度器与集群管理。
实战经验：某金融风控团队在日均 50 万条回放场景下，单机模式（8 核 16G）稳定运行 3 个月；当业务增长到日均 300 万条时，通过将 Reader 扩展为 3 节点、Executor 扩展为 5 节点，吞吐提升 6 倍，且未改动比对逻辑一行代码。