4. 回放验证架构设计
回放验证架构是分层试验回放验证体系的核心骨架。它决定了回放数据如何采集、如何被引擎重放、以及如何与真实流量进行比对。一个健壮的架构需要同时解决数据源的可靠性、引擎的吞吐能力以及比对机制的准确性。本章将从三个核心维度展开：回放数据源、回放引擎设计、回放结果比对机制。
4.1 回放数据源
回放数据源是验证的“燃料”。根据数据存储与采集方式的不同，主要分为三类：日志、消息队列、数据库。选择哪种数据源，取决于系统的实时性要求、数据量级以及历史数据的可回溯性。
| 数据源类型 | 典型场景 | 优势 | 劣势 |
|---|---|---|---|
| 日志 | Nginx 访问日志、应用业务日志 | 格式固定、易于离线批量处理、存储成本低 | 实时性差、解析开销大、可能丢失上下文 |
| 消息队列 | Kafka、RocketMQ 中的实时流量 | 高吞吐、低延迟、天然支持回放与回溯 | 依赖中间件稳定性、消息顺序需额外保证 |
| 数据库 | MySQL Binlog、MongoDB Oplog | 数据完整、支持精确状态还原 | 对源库有性能影响、数据量膨胀快 |
实践建议：在分层试验中，推荐将消息队列作为主要回放数据源。它既能承载高并发流量，又能通过 offset 管理实现精确的“断点续传”，非常适合与回放引擎对接。
4.2 回放引擎设计
回放引擎是架构中的“发动机”。它负责从数据源拉取请求，按照原始时间戳或业务逻辑顺序，向被测系统（SUT）重新发送请求，并收集响应。设计时需重点关注：流量模型、并发控制、上下文隔离。
引擎设计要点：
- 流量模型：支持“按时间戳回放”和“按比例回放”两种模式。前者用于精确复现，后者用于压力测试。
- 并发控制：通过信号量或线程池限制最大并发数，防止回放流量压垮被测系统。
- 上下文隔离：每个回放请求必须携带唯一 TraceID，确保日志与监控数据可独立追踪。
4.3 回放结果比对机制
比对机制是验证的“裁判员”。它决定了回放结果是否通过验证。比对不能仅停留在“响应状态码是否一致”，而需要深入到业务字段、响应耗时、依赖调用等多个维度。
4.4 比对维度与策略
比对机制需要覆盖以下三个核心维度，缺一不可：
| 比对维度 | 比对内容 | 常见策略 | 失败处理 |
|---|---|---|---|
| 字段级比对 | JSON 字段、业务状态码、错误信息 | 精确匹配 / 模糊匹配（忽略时间戳、随机数） | 记录差异字段，标记为“字段不一致” |
| 耗时比对 | P50、P99 响应时间 | 阈值比对（回放耗时 ≤ 基线耗时 × 1.2） | 超时则标记为“性能退化” |
| 依赖比对 | 下游 RPC 调用次数、调用顺序 | 调用链拓扑比对 | 调用缺失或新增则标记为“依赖异常” |
避坑指南：字段级比对时，务必配置“忽略字段白名单”。例如，
request_id、timestamp 等每次请求都会变化的字段，如果不忽略，会导致大量误报。建议在比对引擎中内置一个可配置的 JSON Path 忽略列表。
4.5 架构总览
将数据源、引擎、比对机制整合在一起，形成完整的回放验证架构。下图展示了各模块之间的协作关系：
架构总结：
- 数据源层负责提供原始流量，推荐优先使用消息队列。
- 引擎层负责流量的拉取、排序、发送与隔离，是性能瓶颈的关键点。
- 比对层负责多维度结果校验，输出最终的通过/失败结论。
- 三层之间通过标准接口（如 gRPC 或 HTTP）解耦，便于独立扩展与维护。