记一次全链路压测实践和心得

全链路压测

参照生产环境业务系统的流量模型设计出合理的性能测试策略，在完整链路中进行压力测试并持续调优的过程。

并发测试模式和RPS测试模式的区别：

观察的角度不同：
并发测试模式是从用户角度观察——比如10辆车同一时刻进入高速收费站
RPS测试模式是从服务器角度观察——收费站每秒能识别和通过多少台车

RT （Response Time 响应时间）
RPS （Request Per Second 每秒事务数）

业务分析和拆分：

1. 业务描述：对设备上报的数据进行清洗转换，阈值对比计算（若触发了预设的规则即刻要发出警告）， 最后入库和页面展示，每个设备都支持多种监控类型；

2. 业务链路如图：

设备数据上报 -> 收集服务 -> 写入Kafka -> 清洗服务 -> 写入redis并且与阈值对比计算 -> 写入数据库

流量预估：

400家影院，平均每家开设6个影厅， 平均每个厅安装有4台设备

那么总设备数量是： 400 * 6 * 4 = 9600 台， 如果把每个机器当作一个用户， 那么总共是9600个用户，并发数=9600

平均每台设备支持30个监控类型【例如一台高级电源提供 风扇转速 | 模块温度 | 环境湿度 等类型的数值读取】

那么总事务数是： 9600 * 30 = 288000 个

---

按传统方式并发公式来看，并发应设置为 288000个请求 / 秒，那RPS是不是就等于28.8万呢？

答： 我们从接收者（流量挡板）的角度来看， 理想状态下系统的瞬时事务数即为28.8万，可能你会下意识认为这个值就可以作为压测配置去执行，但是：

这与实际业务模型不符，我分析了生产数据后发现：

1. 一个设备不可能同一时刻发出30个类型的数据，最多的情况下1秒内发出了5个类型的数据，这只达到初期计算方式中的 1/6
2. 由于每个影院所处的区域和网络环境不一致，导致他们的设备数据上报后的传输时间也不一样

OK， 根据该2点我们大致明白了：RPS应等于 288000 * 1/6 = 48000 个

PS： 大家在做流量预估的时候可以参考本案例，尽可能根据生产环境得出流量模型，让压测过程更加贴近实际

---

容量规划：

基准测试：

单个数据上报， 直到前端展示耗时多久？即为：单个事务RT是多少

测试环境准备：
1. 测试机：
Locust在单机上能提供1000/s （处理器核心越多能提供的压力越大）左右的压力
2. 被测机器：
得到了基准性能指标后，调整配置参数，进行K8s集群部署，配置nginx负载均衡。

测试策略设计

1. Locust多开Slave分布式压测方案及脚本编写

---

//TODO
2021-03-12未完待续

//2. 压测脚本编写
//3. 系统监控和收集 -- 监控套件基于docker， 最合适的方式是用Prometheus(普罗米修斯) 收集系统资源日志, 然后用Grafana生成可视化图表
//4. 脏数据清理和配置还原
//5. 编写测试报告

3. 系统监控

   监控平台搭建: 使用docker部署Prometheus + Grafana可视化图表