什么是全链路压测?

基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程

主要特征：

全链路压测组成

单链路指一个业务线。

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

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

全链路压测解决什么问题?

什么时机下需要?

业务发展速度
在可以预期的一段时间（最好是半年，一个季度有点晚）内，业务会有较快速的发展，线上机器必须要大幅度扩容
扩容有的时候并不是线性的，从两台扩展到四台，你得服务能力或者能提高两倍
继续扩容服务能力就有可能提高不上去了，因为要受限于其他的模块，比如 DB、公共组建、中间件等

链路的复杂程度在扩张
一般而言，随着业务的发展，我们的接口会越来越多，系统会逐渐的做分布式
业务线内部的模块越抽象越多，业务线跟其他业务线的交互也越来越多
我们无法单纯的根据自己系统的处理能力来评估接口的服务能力

对单机压测结果越来越没有自信
- 一个很好的指标，一般而言，我们都会压一下我们自己的模块
- 单机的压测不代表真实的线上场景，内心会越来越虚，这个时候，就要考虑全链路了

如何展开全链路压测?

压力测试方式的几个阶段

梳理核心链路和边界

核心链路是一个业务的核心，这一块应该可以很快梳理清楚
难点在于梳理清楚链路的边界
千万不要污染正常数据：认真梳理数据处理的每一个环节，确保 mock 数据的处理结果不会写入到正常库里面
在核心链路的基础上，我们会有很多的分支业务，而这些分支业务有的可以参与压测，有的不能参与压测
- 比如给用户下放 push 消息
- 短信 / 支付 / 微信 Oauth 授权

数据模型构建

数据的真实性和可用性：可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量
数据脱敏：基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏
数据隔离：千万不要污染正常数据：认真梳理数据处理的每一个环节，可以考虑通过压测数据隔离处理，落入影子库，mock 对象等手段，来防止数据污染

流量平台搭建

jmeter、Ngrinder、locust，提供分布式压测的方式(饿了么的流量平台是基于 jmeter 改造的)、压测机中的机器数据能够实时的收集查看到、可以随时停止压测、一定时间内实时错误率达到阈值自动熔断。考虑到压测量较大的情况下回传测试结果会对 agent 本身造成一定资源占用，可以考虑异步上传，甚至事务补偿机制。
业务代码改造：压测请求上会打上特殊的标记，这个标记会随着请求的依赖调用一直传递下去。写请求写到影子区域(比如header头中做标记，存储、缓存、消息、日志等一系列的状态数据)、依赖的外部服务做 mock 处理(短信、邮件、push 等等)

真实流量蓄水池，分批释放
逐步压测

全链路压测核心功能

数据构造

压测隔离

添加压测标识，各服务和中间件依据标识来进行压测服务的分组和影子表方案的实施。
在请求头添加特殊标识，但需要保证线程间和跨服务间透传。
链路诊断功能方便定位问题。

服务隔离

通常选择深夜低峰压测，同时隔离正常流量和测试流量。隔离策略：基于IP，机器数，百分比

数据隔离

影子表（阿里）：使用线上同一个数据库，包括共享数据库中的内存资源，只在写入数据时写进另一个影子表。 KV的处理类似，MQ则选择生产端或消费端忽略消息。

调度中心

资源计算预估

压测期望到达的QPS
压测请求的平均响应时间和请求/响应体大小
压测的词表大小、分片数
压测类型

事件注入机制

根据系统的实际情况对压力进行相应调整。

调整QPS
触发熔断
开启事故注入
开启代码级性能分析

熔断保护机制

客户端熔断：根据业务自定义的熔断阈值，实时分析监控数据，当达到熔断阈值时，任务调度器会向压测引擎发送降低QPS或者直接中断压测的指令，防止系统被压挂。

容量规划

为什么需要容量规划

容量规划的目的在于让每一个业务系统能够清晰地知道：什么时候该加机器、什么时候应该减机器？双11等大促场景需要准备多少机器，既能保障系统稳定性、又能节约成本

容量规划四步走

业务流量预估阶段：通过历史数据分析未来某一个时间点业务的访问量会有多大
系统容量评估阶段：初步计算每一个系统需要分配多少机器
容量的精调阶段：通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整
流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务流量控制阶段：对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务

获取单台机器的服务能力

为了精准地获取到单台机器的服务能力，压力测试都是直接在生产环境进行，这有两个非常重要的原因：单机压测既需要保证环境的真实性，又要保证流量的真实性

生产环境进行单台机器压力测试的 4 个方法

模拟请求：通过对生产环境的一台机器发起模拟请求调用来达到压力测试的目的

复制请求：通过将一台机器的请求复制多份发送到指定的压测机器

请求转发：将分布式环境中多台机器的请求转发到一台机器

调整负载均衡：修改负载均衡设备的权重，让压测的机器分配更多的请求

单机压测问题

系统可用性问题

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

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

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

单系统压测的问题

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

流程举例

业务中需要区分流量(正常流量/压测流量)
- 压测时需要在 http header 里加入 X-Shadow 的key ,值为 true 的代表压测,key 不存在或者 key 值不等于 true 代表非压测流量
接收和发送 http / grpc 等请求时
- 在向下游服务发起请求时，如果是压测流量把 header 头中的标记字段往下透传，下游继续在业务中往下透传
- 接收到如果是压测流量，使用相应的压测数据
依赖的模块
- MySQL 使用影子表，将压测流量对 MySQL 的读写打到影子表上。即正常的业务表名为A,则影子表名为Ashadow
  - 所有涉及到的业务表都需要建一份影子表
  - 便于事后数据的清理
- MongoDB 使用影子 collection ，将压测流量对 MongoDB 的读写打到影子表上。即正常的业务表名为A,则影子表名为 Ashadow
  - 同 MySQL
- Redis 使用影子 key ，将压测流量对 redis 的读写打到影子 key 上。如 set key value 会变成 set key_shadow value
  - 同 MySQL
- kafka 使用影子 topic，key 后拼接 _shadow
  - 同 MySQL
不需要参与压测的做 mock 处理
- 给用户发push、短信、支付、微信 Oauth 授权

全链路压测应用

1 阿里分享

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

系统稳定性保障核武器——全链路压测
双11核武器——全链路压测详解

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 无日志服务