文章导读

服务压力测试，是评估一个服务是否优秀的过程，他不仅能让你找到你的服务哪些地方存在性能瓶颈，而且还能让你准确的去做容量评估，防止容量不足，也规避了资源浪费。
本文会带你了解以下几点内容：

• 压测的意义
• 压测注意点
• 压测准备
• 模型压测的自我理解
• 普通压测工具
• goreplay压测工具介绍

为什么要压测

• 业务推广保障
• 准确评估容量
• 快速发现服务瓶颈
• 极限压力测试
• 服务迁移全链路测试

  压测需要注意哪些点(重点阅读)

• 环境统一(基础环境、参数配置、资源型号、请求链路)
• 压测机不能存在瓶颈
• 压测姿势一致
• 多次压测
• 注意写流量(如果你不想产生脏数据)
• 注意三方依赖服务(你压测A服务，要考虑是否会顺带压测到B服务)
• 极限压测过程中注意拐点(某些时候你qps上不去，响应时间大幅度上涨，那就说明是拐点了)

  环境统一

  这个目前我们有两种方式，第一种是新建测试环境压测，第二种是直接在生产环境压测。
  如果新建，那么我们需要考虑的点就是跟生产环境完全一致。
• 基础环境，包括系统版本，系统参数配置
• 软件环境，比如 Php 版本，Php 参数配置
• 资源型号，机器的型号配置，Redis 的规格，MySql 的规格等
• 请求链路，比如我请求的链路是经过两层 Nginx，不能在压测的时候只经过一层 Nginx。

  压测机器不能存在瓶颈

  我们之前在压测过程中，会发现当压测到一定量级后就上不去了，这时候我们一直在排查服务端是否有什么问题，包括部署资源是否足够，后端资源是否性能瓶颈，带宽是否打满等信息，绕了一圈都没有发现问题。
  最终我们发现是压测端机器性能较低，带宽打满了，最终换用了更高配的机器来进行压测。所以我们压测端一定不能成为压测计划的瓶颈。

  压测姿势一致

  简单举个例子，用ab压测的时候，需要指定线程，压测时间等参数，假如第一次用10个线程，压测10分钟，第二次用12个线程，压测20分钟

那么这样得到的数据是完全无用的。

多次压测

性能压测的数据是多次得来的，结论也是多次数据对比得出的。
由于每次压测都会有无法预知的问题，所以每次压测结束后，都需要分析结果，看看是否符合预期，比如在第二次压测，某截网络断了，那么得到的数据可能会非常差，那么这次的压测数据就不能使用。

注意写流量

这个也是跟我们的压测场景有关。

• 当我们在生产压测，那么我们肯定不能有写流量的压测，那么我们的生产数据就会脏掉，除非这些数据能够把控，在压测后能完全删除，不然是只能压测读流量。
• 当我们在测试环境压测，这种情况可以压测全链路，不过有一个点需要关注下，当我们是服务迁移的压测，这时候生产环境跟测试环境是数据实时同步的，测试环境的脏数据也会回写到生产环境。

  注意三方依赖服务

  再举个例子，我美颜相机服务要准备压测，依赖登录、素材展示两个服务。

那么我们在压测的时候一定要去周知登录和素材的开发同学，以及让他们做好扩容准备和实时监控，实时反馈目前的一个服务状态，当有异常的时候，应立即停止压测。

极限压测过程中注意拐点

在我们压测过程中，是需要记录每次压测的结果的，比如压测结果的qps、相应时间、服务SLA等信息。当某些值在一定持续增长的压力下增长缓慢、不增长甚至降低，那么这时候你就要考虑压测是否到达了一定的拐点，类似可以做一个如下的图来简单判断拐点：

压测前准备

• 明确整体系统链路情况
• 依赖资源的容量评估，确认压测的时候是否需要扩容
• 压测部分降级方案的确认

明确整体系统链路情况

业务压测前，首先需要明确业务架构，开发需要配合运维梳理整个系统结构，开发补充业务层面，运维补充系统层面，整理出一个流量走势以及三方依赖图。明确是否跨机房、是否跨专线、是否存在网络隔离等问题。

依赖资源的容量评估

例子，A业务压测，三方依赖服务有B和C，首先要记录当前生产业务的qps，B和C业务的使用量级。假如是1000qps，B用量10台机器，C用量20台机器。那么我们压测需要压到2000qps，理论上B用20台机器，C用40台机器。

压测部分降级方案的确认

做压测工作，我们需要明确几点：

• 我们是为了保障线上业务稳定才做的压测，所有的评估都要有预留。
• 压测遇到的问题也正是我们上生产或者迁移后遇到的问题，所以每一个问题都需要正视。

所以针对上面两点，我们需要明确业务容量评估一定要留cache，降级方案、回退方案一定要有，防止真的出现问题。
下面是我们在压测过程中遇到的问题以及处理的过程：

模型压测(自我理解)

这是我在压测过程中，总结的一个点，这个我可能没法用很好的词语来描述，我就用一个简单的例子来描述吧。

业务场景：简单的 Nginx + PHP 业务，容器化部署。

那么我们可以配置以下几个压测模型场景来进行压测，然后给出相应的结论：

1. 单 Pod CPU 内存压测
2. 单 Pod Nginx + PHP 空接口压测
3. 单 Pod Nginx + PHP 业务单接口压测

• 关于单 Pod CPU 内存压测，我们可以在业务部署机器上启动一个空 Pod，然后进行压测，不涉及任何业务，这里得到的结论 — 排除底层平台带来的影响。
• 单 Pod Nginx + PHP 空接口压测，这里你可以随便写一个php接口，return 一个 OK 就行，然后进行压测，这里得到的结论 — 排除业务基础环境带来的影响比如 Nginx + PHP 等。
• 单 Pod Nginx + PHP 业务单接口压测，这里找一个具有代表性的接口，什么是具有代表性的接口，比如这个接口是涉及到读 Redis 或者 MySql 等后端资源的。这里得到的结论 — 业务层面的一个压测结果。

经过这一轮压测之后，你能非常明确你的压测结论是否存在异议，一步步排除环境因素。

普通压测工具介绍

目前来说，我在运维过程中使用的压测工具也就是ab，wrk等，其实针对不同的场景，每一个工具都有自己的优点和缺点。

ab

• 支持多平台
• 默认短链接
• 只能单进程
• 无法控制压测时间，控制速率

wrk

• 类unix
• 支持多线程(更容易发挥多核的能力)
• 支持自定义脚本
• 默认长链接

goreploay介绍

优点

• 可用于服务迁移前的全链路测试
• 支持http请求录制和重放，可以复制线上请求，在压测环境重放
• 支持http层的流量过滤，比如我只复制某一个接口的请求
• 支持请求放大，用于性能压测
• ……

  文档地址

  官方git地址：https://github.com/buger/goreplay
  官方文档：https://github.com/buger/goreplay/wiki
  

流量捕获

• input-raw 捕获 HTTP 流量，需指定端口号
• input-file 使用 –output-file 记录的文件作为输入
• input-tcp 将多个 Gor 实例获取的流量聚集到一个 Gor 实例

流量重放

• output-http 将流量重放到URL地址
• output-file 将获取的流量记录如文件
• output-tcp 将获取的流量转移至另外的 Gor 实例，与input-tcp组合使用
• output-stdout debug 工具，将流量信息直接输出

请求过滤

• http-allow-url 只发送正则匹配的url的请求
• http-disallow-url 不发送正则匹配url的请求
• http-allow-header 只发送指定head的请求
• http-disallow-header 不发送指定head的请求
• http-allow-method 允许的请求方法
• http-set-header 增加http-header

流量限制

• 随机丢弃一部分请求
  • 按照准确的qps限制
  • 按照比例限制(这里的比例，可以实现大于100%，即倍量的压测)
• 根据Header 或者 URL 参数限制一部分请求

实战演练

goreplay安装

依赖go环境
wget https://github.com/buger/goreplay/releases/download/v1.0.0/gor_1.0.0_x64.tar.gz
tar xvf gor_1.0.0_x64.tar.gz

抓取流量

在公司中，我们的流量入口一般是公共代理，比如nginx等。下面例子是我在公司其中一台公共代理上抓取的流量，有以下几个说明：(给的例子是我在使用过程中的，有特殊需求的可以参考官方文档进行相应的修改)

• 80端口
• allow header：lb6test.meitu.com，这就是我想要压测的服务域名
• method是get，因为post请求我们不压测，涉及到写数据
• allowurl是我只想要抓取这个域名中a和b这两个接口的流量
• disallow header，我要抓取token为空的，因为不为空的token涉及到登录，会连带压测我们登录的服务
• outputfile：把抓取的流量输出为一个流量包，这样好携带

./goreplay  --input-raw :80 --http-allow-header 'Host: lb6test.meitu.com' -http-allow-method 'GET' -http-allow-url '/a/a.json' -http-allow-url '/b/b.json' -http-disallow-header 'Access-Token:' -output-file meitu.gor

普通输出流量

这个操作一般我们会放到单独的压测机器上进行，如果你压测的是新部署的测试环境，注意这个域名一定要在这个机器上绑定一个host，防止你压测到生产环境去了。

• loop，循环压测，因为流量包抓取的时间是固定的，如果不循环压测，流量重放结束就会终止压测
• disallowurl，我突然不想压测b接口的流量，那么就关闭掉。
• outputhttp，从该压测机发起对测试环境的请求流量

  ./goreplay --input-file-loop --input-file "meitu.gor" --http-disallow-url "/b/b.json" --output-http "http://lb6test.meitu.com"
  

  压测输出流量

  当你按照普通输出流量走一遍的时候，并且不过滤任何接口，你就会知道你这个流量包到底有多少流量，是多少 qps，假如我的meitu.gor是100 qps。

  我想要50qps

  ./goreplay --input-file-loop --input-file "meitu.gor" --output-http "http://lb6test.meitu.com|50"
  

  我想要200qps

  这里一个操作是把流量放到1000%，那么你就可以认为这个qps是无限大的，你可以任意指定你想要的qps了。

  ./goreplay --input-file-loop --input-file "meitu.gor|1000%" --output-http "http://lb6test.meitu.com|200"
  

  一次压测太慢，我要快速压测

  如果你觉得一个进程太慢了，那么就多启动几个进程进行压测吧

  nohup ./goreplay --input-file-loop --input-file "meitu.gor" --output-http "http://lb6test.meitu.com" > /dev/null 2>&1
  

  输出文档

  我们压测好之后，应该输出哪些东西呢
• 基础压测的数据
• 极限压测的数据
• 不同压力下的数据
• qps，响应时间，成功率

下面是我当时压测公司某个服务记录的一些信息和描绘的图。