全链路压测
参照生产环境业务系统的流量模型设计出合理的性能测试策略，在完整链路中进行压力测试并持续调优的过程。
并发测试模式和RPS测试模式的区别：
观察的角度不同：
并发测试模式是从用户角度观察——比如10辆车同一时刻进入高速收费站
RPS测试模式是从服务器角度观察——收费站每秒能识别和通过多少台车
RT （Response Time 响应时间）
RPS （Request Per Second 每秒事务数）
业务分析和拆分：
-
业务描述：对设备上报的数据进行清洗转换，阈值对比计算（若触发了预设的规则即刻要发出警告）， 最后入库和页面展示，每个设备都支持多种监控类型；
-
业务链路如图：
设备数据上报 -> 收集服务 -> 写入Kafka -> 清洗服务 -> 写入redis并且与阈值对比计算 -> 写入数据库
流量预估：
400家影院，平均每家开设6个影厅， 平均每个厅安装有4台设备
那么总设备数量是：
400 * 6 * 4 = 9600台， 如果把每个机器当作一个用户， 那么总共是9600个用户，并发数=9600
平均每台设备支持30个监控类型【例如一台高级电源提供 风扇转速 | 模块温度 | 环境湿度 等类型的数值读取】
那么总事务数是：
9600 * 30 = 288000个
按传统方式并发公式来看，并发应设置为 288000个请求 / 秒，那RPS是不是就等于28.8万呢？
答： 我们从接收者（流量挡板）的角度来看， 理想状态下系统的瞬时事务数即为28.8万，可能你会下意识认为这个值就可以作为压测配置去执行，但是：
这与实际业务模型不符，我分析了生产数据后发现：
- 一个设备不可能同一时刻发出30个类型的数据，最多的情况下
1秒内发出了5个类型的数据，这只达到初期计算方式中的1/6 - 由于每个影院所处的区域和网络环境不一致，导致他们的设备数据上报后的传输时间也不一样
OK， 根据该2点我们大致明白了：RPS应等于 288000 * 1/6 = 48000 个
PS： 大家在做流量预估的时候可以参考本案例，尽可能根据生产环境得出流量模型，让压测过程更加贴近实际
容量规划：
基准测试：
单个数据上报， 直到前端展示耗时多久？即为：单个事务RT是多少
测试环境准备：
1. 测试机：
Locust在单机上能提供1000/s （处理器核心越多能提供的压力越大）左右的压力
2. 被测机器：
得到了基准性能指标后，调整配置参数，进行K8s集群部署，配置nginx负载均衡。
测试策略设计
- Locust多开Slave分布式压测方案及脚本编写
//TODO
2021-03-12未完待续
//压测脚本编写
//数据收集 -- 环境基于docker， 最合适的方式是用Prometheus(普罗米修斯) 监控和日志收集
//编写测试报告
//脏数据清理和配置还原
