有赞全链路压测实战

有赞全链路压测实战

1、前言

有赞致力于成为商家服务领域里最被信任的引领者，由于被信任，全部咱们更须要为商家保驾护航，保障系统的稳定性。有赞从去年开始经过全链路压测，模拟大促真实流量，串联线上所有系统，让核心系统同时达到流量峰值：

• 验证大促峰值流量下系统稳定性
• 容量规划
• 进行强弱依赖的划分
• 降级、报警、容灾、限流等演练
• …
  经过全链路压测这一手段，对线上系统进行最真实的大促演练，获取系统在大压力时的表现状况，进而准确评估线上整个系统集群的性能和容量水平，不辜负百万商家的信任。

有赞对于性能测试主要有线下单系统单接口、线上单系统以及线上全链路压测等手段，经过不一样维度和颗粒度对接口、系统、集群层面进行性能测试，最终保障系统的稳定性。这里主要讲述一下，有赞全链路压测的相关设计和具体的实施。

2、总体设计

说到全链路压测，业内的淘宝、京东都都已有很成熟的技术，主要就是压测流量的制造、压测数据的构造、压测流量的识别以及压测数据流向的处理；直接看下有赞压测的总体设计：

• 大流量下发器：其实就是模拟海量的用户去使用咱们的系统，提供压测的流量，产生大促时的场景和流量；
• 数据工厂：构造压测链路中用户请求的数据，以及压测铺底的数据、数据清洗、脱敏等工做；
  压测平台负责管理压测脚本和压测请求数据，从数据工厂获取压测数据集，分发到每个压测 agent 机器上，agent 根据压测脚本和压力目标对线上机器发起请求流量，模拟用户的查看商品-添加购物车-下单-支付等行为，线上服务集群识别出压测的流量，对于存储的读写走影子存储。这里就要说到，线上压测很重要的一点就是不能污染线上的数据，不能让买卖家有感知，好比压测后，卖家发现多了好多订单，买家发现钱少了。因此，线上服务须要可以隔离出压测的流量，存储也须要识别出压测的数据，下面看一下有赞的压测流量和压测数据存储的隔离方案。

3、流量识别

要想压测的流量和数据不影响线上真实的生产数据，就须要线上的集群能识别出压测的流量，只要能识别出压测请求的流量，那么流量触发的读写操做就很好统一去作隔离了，先看一下有赞压测流量的识别：

3.1 同步请求

• 全链路压测发起的都是Http的请求，只须要要请求头上添加统一的压测请求头，具体表现形式为: Header Name:X-Service-Chain;
  Header Value:{“zan_test”: true}

• Dubbo协议的服务调用，经过隐式参数在服务消费方和提供方进行参数的隐式传递，表现形式为：
  Attachments:X-Service-Chain;
  Attachments Value:{“zan_test”: true}

• 经过在请求协议中添加压测请求的标识，在不一样服务的相互调用时，一路透传下去，这样每个服务都能识别出压测的请求流量，这样作的好处是与业务彻底的解耦，只须要应用框架进行感知，对业务方代码无侵入

3.2 中间件

NSQ:经过 NSQMessage 中添加 jsonExtHeader 的 KV 拓展信息，让消息能够从 Producer 透传到 Consumer 端，具体表现形式为：Key:zan_test;Value:true
Wagon:对来自影子库的 binlog 经过拓展消息命令(PUBEXT)带上压测标记{“zantest”: true}

3.3 异步线程

异步调用标识透传问题，能够自行定制 Runnable 或者定制线程池再或者业务方自行定制实现。

4、数据隔离

经过流量识别的改造，各个服务都已经可以识别出压测的请求流量了，那么如何作到压测数据不污染线上数据，对于不一样的存储作到压测数据和真实的隔离呢，有赞主要有客户端 Client 和 Proxy 访问代理的方式实现，下面就看一下有赞的数据隔离方案：

4.1 Proxy 访问代理隔离

针对业务方和数据存储服务间已有Proxy代理的状况，能够直接升级 Proxy 层，存储使用方彻底无感知，无侵入，下面以 MySQL 为例，说明 Proxy 访问代理对于压测数据隔离的方案；

业务方应用读写DB时，统一与 RDS-Proxy (介于 MySQL 服务器与 MySQLClient 之间的中间件)交互，调用 RDS-Proxy 时会透传压测的标记，RDS 识别出压测请求后，读写 DB 表时，自动替换成对应的影子表，达到压测数据和真实的生产数据隔离的目的

ElasticSearch、KV 对于压测的支持也是经过 Proxy 访问代理的方式实现的

4.2 客户端SDK隔离

业务应用经过Client调用存储服务时，Client 会识别出压测的流量，将须要读写的 Table 自动替换为影子表，这样就能够达到影子流量，读写到影子存储的目的；

Hbase、Redis 等采用此方案实现

4.3 数据偏移隔离

推进框架、中间件升级、业务方改造，不免会有遗漏之处，因此有赞对于压测的数据统一作了偏移，确保买卖家 ID 与线上已有数据隔离开，这样即便压测数据因为某种缘由写入了真实的生产库，也不会影响到线上买卖家相关的数据，让用户无感知；

这里要说一下特殊的周期扫表应用的改造，周期性扫表应用因为没有外部触发，全部没法扫描影子表的数据，如何让这样的 job 集群总体来看既扫描生产库，也扫描影子库呢？ 有赞的解决思路是，部署一些新的 job 实例，它们只扫描影子库，消息处理逻辑不变；老的 job 实例保持不变（只扫生产库）

5、压测平台

有赞的全链路压测平台目前主要负责压测脚本管理、压测数据集管理、压测 job 管理和调度等，后续会有重点介绍，这里不作深刻

压测的“硬件”设施基本已经齐全，下面介绍一下有赞全链路压测的具体实施流程吧

6、压测实施流程

废话很少说，直接上图：

有赞全链路压测的执行流程如上图所示，下面具体看一下几个核心步骤在有赞是怎么作的。

6.1 压测计划制定

要想模拟大促时线上真实的流量状况，首先须要确认的就是压测场景、链路，压测的目录，以及压测的流量漏斗模型：

• 压测的链路：根据公司具体业务具体分析，有赞属于电商类型公司，大促时候的峰值流量基本都是因为买家的购买行为致使的，从宏观上看，这样的购买行为主要是店铺首页-商品详情页-下单-支付-支付成功，咱们把这一条骨干的链路称为核心链路，其实大促时主要就是保证核心链路的稳定性

• 压测链路的漏斗模型：线上真实的场景案例是，100我的进入了商家的店铺首页，可能有50我的直接退出了，有50我的最终点击进入了商品详情页面，最终只有10我的下了单，5我的真正付款了，这就是压测链路的漏斗模型，也就是不一样的接口的真实调用比例；实际的模型制定会根据近7天线上真实用户的行为数据分型分析建模，以及往期同类型活动线上的流量分布状况，构建压测链路的漏斗模型

• 压测的场景：根据运营报备的商家大促活动的计划，制定大促的压测场景（好比秒杀、抽奖等），再结合近七天线上流量的场景状况，综合肯定压测的场景；
  

• 压测目标：根据运营报备的商家大促预估的PV和转换率状况，结合去年同期线上流量状况和公司业务的增加速率，取大值做为压测的目标

6.2 数据工厂

前面咱们已经介绍了如何肯定压测的目标、场景、链路，那么压测的数据怎么来尼，这就是数据工厂登场的时候了，下面就介绍一下有赞压测的数据工厂

有赞的压测数据工厂主要负责，压测铺底数据的准备、压测请求数据块的生成；

6.3 铺底数据准备

压测准备铺底的数据，这个众所周知的，可是因为有赞压测的方案采用的是影子库的设计，因此对于铺底数据准备不得不去处理影子库的数据。直接看下铺底数据准备的流程图：

数据导入 从生产数据库按需过滤，导入压测铺底须要的数据到大数据集群的hive表中。

• 数据处理 在 hive 表中，对导入的数据进行脱敏和清洗，清洗的目的是保证压测的数据可用性，好比保证铺底商品库存最大、营销活动时间无限、店铺正常营业等。 - 数据导出 对 hive 标中已经处理完成的数据，导出到已经建立好的影子库中，须要注意的是同一实例写入数据的控制（由于影子库和生产库同实例），写入数据的 binlog 过滤。
  有赞的压测数据准备目前所有在 DP 大数据平台上操做，基本完成了数据准备操做的自动化，维护了近千的数据准备 job

压测请求数据数据集
gatling 原生支持 json、csv、DB 等方式的数据源载入，咱们采用的压测数据源是 json 格式的，那么如此海量的压测源数据，是经过什么方式生成和存储的尼，咱们的实现仍是依托于 DP 大数据平台，经过 MapReduce 任务的方式，按需生成咱们压测请求须要的数据集：

• 从各个业务线的表中获取压测场景整个链路因此接口请求须要的参数字段，存到一张建立好的压测数据源宽表中
• 编写 MapReduce 任务代码，读取压测数据源宽表数据，按压测的接口请求参数状况，生成目标 json 格式的压测请求数据块文件到 HDFS
• 压测时，压测引擎自动从 HDFS 上拉取压测的请求数据块
  MapReduce 生成的数据集 json 示例：

6.4 压测脚本准备

6.4.1 梳理压测请求和参数

压测就要知道压测的具体接口和接口参数，因此咱们采用统一的 RESTful 风格规范，让各个业务方的人员提交压测接口的 API 文档，这样压测脚本编写人员就能根据这份 API 快速写出压测的脚本，以及接口的预期结果等

6.4.2 控制漏斗转化率

有赞的压测引擎用的是公司二次封装的 gatling，原生就支持漏斗比例的控制，直接看例子

6.4.3 不一样场景的配比

对不一样的压测场景链路按模块编写压测脚本，这样的好处就是须要不一样场景混合压测时，只须要在 setUp 时，按需把不一样的场景组合到一块儿便可；须要单独压测某一个场景时，setUp 中只留一个场景就好，作到一次编写，到处可压。

6.5 压测执行

压测的铺底数据、压测脚本、压测请求的数据集都已经介绍完了，可谓是万事俱备只欠东风，那这个东风就是咱们自建的压测平台 maxim，这里不对压测平台的设计展开介绍，展现一下 maxim 在压测执行过程当中所承担的工做。

maxim平台主要的功能模块有：

• 测试脚本：负责测试脚本的管理

• 数据集：负责压测请求数据集的管理，目前主要有两种数据集上传模式：直接上传数据包和 hadoop 集群数据源路径上传。第二种上传模式，只须要填写数据源所在的 hadoop 集群的路径，maxim 平台会自动去所在路径获取压测数据集文件

• 测试 job：负责测试任务的管理，指定压测 job 的脚本和脚本入口，以及压测数据集等

• 压测注入器：负责展现压测注入机器的相关信息

• 压测报告生成：压测报告的生成，直接用的 gatling 原生的报告生成功能

maxim 平台压测结果报告

下面看一下压测执行的页面功能：

• 压力注入器数量：指定本次压测执行，须要多少台压测机去执行
• 重复场景测试：一个虚拟用户重复几回压测场景
• 并发用户数：可执行压测时，按需填写须要的每秒加载的并发用户数和持续时间，无需每次变动压测脚本
• 目标 RPS：可执行压测时，按需填写压测的目标 RPS，爬坡时间，目标持续时间，达到限流的做用，可同时指定多个目标 RPS，达到分梯度压测的目的；

7、最后

到这里有赞全链路压测方案已经介绍完了，由于篇幅的缘由还有不少实施细节部分并无完整表述，同时有赞的全链路压测也才初具雏形，欢迎有兴趣的同窗联系咱们一块儿探讨，有表述错误的地方也欢迎你们联系咱们纠正。

 

 版权声明：本文为CSDN博主「花露丝雨」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。
原文连接：https://blog.csdn.net/hualusiyu/article/details/85112931#comments