全链路压测指的是基于实际的生产业务场景、系统环境,模拟海量的用户请求和数据对整个业务链进行压力测试,并持续调优的过程。常用于复杂业务链路中,基于全链路压力测试发现服务端性能问题。
随着公司业务的不断扩张,用户流量在不断提升,研发体系的规模和复杂性也随之增加。线上服务的稳定性也越来越重要,服务性能问题,以及容量问题也越发明显。为了及时暴露服务的各种稳定性问题,我们了引入了基于线上全链路压测的工具、研发体系。
本文主要介绍字节跳动的服务端全链路压测体系,以及字节跳动各种业务的全链路压测实践。
下图一个典型的网络架构,用户请求通过CDN溯源,经过TTGW,TLB,AGW,然后才到达业务服务PSM。(TTGW是头条的高性能4层负载均衡网关,TLB是七层负载均衡服务,AGW是头条统一业务Api接入层)
场景分类
主要目的
典型场景
主要特点
能力验证
验证在给定的软硬件条件下,系统能否具有预期表现
当前服务已经部署了n台机器,能否支持50万用户同时在线访问
1、软硬件环境都已经确定
2、有明确的性能目标
3、需要根据业务场景来构造压测数据和请求
容量规划
春节活动需要X亿人同时在线访问,系统需要如何调试?(性能优化,设计优化,资源预估)
1、它是一种探索性测试
2、常用于了解系统现状
3、需要根据系统现状,对未来系统进行一个预估和规划
性能调优
主要用于对系统性能进行调优
系统响应越来越慢,此时该如何处理?
1、对于代码级的优化,单实例压测即可
2、对于系统整体设计优化,需要集群压测,保证集群负载维持在一定水位
缺陷发现重现
发现/重现性能缺陷
服务线程死锁,内存泄漏等
1、需要对性能问题分类
2、针对每类问题构造对应的数据和压测策略
性能基准比较
系统新版本的性能验证
新版本的代码改动,是否有降低了系统性能,是否符合上线要求
1、有版本性能基准
2、固定环境因素的影响
3、AABDiff
4、diff置信度
在网络架构图中,明确展示了各系统各司其职,它们分别负责将用户请求做相应处理并将请求流转至下游服务。因此,根据压测方案的目的,选择一个合理的压测目标,可以减少大量的压测工作,提高压测效率。
目的
压测目标
压测带宽
从CDN、TLB处发压
春节活动需要X亿人同时在线访问,链路带宽是否足够?
压测业务逻辑
从汇聚机房、核心机房、卫星机房的AGW和业务服务发压
用户零点秒杀,是否能够保障商品、订单等系统一切正常?
压测异步消息
从MQproducer处发压
异步消息队列是否能够满足高压力场景?
在字节内部,线下测试环境是不允许压测的,由于线下资源不足,与线上环境差异大,压测出来的结论并不能充分保证线上的性能情况。因此本文指的压测都是在线上环境的压测。下文将重点介绍字节的全链路压测环境。
为了区分线上流量与压测流量,使服务可以针对压测流量做定制业务逻辑,服务架构体系在服务框架与服务治理层面设定了压测标记。
目的:
原理:
生效条件:
为了强化压测流量的管理,服务治理体系引入了压测开关的概念。压测开关作为总控制,所有服务框架必须判断压测开关是否打开,若打开才能允许通过压测流量,若关闭则只能拒绝压测流量。
对于压测数据的存储,必须将线上数据与压测数据做隔离,否则会导致压测数据量过大影响线上数据正常存取。
它是一个多功能压测平台,支持多种场景、模式的发压。Rhino统一管理了压测任务、压测数据、发压机、压测结果。集成了Bytemesh、User、Trace、Bytemock、Bytecopy等多个系统。
Rhino压测平台支持以下能力:
无法复制加载中的内容
根据不同业务的场景、以及压测的方案,业务方需要制定不同的发压方式,以达到压测预期效果。下面将介绍Rhino平台提供的四种发压方式,业务方需根据自身业务特点,选择适合的方式发压。
Fake流量压测是指用户自行构造压测请求进行压测。Rhino平台支持HTTP、Thrift两种协议的Fake流量发压。
Fake流量模式适合针对请求参数简单的接口压测,同时也适合针对特定请求进行压测。Rhino平台会为每个请求注入压测标记。
典型场景:
为了支持更多的协议与更复杂的压测场景,Rhino平台支持了GoPlugin发压模式。
依赖golang的plugin功能,运行时加载plugin文件,并加以执行
GoPlugin发压模式适合灵活构造请求数据、支持自定义协议、支持自定义发压场景,相当于所有发压场景都可以通过代码实现。注意Rhino平台对于GoPlugin模式不会注入压测标记,用户需在插件内加上压测标记。
为了使压测更贴近线上请求,Rhino平台支持了流量录制回放的发压模式,平台经过线上流量采集、线上流量改写为压测请求、压测流量回放三个步骤,将线上请求回放到压测目标中。
依赖bytecopy的采集流量能力,要求服务已经部署到线上,开启mesh,且有流量可以采集。
对于服务维度而言,如果想测试服务能承载多少QPS,每个接口的QPS分布情况,流量调度是一个比较合适的压测方式。Rhino平台支持了单实例的流量调度模式压测。
scheduler修改被测实例的consul权重,使流量不断打到目标实例中,而其他实例流量相应的减少,保持服务的总流量不变。压测的请求完全来自线上流量,不使用压测标识,因此压测流量的流转、存储均保持线上模式。同时scheduler会监控目标实例的服务指标,当服务指标到达阈值后将停止压测,将consul权重恢复至初始值。
下面将上述压测方式在压测目标、压测场景、优缺点维度下做对比,方便业务方选择合适的方式用于压测。
压测方法
Fake流量压测
自定义压测(Plugin)
流量录制回放
流量调度
作用目标
集群或单实例
单实例
压测场景
单接口/多接口(场景/流量配比)
单接口/多接口(任何形式)
服务维度
应用场景
新上线的服务;
压测方案为明确性能优化计划;
线上/线上任意协议接口接口;
单服务复杂压测场景;
跨多个服务混合场景;
压测数据构造复杂,要求数据多样性强;
线上数据快速压测;
单实例容量测试
缺点
压测数据构造形式单一
对用户代码能力要求较高;
任务需要自行调试
需要线上服务有流量;
服务开启mesh开关;
线上流量充足;
单实例不能线性反应整条链路的性能;
为了使压测结果更准确、使被测服务在压测过程中更安全,Rhino平台开发了一套压测专用的报警监控体系。分为实时客户端监控、被测服务端监控、ms报警监控。
公司的服务监控体系是基于metrics的30s一次聚合,但是对于压测任务而言,意味着观察压测状态需要等待30s的延时,这基本上是不能忍受的。因此Rhino平台支持了发压客户端维度的秒级监控,使用户可以及时观察压测状态,当压测出现异常时可以立即停止压测。
实现方案:
Rhino支持服务端角度的全链路监控,包括服务监控、机器资源监控、上下游监控。目前使用的是grafana面板展示,将全链路每个服务metrics、机器influxdb数据聚合展示到grafana中。未来将使用Argos展示服务端监控数据。
此外,Rhino平台还支持监控ms告警规则,当被测服务或下游服务触发了告警规则后,压测任务便自动停止,防止造成线上事故。
1.监控分析
可以从发压客户端监控、被测服务端监控发现异常,异常主要包括:
2.Lidar性能平台
3.系统层tracing分析
1.服务的CPU陡然升高,RPC调用和consul、etcd访问频繁超时,以及goroutine数目大涨。