有道精品课全链路测试的改进和思考
01 导读
02 背景
03 具体实践
3.1
整体目标
容量规划：以整体流量和业务目标为基础，估算出每个子系统需要满足的容量大小，结合压测情况，对系统进行适当的扩容和优化，确保系统能够满足业务流量压力。 流量控制及降级：系统需要防止流量超过可支撑的容量，对超出设计的流量进行限流，对超负荷or异常的服务及时进行降级。这里主要验证：限流和降级策略的合理性和可用性。 监控：测试现有监控手段是否能合理发现和暴露问题，以便对问题及时预警，做到早发现，早治理。 演练预案：对系统可能面临的问题要进行全面的预演，比如基础服务异常，机房故障等等灾难模拟的手段来检验系统表现以及准备合理的处理方案。
3.2
流程
3.3
常见问题解决方案分享
可以说模型的准确性直接关乎压测的成败，去年我们的模型中漏掉了退换课接口，但是这个接口存在比较严重的性能问题，直接触发了系统的级联故障，影响很大。 如何获取准确的模型，我们讲究“取之于实际，用之于实际”。即获取前一次续报活动的实际调用情形，通过数据清洗与整理，结合本次的预估数据量及sop，量化本次压测的指标。可参考下图：
通过我们的自研工具，完成日志自动解析、接口列表补充、压测场景确定等工作。一部分处理流程如下：（备注：npt为杭研的压测平台简称）
将SOP转化为接口路径。传统方式是抓包后，人工筛选、对比、整理抓包结果，再将接口变更情况手动同步到压测平台，该工作较繁琐且重复。这部分我们提炼成web工具后，仅需要上传抓包文件，就可以得到场景级别的接口增减情况，并支持“场景级别的接口列表维护”、“设置接口黑名单”、“接口一键导入压测平台”等功能，效果展示：
最终效果：不管是接口列表或者量级，我们压测模拟的流量跟实际流量几乎是一致的。
一键开启goreplay录制进程，自定义录制单个服务所对应的所有pod上的（or部分）流量。 终止录制时，自动将录制好的流量存储到物理机器中，并提供录制流量的分析功能。 使用容器节点进行离线流量回放，不依赖物理机器，根据实际需求创建n个回放副本。支持一键开启回放进程。 给定namespace、container，一键关闭所有pod的goreplay进程，终止流量拷贝/回放工作。
在压测过程中，性能优化是必不可少的，那么快速完成优化后的接口功能验证是性能测试能继续进行的重要保障；实际遇到过很多种需要进行功能回测的场景，比如：需要修改接口本身逻辑，例如单查改为批量查询等；更换数据源，例如从查询es改为查询doris等，这里手工回测和我们现有的接口自动化回测都具有一定的局限性，所以我们引入了流量分析+diff方案，测试高效并且覆盖率高。 核心目标是：对比数据量多，对比速度快，操作简单方便，使用流程： 关于数据对比，满足我们要求的第三方库有很多，比如常见的deepDiff、difflib、json-diff、json_tools等，都有各自侧重点。其中DeepDiff可以对比字段、字符串等可迭代的对象，针对对象的深层差异，支持递归查找所有更改，同时支持对比的格式也很多，包括JSON、XML、图片等，因为功能比较完善并且满足我们的需求，我们最终实现选用了deepDiff库。
04 总结
4.1
收益
经过多轮压测，发现了大于20个的性能问题和优化项，在最后实际开闸期间，系统表现优秀，业务方反馈很好。 整个系统的稳定性有显著提升，日常故障率明显降低。 群策群力，产出了一份完善的压测作战手册作为后续大型活动压测任务的指导性文档。
4.2
后续展望
压测日常化→关于压测执行这部分，后续我们会与开发运维一起，部署一套压测专属环境，建立日常压测流程及标准，在新的变更上线前尽早发现和优化性能问题，避免临时抱佛脚。 无人值守压测→ 目前每次全链路测试，我们都需要压测执行的测试和研发人员线上实时关注监控报警等，以便及时发现和定位问题，后续希望在压测时接入我们的各种服务和接口报警系统，达到问题自动发现和产出报告的效果。 相关工具的易用性拓展，提供给开发自主回测→上面提到的一些工作，仍然存在大量的人工操作，目前我们正在做进一步的工具开发，包括diff工具增加结果展示的对比和统计，流量回放web操作页面等等。 性能瓶颈分析工具→ 当前出现性能问题时一般是靠研发人员进行人工定位和排查，后续会调研能否利用apm系统做一些问题初步分析的事情。 工具集成化，赋能其他业务线。
往期推荐