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进程。
- 熔断功能:系统会根据实时信息中的错误率进行判断,当一定时间内的实时错误率达到或超过某个阈值时,该次测试将被自动熔断,无需用户干预。
- 兜底脚本:最极端的情况,当整个系统不可用,而此时需要停止测试时,我们提供了一份外部脚本直接进行停止。