文章导读
服务压力测试，是评估一个服务是否优秀的过程，他不只能让你找到你的服务哪些地方存在性能瓶颈，并且还能让你准确的去作容量评估，防止容量不足，也规避了资源浪费。本文会带你了解如下几点内容：php
-
压测的意义 -
压测注意点 -
压测准备 -
模型压测的自我理解 -
普通压测工具 -
goreplay压测工具介绍
为何要压测
-
业务推广保障 -
准确评估容量 -
快速发现服务瓶颈 -
极限压力测试 -
服务迁移全链路测试
压测须要注意哪些点(重点阅读)
-
环境统一(基础环境、参数配置、资源型号、请求链路) -
压测机不能存在瓶颈 -
压测姿式一致 -
屡次压测 -
注意 写流量(若是你不想产生脏数据) -
注意三方依赖服务(你压测A服务，要考虑是否会顺带压测到B服务) -
极限压测过程当中注意拐点(某些时候你qps上不去，响应时间大幅度上涨，那就说明是拐点了)
环境统一
这个目前咱们有两种方式，第一种是新建测试环境压测，第二种是直接在生产环境压测。若是新建，那么咱们须要考虑的点就是跟生产环境彻底一致。nginx
-
基础环境，包括系统版本，系统参数配置 -
软件环境，好比 Php 版本，Php 参数配置 -
资源型号，机器的型号配置，Redis 的规格，MySql 的规格等 -
请求链路，好比我请求的链路是通过两层 Nginx，不能在压测的时候只通过一层 Nginx。
压测机器不能存在瓶颈
咱们以前在压测过程当中，会发现当压测到必定量级后就上不去了，这时候咱们一直在排查服务端是否有什么问题，包括部署资源是否足够，后端资源是否性能瓶颈，带宽是否打满等信息，绕了一圈都没有发现问题。最终咱们发现是压测端机器性能较低，带宽打满了，最终换用了更高配的机器来进行压测。因此咱们压测端必定不能成为压测计划的瓶颈。git
压测姿式一致
简单举个例子，用ab压测的时候，须要指定线程，压测时间等参数，假如第一次用10个线程，压测10分钟，第二次用12个线程，压测20分钟github
那么这样获得的数据是彻底无用的。web
屡次压测
性能压测的数据是屡次得来的，结论也是屡次数据对比得出的。因为每次压测都会有没法预知的问题，因此每次压测结束后，都须要分析结果，看看是否符合预期，好比在第二次压测，某截网络断了，那么获得的数据可能会很是差，那么此次的压测数据就不能使用。shell
注意写流量
这个也是跟咱们的压测场景有关。json
-
当咱们在生产压测，那么咱们确定不能有写流量的压测，那么咱们的生产数据就会脏掉，除非这些数据可以把控，在压测后能彻底删除，否则是只能压测读流量。 -
当咱们在测试环境压测，这种状况能够压测全链路，不过有一个点须要关注下，当咱们是服务迁移的压测，这时候生产环境跟测试环境是数据实时同步的，测试环境的脏数据也会回写到生产环境。
注意三方依赖服务
再举个例子，我美颜相机服务要准备压测，依赖登陆、素材展现两个服务。后端
那么咱们在压测的时候必定要去周知登陆和素材的开发同窗，以及让他们作好扩容准备和实时监控，实时反馈目前的一个服务状态，当有异常的时候，应当即中止压测。微信
极限压测过程当中注意拐点
在咱们压测过程当中，是须要记录每次压测的结果的，好比压测结果的qps、相应时间、服务SLA等信息。当某些值在必定持续增加的压力下增加缓慢、不增加甚至下降，那么这时候你就要考虑压测是否到达了必定的拐点，相似能够作一个以下的图来简单判断拐点：网络
压测前准备
-
明确总体系统链路状况 -
依赖资源的容量评估，确认压测的时候是否须要扩容 -
压测部分降级方案的确认
明确总体系统链路状况
业务压测前，首先须要明确业务架构，开发须要配合运维梳理整个系统结构，开发补充业务层面，运维补充系统层面，整理出一个流量走势以及三方依赖图。明确是否跨机房、是否跨专线、是否存在网络隔离等问题。
依赖资源的容量评估
例子，A业务压测，三方依赖服务有B和C，首先要记录当前生产业务的qps，B和C业务的使用量级。假如是1000qps，B用量10台机器，C用量20台机器。那么咱们压测须要压到2000qps，理论上B用20台机器，C用40台机器。
压测部分降级方案的确认
作压测工做，咱们须要明确几点：
-
咱们是为了保障线上业务稳定才作的压测，全部的评估都要有预留。 -
压测遇到的问题也正是咱们上生产或者迁移后遇到的问题，因此每个问题都须要正视。
因此针对上面两点，咱们须要明确业务容量评估必定要留cache，降级方案、回退方案必定要有，防止真的出现问题。下面是咱们在压测过程当中遇到的问题以及处理的过程：
模型压测(自我理解)
这是我在压测过程当中，总结的一个点，这个我可能无法用很好的词语来描述，我就用一个简单的例子来描述吧。
业务场景：简单的 Nginx + PHP 业务，容器化部署。
那么咱们能够配置如下几个压测模型场景来进行压测，而后给出相应的结论：
-
单 Pod CPU 内存压测 -
单 Pod Nginx + PHP 空接口压测 -
单 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.gztar 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，响应时间，成功率
下面是我当时压测公司某个服务记录的一些信息和描绘的图。
本文分享自微信公众号 - 程序猿的野生香蕉（gh_2e510bc5c532）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。