背景与挑战
在搜索系统中，C++ 引擎长期扮演着底层核心基础设施的角色：性能敏感、逻辑复杂、变更频繁，同时承载着大规模线上流量的稳定运行。随着业务持续发展和技术架构不断演进，我们逐步意识到：在高频迭代背景下，回归能力也需要同步升级。
过去一年，团队围绕搜索 C++ 引擎展开了一次系统性的回归能力工程化建设。这次升级不仅涉及工具链的完善，更是对质量保障流程的重构。
高频迭代下的回归压力
搜索 C++ 引擎的升级主要来自三类需求：业务功能需求、重要技术项目（有 QA 深度参与）、大量技术优化与结构性改造需求。
在实际迭代节奏中，技术优化与结构性改造类需求占比较高，引擎整体呈现出多人并行开发、持续迭代推进的状态。随着规模扩大，我们发现：现有回归环境更适用于单次项目式验证。多需求并行时，资源调度与复用能力仍有提升空间，回归准出标准尚未完全工程化。这意味着，在稳定性要求不断提升的背景下，我们有必要构建更加标准化、流程化的回归体系，让质量保障能力与迭代节奏匹配。
现有测试方式的演进空间
当前搜索引擎主要依赖两类测试手段：DIFF 测试和压测，这些手段在长期实践中发挥了重要作用，但随着业务复杂度提升，我们也逐步看到进一步优化的空间：
- 流量获取依赖下载日志、手工上传，自动化程度仍可提升。
- DIFF 过程中存在自然噪音，需要更精细化处理（如 AA DIFF、排序不稳定）。
- 报告与分析信息分散在不同工具中，定位效率有优化空间。
- 多套工具并行使用，缺乏统一平台化沉淀。
整体来看，测试能力更多体现为'工具能力集合'，而在流程标准化、资产沉淀与统一治理方面仍有提升空间。
建设目标
这次建设的目标，并不是简单'再做一个工具'，而是希望系统性解决以下问题：
- 让 DIFF 和压测成为搜索 C++ 引擎的标配回归能力。
- 让回归结果具备可分析、可归因能力。
- 让回归成为发布的硬性准出标准。
- 保证工具本身的稳定性，不成为新风险。
- 整体提升引擎的回归效率和交付质量。
- 通过流程和流水线，降低对'人'的依赖。
一句话总结：把回归这件事，从'靠自觉'，变成'靠系统'。
整体方案概览
围绕上述目标，我们将建设拆分为五个关键方向：流量录制、环境建设、DIFF 工具体系、一键压测能力、工具与索引平台集成。下面将会按模块展开说明。
流量录制：回归的基础设施
为什么先做流量录制
DIFF 和压测的核心前提只有一个：真实、稳定、可复用的流量。因此我们优先建设了搜索 C++ 引擎的流量录制链路，作为后续所有测试能力的基础。
流量如何触发
- 在索引平台集群详情页直接发起流量录制。
- 索引平台更新 ARK 配置中心中的录制配置。
- 搜索 C++ 引擎实时监听配置变化。
录制配置设计
所有配置统一收敛在 dsearch3#test.properties，支持：
- 全局开关。
- 指定 app / group。
- 截止时间。
- 指定 IP。
- 采样率（0～100）。
这使得录制行为可控、可回收、可精细化管理。
流量生成与存储
- 引擎侧根据配置生成 Kafka 消息。
- 多业务场景复用同一 ARK 集。
- 多场景流量复用同一个 Kafka Topic。
最终流量落入 ODPS，按天分区，字段包含：请求体、流量场景、实验信息、环境信息（生产 / 预发）。这为后续 DIFF、压测、问题复现提供了统一数据源。
流量存储字段说明：
