全链路压测

一、背景

2021年11月份开始，新东方的同事来支援推进全链路压测，相比之前做的单接口压测，全链路压测能更准确的暴露出服务的性能瓶颈，能更针对性的进行性能优化。但是全链路压测比单接口压测更为复杂，需要覆盖各个典型的场景，每个场景需要预估流量分配，需要进行接口之间的上下文关联，有需要构造不同场景的数据。除此之外，公司还专门为做全链路压测搭建了一套与线上资源1:1的仿真线上环境。由此可见，全链路压测是个十分复杂的，且需要全员配合的庞大工程。

二、压测准备

2.1、压测场景分析

根据学生机上真实用户场景进行分析，对一般链路场景覆盖和核心链路场景进行覆盖（调第三方接口场景接口先排除）
学生机上的场景基本如下（具体见jmeter脚本）：

1. 观象台
2. 智慧学习
3. 魔镜
4. 智慧课堂
5. 个人中心
6. 首次调用请求集合
7. 新东方相关场景
   其中，答题场景接口放在智慧学习场景下，对于类似填空题需要生成avg文件的，选取100k大小的文件进行上传模拟

2.2、链路压测脚本准备

根据分析出的链路场景，通过jmeter进行接口关联起来，具体步骤如下：

1. 每个场景链路用一个单独的线程组
2. 在每个线程组下写对应场景的接口
3. 将需要关联的数据通过正则或jsonpath匹配来提取进行关联
4. 其他配置如，csv数据文件设置、登录token造数据、聚合报告等等
5. 调试成功后即可开始进行流量分配进行压测

2.3、整体数据准备（造各个平台的数据）

1.建立学校（oms平台）
2.老师、班级、学生（校后台和智慧学习工作台）
3.课程（教师空间）（需授权才能看见课程体系数据）
4.推送课程到智慧学习、智慧课堂预习、上课、测评等（教师机）

2.4、学生数据

1.用脚本造200名学生，将学生加入班级
2.200个学生的token数据，通过jmeter循环200次登录接口，用beanshell自动将生成的token保存到文件

三、压测难点分析

1.数据构造：部分数据构造困难，如学生账号、用户token生成等
2.场景分析：分析现有场景，结合线上实际流量场景、线上慢接口场景
3.代码限制逻辑：如错题重做最多3次
4.掉第三那方服务接口：如上传文件接口会调七牛服务（是通过做挡板或别的方式来进行压测该接口）
5.elk日志查看：看总体日志、错误日志等，通过日志定位压测问题

四、压测执行

压测方式：2种
1.瞬时并发压测（进行各场景流量分配后，循环一次）
a.从低到高增加线程数压测，在报告中看耗时最长的接口和错误的接口，进行记录，进行优化；
b.去掉耗时特别高的接口，留其他接口，继续增加线程数，直到出错，然后记录数据，循环此操作；
2.持续时间压测
a.持续时长10min，10min后，看各个场景的接口响应时长，并记录问题
具体压测执行记录，见学生端链路压测

五、压测遇到的问题及解决（具体优化见：研发优化）

1. 超时问题，有的服务固定超过5s即为超时；加缓存，如观象台接口增加缓存后，接口性能明显提高
2. 报504问题，nginx连接数打满，op调大后问题解决

**解决措施总结：**1.大部分接口通过添加缓存来进行优化，具体见：核心路径接口链路梳理；2.较少接口通过优化代码逻辑来优化，如上传文件接口；3.报504的通过修改nginx配置进行优化；4.通过修改线程大小进行优化；5.最后根据系统架构和调用情况，对服务pod进行扩容优化

学生端系统架构图如下：

六、链路压测需要用到的平台

1. rancher（没到yace环境之前）
   服务部署，修改pod数量
   看接口对应服务的cpu、内存是否达到瓶颈；
   修改configMap配置；
2. elk日志
   通过在elk日志上查询错误的日志
3. k8s平台
   （转移到yace平台后）服务部署平台，在这里添加服务的pod数和configmap相关的配置
4. 性能测试平台（新东方的压测平台（jemter的二次开发））
   优点：
   1. 可以生成jemter命令执行生成的报告（里面有聚合报告，点击数、耗时等图）；
      2.可保存历史执行的报告数据；

缺点：

1. 运行时不能试试查看；

2. 添加参数较为复杂；

3. 不支持本地的jemter脚本上传操作；

4. 阿里云平台
   其中链路拓扑

   1. 可以看出接口的调用的所有链路
      2.可以看出每个链路上耗时较高的方法（包括代码耗时和数据库sql耗时等）
      3.可以看到错误的链路和错误的日志
      4.可以清晰地看到哪个服务是流量入口，为设置pod数提供分析

七、压测最终系统调优结果

核心链路100%，整体99.9%（主要是持续优化性能提升稳定性）

（1）、当前压测环境能够同时支撑8000用户同时在线业务操作，相对智慧学习业务模块的成功率较低，仅76%左右，整体服务成功率在98%左右；

（2）、学生端服务整体QPS在3700左右，相对较稳定无较大波动；

（3）、涉及性能较差的接口建议优先优化，防止大流量请求时因慢请求导致服务性能抖动或频繁超时异常或业务线程阻塞；

八、风险分析

1、压测环境与生产环境差异较大，评估生产环境性能出入可能存在差异；

2、由于环境问题，当前压测环境未涉及绑定帐号相关的登录压测（需要评估是否移至线上完成一轮登录相关性能摸底）；

3、由于模拟压测过程中无法准确评估线上业务调用占比，因此模拟各模块业务调用量均是1:1方式，因此链路压测流量与实际调用可能存在流量调用占比不均的情况；

4、业务变更频繁，本次学生端性能评估仅支持2022年01月12日及之前的版本性能，后续版本服务性能需要再跟踪；

5、另外，魔拍相关业务以及涉及的第三方服务调用在该阶段未覆盖，请知悉；

九、全链路压测和日常单接口压测区别与建议（只是对我们公司）