1、简介
Goreplay 是用 Golang 写的一个HTTP 实时流量复制工具。功能更强大，支持流量的放大、缩小，频率限制，还支持把请求记录到文件，方便回放和分析，也支持和 ElasticSearch 集成，将流量存入 ES 进行实时分析。
GoReplay 不是代理，而是监听网络接口上的流量，不需要更改生产基础架构，而是在与服务相同的计算机上运行 GoReplay 守护程序。
特点：简单易用，与TCPCopy 相比它的架构更简单，只有一个 gor 组件，如下：
只需要在生产服务器上启动一个gor 进程，它负责所有的工作包括监听、过滤和转发。它的设计遵循 Unix 设计哲学：一切都是由管道组成的，各种输入将数据复用为输出。
安装方式
安装go语言环境
Go语言包下载地址：https://studygolang.com/dl
解压安装：
tar -C /usr/local -zxvf go1.14.4.linux-amd64.tar.gz
配置环境变量：
# 打开vim /etc/profile # 添加export GOROOT=/usr/local/goexport PATH=$PATH:$GOROOT/bin # 编译生效source /etc/profile验证go版本：
[root@vm ~]# go versiongo version go1.15.5 linux/amd64
安装goreplay
下载二进制包：https://github.com/buger/gor/releases
下载1.3.3版本，解压后即为可执行文件。2.0的包是源码，安装时需要下载一些包，内网无法安装。
使用方式
监听本地服务端口 8082 流量保存到本地的文件
sudo ./gor --input-raw :8082 --output-file=requests.gor
将流量从文件回放到其他服务
./gor --input-file requests_0.gor --output-http="http://172.16.106.237:8082"
将 http 的请求打印到终端：
sudo ./gor --input-raw :8082 --output-stdout
将 http 的请求实时转发到其他服务
sudo ./gor --input-raw :8082 --output-http="http://172.16.106.237:8082"
压力测试：
将流量放大或减少转发给其他服务端口：
./gor --input-file "requests.gor|200%" --output-http="http://172.16.106.237:8082"
./gor --input-file "requests.gor|20%" --output-http="http://172.16.106.237:8082"4、其他功能
过滤指定请求
gor --input-raw :80 --http-allow-method GET --output-http http://target_server:8080
gor --input-raw :8080 --output-http staging.com --http-allow-url /api
只收集请求头中符合 api-version 为 1.0x 的请求
gor --input-raw :8080 --output-http staging.com --http-allow-headerapi-version:^1\.0\d
对指定的header或url请求进行限流或者加速
gor --input-tcp :28020 --output-http"http://staging.com|10"# (每秒请求数限制10个以内)
gor --input-raw :80 --output-tcp"replay.local:28020|10%" # (每秒请求数限制10%以内)
gor --input-raw :80 --output-tcp"replay.local:28020|10%" --http-header-limiter "X-API-KEY:10%"
gor --input-raw :80 --output-tcp"replay.local:28020|10%" --http-param-limiter "api_key:10%"
将流量转发到多个站点
gor --input-raw :80 --output-http "http://target_server:8080"--output-http http://target_server2:8080
将相同的流量发送到多个站点，并且平分所有流量。
gor --input-raw :80 --output-http "http://staging.com" --output-http "http://dev.com"--split-output true
5、更多参考
https://www.cnblogs.com/Chary/p/16829396.html
http://www.manongjc.com/detail/60-lechphnhdwofesc.html
https://www.cnblogs.com/junethirty/p/13304774.html
6、使用思考
1、流量录制回放与传统接口自动化测试的区别？
流量录制回放提供了一种新的接口自动化测试方法。与传统接口自动化测试相比，流量回放最大的优势是降低了测试数据和用例编写的成本。利用流量即用例的思想，我们可以直接将线上流量转化成接口测试用例，从而避免了繁琐的测试数据准备和脚本编写工作。
同时，线上流量覆盖更全面、数据更真实，使用线上流量作为测试数据，与人工构造测试数据相比，能够更真实、更全面地覆盖业务场景，提升用例发现问题的能力。
但是由于录制流量的独立性，流量回放主要用于单接口测试。对于需要多个接口组合才能覆盖的测试场景，流量回放无法支持，需要采用传统的接口自动化测试方法。
2、流量筛选：流量录制回放提供了一种非常低成本的用例生成方法。然而，我们需要的不是一个随机的用例，而是能够增加测试覆盖的用例。如何从线上流量中去粗取精，挑选能够增加测试覆盖的流量进行回放，是流量筛选需要解决的关键问题。
3、很多时候需借助Mock
在流量回放中，由于读接口没有副作用，因此可以直接回放。对于写接口回放，则必须通过Mock方式对中间件进行隔离、避免脏数据产生。由于在录制流量的时候，我们可以同时录制所有子调用，进而利用录制的子调用自动生成Mock，因此是可以一定程度上降低Mock成本的。
Mock回放与非Mock回放的根本区别在于：Mock回放是白盒测试，而非Mock回放是黑盒测试。在非Mock回放中，用例只依赖接口的输入输出定义，不依赖接口内部代码实现；在Mock回放中，用例不仅依赖接口的输入输出定义，还依赖接口的内部实现，即接口对中间件、第三方等的调用详情。
对于Mock回放来说，其白盒测试固有性质除了会带来测试覆盖度降低(中间件变更无法被用例覆盖，存在漏测风险)之外，其最大挑战在于回放失败率上升及回放失败的排查成本高。
用例失败概率上升：非Mock回放，接口的输出不符合预期，用例就会失败；而Mock回放中，任何一个Mock子调用失败，都会导致用例失败。尤其当子调用数量多、链路易变的情况下，Mock回放用例失败概率会很高。
4、注意测试环境的影响。流量回放本质上是对比测试，而对比的数据是依赖于测试环境的。我们对比的数据应该来自同一套数据源或使用Mock，否则是没有办法进行对比的(因为没有可比性)。
5、最好确保被测环境与生产环境进行录制前状态一样，否则回放会因数据问题导致部分请求会失败。
