基于流量双发平台的高效回归方案

背景介绍

容器化迁移目的

随着易盾反垃圾业务的迅速发展，业务集群的规模也在急剧增长，传统的通过物理机来部署的方式在灵活度上越来越达不到要求，主要痛点包括但不限于：资源利用率低、集群扩容/缩容成本高、业务集群混合部署导致故障不隔离等，因此，急需一种更好的方式来提升运维和环境管理的效率。时至今日，容器化的手段已经非常成熟，并且可扩展性、敏捷性、故障隔离等方面正是容器化的优势。同时，网易集团的云计算部门基于 K8S 研发的轻舟平台与运维团队研发的诺亚平台为此提供了强大的底层支持技术，易盾业务集群容器化可谓水到渠成。

容器化迁移架构

迁移的架构如下图所示，上层 nginx 分为杭州和建德两个集群，方便在不影响客户使用的情况下进行整体功能回归。业务服务全部迁移，涉及应用集群 100+。底层中间件、ddb 和 es 公用同一集群，保证数据的一致性。

容器化迁移流程

整个迁移流程一共分为方案设计、模块部署、功能测试、性能测试、故障演练、流量对比、灰度切流、DNS 切换等八个步骤，下面我们主要围绕流量对比这个步骤进行展开。

痛点与困境

驱使我们去做流量对比的原因一共有四个。
• 第一，迁移模块多、风险高，反垃圾的检测链路很长，中间涉及到很多模块，中间任何一个模块出问题都会影响最终返回给客户的检测结果，我们的保障覆盖范围需要包括整个链路。
• 第二，补充线上回归用例覆盖不到的场景，目前线上回归用例通过 Goapi 维护，覆盖了所有业务以及检测器，但是做不到百分百覆盖到所有的线上逻辑。需要额外的手段去做补充。
• 第三，开发侧的诉求，在迁移方案的评审阶段，开发就提出诉求，上线前希望能通过某种方式比对新老集群的流量，用大数据量去尽量覆盖到所有场景。
• 最后一个原因缺乏效果测试手段，希望通过这个流量对比做到对效果测试的回归。

流量对比实践

方案选型

引流平台

引流平台是一个基于用户实际使用行为和使用数据，作为测试用例和数据的全自动接口效能工具。平台通过将线上用户的真实流量复制并运用于自动化回归测试当中，期间通过创新的 Mock 机制，可以使用线上数据在测试环境实现增删改查所有类型的接口测试。使用海量用户数据，实现业务逻辑的高覆盖和精准覆盖，是现有接口测试手段一种有效增益手段。引流平台不仅能够实现低成本的日常自动化回归，同时能通过它提供的扩展能力支持系统重构升级的自动回归。

引流平台的优势：
• 不需要额外的开发成本；
• 能获取到用户真实流量；
• 可视化操作、功能全面；

引流平台的劣势&风险点：
• 代码增强后应用响应时间增大、TPS 降低（易盾客户对响应时间非常敏感）；
• 只支持单应用流量录制，不支持全链路；
• 不支持根据条件获取指定流量；

考虑到对应用性能影响以及不支持全链路，没有选择引流的方案，但是这种思路值得我们去借鉴。

自研工具

1. 确定目标
   P0需求：
   • 不影响线上应用性能、RT、TPS 等；
   • 支持全链路流量对比；
   • 支持历史流量回放；
   • 支持指定流量获取；

P1需求：
•尽量低的开发成本；
•支持结果报告；

2. 功能拆分&流程设计
功能拆分为四个模块，分别是数据获取、数据发送、结果比对和报告生成，各模块之间的交互流程如下图所示：

功能实现

样本获取

1. 样本来源
   为了保证样本数据的真实有效并且能保持数据的新鲜度，直接把线上数据作为来源之一。QA 的音视频仓库也是数据来源之一，仓库里面存储了构造的各种格式和时长的音视频数据。除此之外还支持 EXCEL 上传的方法，上传以及标记好的 Case。

2. 样本筛选
   想要获取指定类型的数据，可以通过不同字段的组合设置，在获取数据的时候，会根据字段属性进行筛选，保证获取线上样本丰富度。譬如：
   targetId=8544&hitType=10&spamType=100&requestRegion=cn-beijing
   指定了获取业务 ID 为 8544 从北京发送的数据且命中了规则检测器且垃圾类型为色情的数据，最后获取的样本都符合上述条件。

3. 样本处理
   由于原始数据的字段很多，有一些字段不影响检测效果，譬如 callback、publishTime 等。这些抽取的样本会存数据库，为了减少样本大小，需要将这些额外字段处理掉。有些场景需要和样本历史命中结果做比对，因此这里我们还要把原来的命中信息作为验证字段存起来，后面用来做比对。

4. 模块流程设计
   

数据发送

方案选型

发送数据就是通过什么方式把什么数据往哪里发，数据我们通过上面样本获取的模块已经拿到了，接下来就是解决发送方式和发送地址的问题，这个功能正好是 Goapi 所具备的，秉承着不重复造轮子的理念，在评估过自研和直接用 Goapi 的优劣，我们直接通过 Goapi 的 OpenApi 接口来完成数据发送的操作。

交互流程

平台与 Goapi 交互流程大致分为 6 个步骤：
• Goapi 创建数据驱动的场景用例/单用例，后面数据发送都是基于此用例；
• 获取用例 ID，在平台添加此用例（后端会根据 ID 调用 Goapi 接口查询用例信息）；
• 更新数据驱动数据（步骤 3~6 是循环，直到所有样本跑完）；
• 触发用例执行；
• 轮询任务执行状态；
• 获取执行结果并保存；

详细交互流程如下图：

结果比对

多环境结果比对
样本在多个环境执行完成以后，汇总执行结果根据样本 ID 和执行域名进行分组，随后根据匹配模式和匹配字段进行匹配，最后生成比对的结果存在数据库中。多环境比对的方式适用于机器资源多，环境部署方便，底层依赖的中间件是同一套场景。

历史结果执行比对
样本执行完成以后，获取原始样本的预期结果，将最新结果和预期结果做对比，最后生成比对的结果存在数据库中。历史结果比对的方式适用于环境只有一套但是样本的预期结果比较稳定的场景。

遇到的问题

GOAPI

• GOAPI 数据驱动只支持上传 EXCEL 更新数据 => 推动平台支持接口方式更新数据；
• 数据驱动的执行方式是串行、耗时太高 => 推动平台可以设置执行并发数；

样本提取

1. 提取样本数据部分字段不存在导致执行串数据 => 增加样本字段补全逻辑；
2. 反垃圾图片样本失效的情况=> 增加判断图片失效逻辑；
3. 文本特殊字符导致 GOAPI 加密有问题 => 增加特殊字符过滤逻辑；

任务执行

1. 失败 case 重跑流程复杂 => 增加一键重跑；
2. 减少人为操作带来误差 => 多个环境交替执行，可人工设置验证数量；
3. 任务触发无法中断 => 增加中止操作；

收益和产出

• 两个项目进行落地（反垃圾&反外挂）；
• 反垃圾建德容器化迁移回归发现两个问题：
1.【建德迁移】文本建德/线上对比回归部分 case 不一致，文本分类模型版本不一致导致；
2.【建德迁移】规则 scheduler 没有部署（怕影响线上），导致修改规则没刷新 。

未来规划

• 优化异步接口的流程；
• 优化场景用例存在上下文依赖导致并行执行串数据的问题；
• 探索在反垃圾测试回归和线上回归落地；
• 支持更多匹配方式；
• 持续优化执行慢的问题。