引流回放这个技术现在真的越来越成为了很多公司测试同学必备的一个工具了。当然引流回放的技术有很多，比如下来会提到的jvm-sandbox-repeater。 当然你也可以通过日志分析解析的方式去获取到请求返回的信息等。因为刚听过testerhome开发者大会，好几个主题也讨论到了引流回放，而现在大热的引流回放就是 https://github.com/alibaba/jvm-sandbox-repeater

引流回放面向的目标人群 - 面向测试开发工程师

• 线上有个用户请求一直不成功，我想在测试环境Debug一下，能帮我复现一下吗？
• 压测流量不知道怎么构造，数据结构太复杂，压测模型也难以评估，有什么好的办法吗？
• 不想写接口测试脚本了，我想做一个流量录制系统，把线上用户场景做业务回归，可能会接入很多服务系统，不想让每个系统都进行改造，有好的框架选择吗？
• 我想做一个业务监控系统，对线上核心接口采样之后做一些业务校验，实时监控业务正确性。

我们就按照官网的操作步骤来吧。不过有些地方我们得适当修改下，不确定这些是否适合其他同学哈。

1. 安装sandbox以及repeater

curl -s https://github.com/alibaba/jvm-sandbox-repeater/releases/download/v1.0.0/install-repeater.sh | sh

注： 这种方式安装的的repeater 没有办法被sandbox 识别出来，导致repeater的插件一直没办法被加载

所以推荐是直接通过拉取repeater的源码

git clone https://github.com/alibaba/jvm-sandbox-repeater.git

cd jvm-sandbox-repeater/bin

sh install-local.sh

install-local.sh

#!/usr/bin/env bash

# repeater's target dir
REPEATER_TARGET_DIR=../target/repeater

# exit shell with err_code
# $1 : err_code
# $2 : err_msg
exit_on_err()
{
    [[ ! -z "${2}" ]] && echo "${2}" 1>&2
    exit ${1}
}

# package
sh ./package.sh || exit_on_err 1 "install failed cause package failed"

# extract sandbox to ${HOME}
curl -s https://ghproxy.com/https://github.com/alibaba/jvm-sandbox-repeater/releases/download/v1.0.0/sandbox-1.3.3-bin.tar | tar x -C ${HOME} || exit_on_err 1 "extract sandbox failed"

# copy module to ~/.sandbox-module
mkdir -p ${HOME}/.sandbox-module || exit_on_err 1 "permission denied, can not mkdir ~/.sandbox-module"
cp -r ${REPEATER_TARGET_DIR}/* ${HOME}/.sandbox-module  || exit_on_err 1 "permission denied, can not copy module to ~/.sandbox-module"

install-local.sh的脚本如上，其他它与上述的sh脚本的区别在于 repeater它是直接通过源码打包的，其他都是一样的，所以只能有理由怀疑的是repeater的问题。导致了插件没有办法被加载。具体可以看下，我通过官方的脚本安装以及通过源码安装后执行sandbox.sh的日志差异

这个是根据官方的方式安装的，加载完module-jar以后就直接进行端口绑定了。

通过源码打包的方式，就会出现加载module-lib的逻辑，所以这个就是具体的差异的地方，这个问题会直接repeater完全没有启动。这个原因下来再说为啥会有这个情况

先解释下上边的脚本，脚本的主要作用就是安装sandbox以及repeater， 而安装的路径分别是在 ~/sandbox 与 ~/.sandbox-module 。

2. 修改repeater的配置

这里我们先采用standalone的模式，所以我们需要修改~/.sandbox-module/cfg/repeater.properties的配置信息

改为true. 至于其上面的那些配置想都是配合repeater-console一起使用的，所以我们暂时可以先不用管

同时再修改repeater-config.json, 它默认是在~/.sandbox-module/cfg/repeater-config.json

具体配置含义参见：RepeaterConfig.java

这里我们将配置修改为如下：

{
  "degrade": false, 
  "exceptionThreshold": 1000,
  "httpEntrancePatterns": [
    "^/greeting.*$"， // 这里主要是录制接口为greeting的
  ],
  "javaEntranceBehaviors": [
  ],
  "javaSubInvokeBehaviors": [
  ],
  "pluginIdentities": [
    "http",
    "mybatis",
    "ibatis",
    "dubbo-provider",
    "dubbo-consumer"
  ],
  "repeatIdentities": [
    "java",
    "http"
  ],
  "sampleRate": 10000,
  "useTtl": true
}

启动被测服务

克隆源码

git clone https://github.com/chenhengjie123/gs-rest-service.git

这个项目是在看其他帖子看到的，是个开源的demo，我在这也引用下。

进入到项目路径：/gs-rest-service/complete，使用**mvn install**命令，把项目中打好的包，放到本地仓库

在 target 目录下，可以看到，生成了一个jar包，如下所示

在 target 目录下，使用命令 java -jar gs-rest-service-0.1.0.jar 启动项目，出现如下所示内容，项目启动成功

记录下这个pid，下来会用到

获取到项目PID后，到 sandbox 目录 ~/sandbox/bin下，使用命令./sandbox.sh -p 53972 -P 12580，运行命令后，出现如下内容，说明成功

也可以通过查看sandbox日志来确定，是否有启动成功，日志如下所示：

参数说明

• p 被录制应用进程号
• P repeater启动端口，这个每个人定义的都可以不同，一定是一个未占用的端口

attach 模式下，录制应用名和录制环境这两个参数都会被默认为 unknown。这个应用名与录制环境在standalone作用不大，如果是在repeater-console上就比较重要，用来区分不用应用的流量以及配置使用。

attach关闭

运行命令**./sandbox.sh -p 53972 -S**，出现如下内容，jvm-sandbox关闭成功

jvm-sandbox[default] shutdown finished.

模拟请求

此时我们可以看下repeater的日志，如下：

repeater的日志默认也是在sandbox相同的路径下 ~/logs/sandbox/repeater

同时在~/.sandbox-module/ 目录下也会多出一个 repeater-data 里面也记录下这此录制的内容，只是通过了序列化保存了。

问题

前面说到的 repeater的问题下来会单独来说明这个问题

另外一个就是github的下载经常容易失败，建议大家可以参考上边的链接，做一个加速，在github的链接上增加一个 https://ghproxy.com/ 即可。