共计 2730 个字符，预计需要花费 7 分钟才能阅读完成。
背景介绍
容器化迁徙目标
随着易盾反垃圾业务的迅速倒退，业务集群的规模也在急剧增长，传统的通过物理机来部署的形式在灵便度上越来越达不到要求，次要痛点包含但不限于：资源利用率低、集群扩容 / 缩容老本高、业务集群混合部署导致故障不隔离等，因而，急需一种更好的形式来晋升运维和环境治理的效率。时至今日，容器化的伎俩曾经十分成熟，并且可扩展性、敏捷性、故障隔离等方面正是容器化的劣势。同时，网易团体的云计算部门基于 K8S 研发的轻舟平台与运维团队研发的诺亚平台为此提供了弱小的底层反对技术，易盾业务集群容器化堪称瓜熟蒂落。
容器化迁徙架构
迁徙的架构如下图所示，下层 nginx 分为杭州和建德两个集群，不便在不影响客户应用的状况下进行整体性能回归。业务服务全副迁徙，波及利用集群 100+。底层中间件、ddb 和 es 专用同一集群，保证数据的一致性。
容器化迁徙流程
整个迁徙流程一共分为方案设计、模块部署、功能测试、性能测试、故障演练、流量比照、灰度切流、DNS 切换等八个步骤，上面咱们次要围绕流量比照这个步骤进行开展。
痛点与窘境
驱使咱们去做流量比照的起因一共有四个。
• 第一，迁徙模块多、危险高，反垃圾的检测链路很长，两头波及到很多模块，两头任何一个模块出问题都会影响最终返回给客户的检测后果，咱们的保障覆盖范围须要包含整个链路。
• 第二，补充线上回归用例笼罩不到的场景，目前线上回归用例通过 Goapi 保护，笼罩了所有业务以及检测器，然而做不到百分百笼罩到所有的线上逻辑。须要额定的伎俩去做补充。
• 第三，开发侧的诉求，在迁徙计划的评审阶段，开发就提出诉求，上线前心愿能通过某种形式比对新老集群的流量，用大数据量去尽量笼罩到所有场景。
• 最初一个起因不足成果测试伎俩，心愿通过这个流量比照做到对成果测试的回归。
流量比照实际
计划选型
引流平台
引流平台是一个基于用户理论应用行为和应用数据，作为测试用例和数据的全自动接口效力工具。平台通过将线上用户的实在流量复制并使用于自动化回归测试当中，期间通过翻新的 Mock 机制，能够应用线上数据在测试环境实现增删改查所有类型的接口测试。应用海量用户数据，实现业务逻辑的高笼罩和精准笼罩，是现有接口测试伎俩一种无效增益伎俩。引流平台不仅可能实现低成本的日常自动化回归，同时能通过它提供的扩大能力支持系统重构降级的主动回归。
引流平台的劣势：
• 不须要额定的开发成本；
• 能获取到用户实在流量；
• 可视化操作、性能全面；
引流平台的劣势 & 危险点：
• 代码加强后利用响应工夫增大、TPS 升高（易盾客户对响应工夫十分敏感）；
• 只反对单利用流量录制，不反对全链路；
• 不反对依据条件获取指定流量；
思考到对利用性能影响以及不反对全链路，没有抉择引流的计划，然而这种思路值得咱们去借鉴。
自研工具
- 确定指标
P0 需要：
• 不影响线上利用性能、RT、TPS 等；
• 反对全链路流量比照；
• 反对历史流量回放；
• 反对指定流量获取；
P1 需要：
•尽量低的开发成本；
•反对后果报告；
2. 性能拆分 & 流程设计
性能拆分为四个模块，别离是数据获取、数据发送、后果比对和报告生成，各模块之间的交互流程如下图所示：
性能实现
样本获取
- 样本起源
为了保障样本数据的真实有效并且能保持数据的新鲜度，间接把线上数据作为起源之一。QA 的音视频仓库也是数据起源之一，仓库外面存储了结构的各种格局和时长的音视频数据。除此之外还反对 EXCEL 上传的办法，上传以及标记好的 Case。
- 样本筛选
想要获取指定类型的数据，能够通过不同字段的组合设置，在获取数据的时候，会依据字段属性进行筛选，保障获取线上样本丰盛度。譬如：
targetId=8544&hitType=10&spamType=100&requestRegion=cn-beijing
指定了获取业务 ID 为 8544 从北京发送的数据且命中了规定检测器且垃圾类型为色情的数据，最初获取的样本都合乎上述条件。
- 样本解决
因为原始数据的字段很多，有一些字段不影响检测成果，譬如 callback、publishTime 等。这些抽取的样本会存数据库，为了缩小样本大小，须要将这些额定字段解决掉。有些场景须要和样本历史命中后果做比对，因而这里咱们还要把原来的命中信息作为验证字段存起来，前面用来做比对。
- 模块流程设计
数据发送
计划选型
发送数据就是通过什么形式把什么数据往哪里发，数据咱们通过下面样本获取的模块曾经拿到了，接下来就是解决发送形式和发送地址的问题，这个性能正好是 Goapi 所具备的，秉承着不反复造轮子的理念，在评估过自研和间接用 Goapi 的优劣，咱们间接通过 Goapi 的 OpenApi 接口来实现数据发送的操作。
交互流程
平台与 Goapi 交互流程大抵分为 6 个步骤：
• Goapi 创立数据驱动的场景用例 / 单用例，前面数据发送都是基于此用例；
• 获取用例 ID，在平台增加此用例（后端会依据 ID 调用 Goapi 接口查问用例信息）；
• 更新数据驱动数据（步骤 3~6 是循环，直到所有样本跑完）；
• 触发用例执行；
• 轮询工作执行状态；
• 获取执行后果并保留；
具体交互流程如下图：
后果比对
多环境后果比对
样本在多个环境执行实现当前，汇总执行后果依据样本 ID 和执行域名进行分组，随后依据匹配模式和匹配字段进行匹配，最初生成比对的后果存在数据库中。多环境比对的形式实用于机器资源多，环境部署不便，底层依赖的中间件是同一套场景。
历史后果执行比对
样本执行实现当前，获取原始样本的预期后果，将最新后果和预期后果做比照，最初生成比对的后果存在数据库中。历史后果比对的形式实用于环境只有一套然而样本的预期后果比较稳定的场景。
遇到的问题
GOAPI
• GOAPI 数据驱动只反对上传 EXCEL 更新数据 => 推动平台反对接口方式更新数据；
• 数据驱动的执行形式是串行、耗时太高 => 推动平台能够设置执行并发数；
样本提取
- 提取样本数据局部字段不存在导致执行串数据 => 减少样本字段补全逻辑；
- 反垃圾图片样本生效的状况 => 减少判断图片生效逻辑；
- 文本特殊字符导致 GOAPI 加密有问题 => 减少特殊字符过滤逻辑；
工作执行
- 失败 case 重跑流程简单 => 减少一键重跑；
- 缩小人为操作带来误差 => 多个环境交替执行，可人工设置验证数量；
- 工作触发无奈中断 => 减少停止操作；
收益和产出
• 两个我的项目进行落地（反垃圾 & 反外挂）；
• 反垃圾建德容器化迁徙回归发现两个问题：
1.【建德迁徙】文本建德 / 线上比照回归局部 case 不统一，文本分类模型版本不统一导致；
2.【建德迁徙】规定 scheduler 没有部署（怕影响线上），导致批改规定没刷新。
将来布局
• 优化异步接口的流程；
• 优化场景用例存在上下文依赖导致并行执行串数据的问题；
• 摸索在反垃圾测试回归和线上回归落地；
• 反对更多匹配形式；
• 继续优化执行慢的问题。
