全链路压测

2019/05/25 17:44
阅读数 161

1 阿里分享

2013年为了双11提前预演而诞生,该服务已提供在阿里云PTS铂金版。

1.1 可用性及单机压测问题

1.1.1 系统可用性问题

经常由下面一些不确定性因素引起:

  • 系统容量
  • 业务性能
  • 基础设施瓶颈
  • 中间件瓶颈
  • 系统直接的依赖影响

1.1.2 传统线上单机与单系统压测的四种方式

  • 模拟调用者压测生产环境:读请求+写请求(需要特定处理)
  • 流量录制和回放:快速率回放对单机压测

从流量分配的角度,将流量集中到某台机器(这两种方式要求访问流量不能太小):

  • 请求流量转发
  • 改变负载均衡的权重

1.1.3 单系统压测的问题

  • 在做单个系统的容量规划时,所有的依赖环节能力是无限的,进而使得我们获取的单机能力值是偏乐观的;
  • 采用单系统规划时,无法保证所有系统均一步到位,大多数精力都集中核心少数核心系统;
  • 部分问题只有在真正大流量下才会暴露,比如网络带宽等等。

1.2 全链路压测组成

单链路指一个业务线。

全链路压测是一个模拟线上环境的完整闭环,由5大核心要素组成:

  1. 压测环境:对应用户真实的线上环境,具备数据与流量隔离能力的生产环境; 原则:能够用中间件解决的问题,绝不对业务系统进行改造,系统所需做的是升级中间件,这一原则极大提高了工作效率。
  2. 压测基础数据:构造满足高峰场景的核心基础相关数据,影子库里构造相同量级的数据; 真实线上数据筛选脱敏。
  3. 压测流量(模型、数据):成百上千的接口组合,到复杂的接口之间的参数传递,复杂的条件判断来构造精准的全局流量模型,和真实业务情况保持一致;
    > 压测引擎的三层结构:
    • 协议支持
    • 请求发送:CGroup资源隔离,异步Reactor模型发送请求,链路间线程池隔离
    • 集群协作: Master,Slave长连接; Cristian算法同步网络延迟,Slave动作一致;
  4. 流量发起:模拟全国各地真实的用户请求访问,探测站点能力;
  5. 问题定位:多维度的监控和报表,服务端可通过其他生态产品协助定位。

翻译构造能力的体现:便捷的构造全局业务场景和流量数据的能力。

原子因素:链路(被压测的最小单位) 指令: 思考时间、集合点、条件跳转、cookie存取、全局准备、并发用户限制等

原子因素->串行链路->场景

1.3 超限后的流量控制

  • 丢弃请求
  • 对下游降级
  • 黑白名单
  • 请求排队

1.4 流量平台数据量

  • T级别的压测请求数据
  • 每秒1600W+次请求压测能力
  • 维持1亿+的无线长连接和登陆用户
  • 秒级的智能数据调度和引擎调度能力

2 京东分享

ForgeBot, 2016年开发

京东全链路压测军演系统(ForceBot)架构解密

最早基于开源的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进程。
    • 熔断功能:系统会根据实时信息中的错误率进行判断,当一定时间内的实时错误率达到或超过某个阈值时,该次测试将被自动熔断,无需用户干预。
    • 兜底脚本:最极端的情况,当整个系统不可用,而此时需要停止测试时,我们提供了一份外部脚本直接进行停止。
展开阅读全文
打赏
0
1 收藏
分享
加载中
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部