2、回放对比评审的总体流程概览：从触发回放到输出评审报告的完整链路
回放对比评审并非一个孤立的测试动作，而是一条从事件触发到报告归档的完整数据链路。理解这条链路，有助于架构师在系统设计阶段合理划分模块边界、确定数据流向与异常处理策略。本章将这条链路拆解为6个核心阶段，并给出每个阶段的输入、输出与关键决策点。
2.1 完整链路阶段总览
下表列出了从触发到报告输出的6个阶段及其核心职责：
| 阶段 | 触发条件 | 核心产出 | 关键决策点 |
|---|---|---|---|
| ① 触发与采样 | 规则引擎 / 人工标记 / 定时任务 | 待回放请求快照 | 采样率、流量过滤策略 |
| ② 请求录制与存储 | 网关拦截到匹配请求 | 结构化录制日志（含上下文） | 脱敏规则、存储介质选择 |
| ③ 回放调度与执行 | 评审任务创建 | 回放结果数据集 | 回放速度、依赖Mock策略 |
| ④ 结果对比与差异计算 | 回放完成信号 | 差异明细列表 | 对比阈值、忽略字段配置 |
| ⑤ 人工评审与标注 | 差异列表生成 | 评审结论（通过/需修复/误报） | 差异分级、责任人指派 |
| ⑥ 报告生成与归档 | 评审结论确认 | PDF/HTML评审报告 | 报告模板、归档策略 |
2.2 链路流程图（阶段与数据流向）
下图展示了6个阶段之间的数据流转关系，以及各阶段之间的主要数据制品：
2.3 各阶段详细说明
2.3.1 触发与采样
- 触发方式：支持规则引擎自动触发（如：某接口响应时间突增50%）、人工在控制台标记、定时任务批量触发。
- 采样策略：全量录制（适用于核心交易链路） vs. 按比例采样（适用于高流量非核心接口）。
- 过滤规则：排除健康检查、心跳、静态资源等无效流量，避免存储与回放资源浪费。
架构建议：采样过滤器应置于网关最前端，避免无效请求进入后续录制链路，降低存储成本。
2.3.2 请求录制与存储
- 录制内容：请求头、请求体、路由参数、时间戳、原始响应（可选）。
- 脱敏处理：在写入存储前，对身份证、手机号、银行卡等敏感字段进行脱敏或哈希处理。
- 存储选型：推荐使用列式存储（如 Parquet + HDFS）或时序数据库，便于后续批量回放读取。
2.3.3 回放调度与执行
- 回放速率：支持“原速回放”与“压测回放”两种模式，后者用于验证系统容量。
- 依赖Mock：对下游依赖（如第三方接口、数据库）进行Mock，保证回放结果可对比。
- 执行引擎：通常采用异步非阻塞架构，支持并发回放，提升评审效率。
2.3.4 结果对比与差异计算
- 对比维度：响应状态码、响应体结构、关键字段值、响应时间。
- 忽略机制：配置忽略字段（如时间戳、traceId、随机数），避免无效差异干扰评审。
- 差异分级：致命差异（状态码不一致）、重要差异（金额字段不一致）、轻微差异（格式变化）。
2.3.5 人工评审与标注
- 评审界面：提供差异对比视图，左右分栏展示“基线版本”与“回放版本”。
- 标注操作：支持“通过”、“需修复”、“误报”三种结论，并附带备注。
- 批量操作：对于同一类差异（如时间戳不一致），支持批量标注为“误报”。
2.3.6 报告生成与归档
- 报告内容：评审概要、差异统计、详细差异列表、评审结论分布。
- 输出格式：PDF（用于正式归档）、HTML（用于在线查看）。
- 归档策略：按版本号+时间戳命名，存入对象存储（如S3、OSS），保留至少30天。
2.4 链路中的关键设计模式
在架构层面，回放对比评审链路通常采用以下两种设计模式：
| 模式 | 适用场景 | 优势 | 劣势 |
|---|---|---|---|
| 同步管道模式 | 小规模回放（单次 < 1000条） | 实现简单，调试方便 | 扩展性差，阻塞链路 |
| 异步事件驱动模式 | 大规模回放（单次 > 10000条） | 高吞吐，可水平扩展 | 需要消息队列，运维成本高 |
避坑提醒：在异步模式下，务必为每个回放请求生成唯一 traceId，并贯穿整个链路，否则在对比阶段将无法关联“录制请求”与“回放结果”。
2.5 链路中的关键指标
评审链路是否健康，建议关注以下三个核心指标：
- 录制覆盖率：实际录制请求数 / 应录制请求数 × 100%，目标 ≥ 99.9%。
- 回放成功率：成功回放请求数 / 总回放请求数 × 100%，目标 ≥ 99.5%。
- 评审效率：单次评审平均耗时（分钟），目标 ≤ 30分钟（1000条差异以内）。
以上6个阶段构成了回放对比评审的完整闭环。在实际系统落地时，建议先实现阶段①~④的自动化，再逐步完善阶段⑤的人工评审工具与阶段⑥的报告模板，避免一次性投入过大导致交付延期。