1 阿里分享
2013年为了双11提前预演而诞生,该服务已提供在阿里云PTS铂金版。
1.1 可用性及单机压测问题
1.1.1 系统可用性问题
经常由下面一些不确定性因素引起：
- 系统容量
- 业务性能
- 基础设施瓶颈
- 中间件瓶颈
- 系统直接的依赖影响
1.1.2 传统线上单机与单系统压测的四种方式
- 模拟调用者压测生产环境：读请求+写请求（需要特定处理）
- 流量录制和回放：快速率回放对单机压测
从流量分配的角度，将流量集中到某台机器（这两种方式要求访问流量不能太小）：
- 请求流量转发
- 改变负载均衡的权重
1.1.3 单系统压测的问题
- 在做单个系统的容量规划时，所有的依赖环节能力是无限的，进而使得我们获取的单机能力值是偏乐观的；
- 采用单系统规划时，无法保证所有系统均一步到位，大多数精力都集中核心少数核心系统；
- 部分问题只有在真正大流量下才会暴露，比如网络带宽等等。
1.2 全链路压测组成
单链路指一个业务线。
全链路压测是一个模拟线上环境的完整闭环，由5大核心要素组成：
- 压测环境：对应用户真实的线上环境，具备数据与流量隔离能力的生产环境； 原则：能够用中间件解决的问题，绝不对业务系统进行改造，系统所需做的是升级中间件，这一原则极大提高了工作效率。
- 压测基础数据：构造满足高峰场景的核心基础相关数据，影子库里构造相同量级的数据； 真实线上数据筛选脱敏。
- 压测流量（模型、数据）：成百上千的接口组合，到复杂的接口之间的参数传递，复杂的条件判断来构造精准的全局流量模型，和真实业务情况保持一致；
> 压测引擎的三层结构：- 协议支持
- 请求发送：CGroup资源隔离，异步Reactor模型发送请求，链路间线程池隔离
- 集群协作： Master，Slave长连接； Cristian算法同步网络延迟，Slave动作一致；
- 流量发起：模拟全国各地真实的用户请求访问，探测站点能力；
- 问题定位：多维度的监控和报表，服务端可通过其他生态产品协助定位。
翻译构造能力的体现：便捷的构造全局业务场景和流量数据的能力。
原子因素：链路（被压测的最小单位） 指令： 思考时间、集合点、条件跳转、cookie存取、全局准备、并发用户限制等
原子因素->串行链路->场景
1.3 超限后的流量控制
- 丢弃请求
- 对下游降级
- 黑白名单
- 请求排队
1.4 流量平台数据量
- T级别的压测请求数据
- 每秒1600W+次请求压测能力
- 维持1亿+的无线长连接和登陆用户
- 秒级的智能数据调度和引擎调度能力
2 京东分享
ForgeBot， 2016年开发
最早基于开源的NGrinder，能胜任单业务压测。Controller功能耦合重，支持的Agent数量有限。 之后开发了ForgeBot。
2.1 主要功能模块
- Controller：任务分配
- Task Service：负载任务下发，支持横向扩展。提供任务交互和注册服务。（gRPC:HTTP2+protobuf3）
- Agent：注册心跳，拉取任务、更新任务状态、 执行和停止worker process（采用Docker容器部署）
- Monitor Service:接受并转发压测数据给JMQ
- DataFlow:对压测数据做流式计算(输出TPS,TP999,TP99,TP90,TP50,MAX,MIN)，将计算结果存到DB(ES)
在管理端创建测试场景，Controller扫描发现场景，寻找空闲Agent资源。
任务分配时，Controller计算每个间隔的执行时间点和递增的虚拟用户数，由Agent动态加压减压。
在多个组件使用了gRPC框架通讯
分读压测和写压测
2.2 一些解决问题的思路
问题：如何模拟在某一个瞬间压力达到峰值？
解决方案：通过集合点功能实现，提前开启峰值所需足够数量的线程，通过计算确定各个时间点上不需要执行任务的线程数量，通过条件锁让这些线程阻塞。当压力需要急剧变化时，我们从这些阻塞的线程中唤醒足够数量的线程，使更多的线程在短时间进入对目标服务压测的任务。
问题：为了计算整体的 TPS，需要每个Agent把每次调用的性能数据上报，会产生大量的数据，如果进行有效的传输？
解决方案：对每秒的性能数据进行了必要的合并，组提交到监控服务
3 饿了么分享
3.1 业务模型的梳理
- 是否关键路径
- 业务的调用关系
- 业务的提供的接口列表
- 接口类型(http、thrift、soa等)
- 读接口还是写接口？
- 各接口之间的比例关系
3.2 数据模型的构建
3.2.1 写请求
压测方法：
- 用户、商户、菜品等在数量上与线上等比例缩放；
- 对压测流量进行特殊标记；
- 根据压测标记对支付，短信等环节进行mock；
-
根据压测标记进行数据清理；
读请求
压测方法：拉取线上日志，根据真实接口比例关系进行回放
3.2.2 无日志服务
压测方法：
- 构建压测数据使缓存命中率为0%时，服务接口性能，数据库性能；
- 缓存命中率为100%时，服务接口性能；
- 缓存命中率达到业务预估值时，服务接口性能；
3.3 压测工具
定制JMeter
3.4 压测指标监控和收集
- 应用层面
- 服务器资源
- 基础服务：中间件和数据库
要点：
- 响应时间不要用平均响应时间，关注95线；
- 吞吐量和响应时间挂钩
- 吞吐量和成功率挂钩
3.5 具体实现
SpringBoot+AngularJS.
测试期间产生的冷数据(用例数据、结果数据)持久化至MongoDB，热数据(实时数据)持久化至InfluxDB并定期清理。
分布式测试：重新实现JMeter的分布式调度
测试状态流转：各种流程形成闭环，要考虑各种异常。
主要流程：配置 -> 触发 -> 运行 -> 结果收集 -> 清理。
整个状态流转的实现，采用异步Job机制实现了类似状态机的概念，状态属性持久化到数据库中，便于恢复。
3.6 安全保障
由于是在线上真实环境，需要避免测试引起的服务不可用和事故。
- 权限管理：用户权限分级管理，不能随意触发他人的测试用例，同时高峰期和禁止发布期，不允许执行任何测试。
- 停止功能：这是面向用户的手动停止功能，用户可以随时点击运行状态下的测试用例上的停止按钮，后台会直接kill掉所有运行该测试用例的测试机上的JMeter进程。
- 熔断功能：系统会根据实时信息中的错误率进行判断，当一定时间内的实时错误率达到或超过某个阈值时，该次测试将被自动熔断，无需用户干预。
- 兜底脚本：最极端的情况，当整个系统不可用，而此时需要停止测试时，我们提供了一份外部脚本直接进行停止。