1.转转流量录制与回放的源码原理及实践
2.JVM-SANDBOX：从阿里精准测试走出的开源贡献奖
3.Jvm-Sandbox原理分析-Sandbox的启动-01
4.通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (二)——repeater-console 使用
5.Jvm sandbox mock机制实践

转转流量录制与回放的原理及实践

       随着转转业务规模和复杂度的提升，服务之间的分析依赖关系变得日益复杂，开发和测试过程中遇到的源码问题也日益增多。如何优雅地解决这些问题成为了一个关键点。分析优雅意味着在不增加业务成本、源码保持业务基本无感的分析防进程挂起模块 源码同时，尽可能减小对业务性能的源码影响。阿里开源的分析jvm-sandbox-repeater（简称Repeater）正是为解决这些挑战而设计的。本文将详细介绍Repeater是源码如何实现业务无感的流量录制和回放，以及其在实际应用中的分析实践与改造。

       首先，源码让我们聚焦于Repeater如何做到业务无感的分析流量录制。流量录制包括对一次入口调用（例如HTTP、源码Dubbo或Java调用）及其子调用的分析捕获和记录，形成完整的源码过程记录。以获取产品价格方法为例，流量录制包含入口调用的参数和返回值，以及远程子调用（如redis.get、daoRpc.getProductCount、redis.set、logicRpc.process）的入参和返回值。本地子调用则不被录制。通过转转流量回放平台展示的单个流量线上效果图，我们可以直观理解流量录制的概念。

       随后，组卷app源码流量回放的过程涉及获取录制流量的入口调用参数，再次发起调用，并根据参数匹配子调用，使用录制时记录的入参和返回值。如果回放后返回值与录制时返回值不一致，则标记回放失败。通过转转流量回放平台展示的流量回放线上效果图，我们可以进一步理解流量回放的概念。

       接下来，我们将深入探讨Repeater实现原理。Repeater利用JVM-Sandbox的BEFORE、RETURN和THROW事件机制进行录制流程控制，实现代码织入。通过字节码增强技术，JVM-Sandbox在目标方法上实现aop逻辑，实现流量录制和回放的自动化。下图展示了使用JVM-Sandbox增强前后的代码变化，帮助理解其原理。

       Repeater的核心逻辑录制基于JVM-Sandbox的事件机制，通过doBefore和doMock方法实现录制和回放的关键逻辑。这些方法在目标方法执行前后被触发，用于记录和模拟调用过程。为了减小录制对线上服务的性能影响，线上环境录制需要特别注意，源码布尔运算本文将介绍具体策略。

       最后，本文总结了Repeater流量录制和回放的实现原理以及在实际应用中的实践与改造点。通过介绍Repeater的使用方法、注意事项和改造点，旨在帮助读者深入了解并熟练运用这一工具，实现业务无感的流量录制和回放，提升开发和测试效率。

JVM-SANDBOX：从阿里精准测试走出的开源贡献奖

       阿里妹导语：在历年双的技术质量保障中，稳定性一直为核心。从年起，淘宝技术质量部研发了一套创新的实时无侵入字节码增强框架——JVM-SANDBOX，并在MTSC大会上荣获开源贡献奖。今天，让我们深入了解这个获奖项目。

       在最近的中国移动互联网测试开发大会上，JVM-SANDBOX与淘系同学维护的ATX共同荣获了MTSC 年度开源贡献奖，表彰他们在测试领域的突出贡献。JVM-SANDBOX旨在为服务端稳定性提供实时、非侵入的字节码增强框架，以提升系统的稳定性保障。

       自年起，团队面临如何高效、轻量级地实现稳定性专项的源码谷官网挑战，如功能回归和故障演练等。通过研发JVM-SANDBOX，他们解决了字节码增强技术的高门槛问题，降低了维护成本，并支持了多项功能的动态管理和快速实现。项目的关键在于实现java方法的环绕控制和运行时链路获取，即AOP解决方案，既要实时生效又需灵活。

       JVM-SANDBOX以纯Java实现，基于JVMTI技术，提供了实时无侵入的AOP框架和模块管理容器，支撑核心功能如BEFORE、RETURN和THROWS事件处理。项目架构包括HTTP-SERVER组件，通过HTTP协议与模块进行交互，并提供API接口。实践应用中，JVM-SANDBOX显著提升了故障演练效率、自动化依赖检测能力和服务端录制隔离回放的精准度。

       目前，JVM-SANDBOX已支持两个开源模块：chaosblade和Repeater，社区活跃度不断提升，期待更多开发者参与。团队呼吁对测试技术感兴趣的图片直播app源码伙伴加入社区，共同推动测试领域的进步。如果你对加入淘系技术质量团队感兴趣，可通过taobaoqa@list.alibaba-inc.com投递简历。

Jvm-Sandbox原理分析-Sandbox的启动-

       Jvm-Sandbox的启动（一）：sandbox.sh脚本分析

       Sandbox的启动是通过其内置的shell脚本 sandbox.sh 开始执行的，一切的开始皆可从该脚本中探寻出结果。脚本有一定的代码量，大概有+行，这里将该脚本分为如下几个部分进行讲解：

1、变量定义过程

       这个过程首先预定义了接下来即将使用的一些变量。代码如下：

# 定义sandbox的home目录，并为其赋值 typeset SANDBOX_HOME_DIR [[ -z ${ SANDBOX_HOME_DIR} ]] && SANDBOX_HOME_DIR=${ PWD}/..# 定义 SANDBOX_USER，并为其赋值 typeset SANDBOX_USER=${ USER} [[ -z ${ SANDBOX_USER} ]] && SANDBOX_USER=$(whoami)# 定义 SANDBOX_SERVER_NETWORK typeset SANDBOX_SERVER_NETWORK# 定义lib目录，这个目录下主要存放jar包 typeset SANDBOX_LIB_DIR=${ SANDBOX_HOME_DIR}/lib# 定义 SANDBOX_TOKEN_FILE typeset SANDBOX_TOKEN_FILE="${ HOME}/.sandbox.token"# 定义JVM参数 SANDBOX_JVM_OPS typeset SANDBOX_JVM_OPS="-XmsM -XmxM -Xnoclassgc -ea"# 定义目标JVM的进程号，后面的agent主要attach到该JVM进程上 typeset TARGET_JVM_PID# 定义目标机器IP以及默认机器IP typeset TARGET_SERVER_IP typeset DEFAULT_TARGET_SERVER_IP="0.0.0.0"# 定义目标进程端口 typeset TARGET_SERVER_PORT# 定义名称空间 typeset TARGET_NAMESPACE typeset DEFAULT_NAMESPACE="default"

       注释和变量命名已经描绘的非常清楚了，在看后面代码遇到忘记了的变量可以到这里来回顾下。

       这里为其中一些变量补充说明：

       SANDBOX_HOME_DIR：shell脚本中，-z表示检测紧跟的字符串长度是否为0，如果为0返回true。这里使用短路与，如果 ${ SANDBOX_HOME_DIR} 为0，则使用 ${ PWD}/.. 的目录作为sandbox的home目录。这种方式表示优先使用环境变量 SANDBOX_HOME_DIR，如果未定义环境变量SANDBOX_HOME_DIR，则使用当前目录。

       SANDBOX_TOKEN_FILE：这个文件主要存放了sandbox attach记录，包括attach进程的host:port。

       TARGET_SERVER_IP：一般情况下，我们都是将整个工程打包后上传至目标机器，然后在目标机器上执行该shell脚本，因此默认机器IP一般为localhost即可。

2、执行入口

       执行入口就比较简单了，就一行代码，其中${ @}会保存我们传递给该shell脚本的所有参数：

main "${ @}"

       比方说，我们以如下命令启动脚本，则${ @} 就包含了-p 这个参数

./sandbox.sh -p 、main函数

       main函数是该脚本的重要方法，也是脚本的执行入口，它主要完成了以下几件事：

       其代码如下所示：

function main() { # 遍历脚本参数 while getopts "hp:vFfRu:a:A:d:m:I:P:ClSn:X" ARG; do case ${ ARG} in h) # 帮助手册函数，大家可以自行翻阅源码查看 usage exit ;; # 赋值PID p) TARGET_JVM_PID=${ OPTARG} ;; v) OP_VERSION=1 ;; l) OP_MODULE_LIST=1 ;; R) OP_MODULE_RESET=1 ;; F) OP_MODULE_FORCE_FLUSH=1 ;; f) OP_MODULE_FLUSH=1 ;; u) OP_MODULE_UNLOAD=1 ARG_MODULE_UNLOAD=${ OPTARG} ;; a) OP_MODULE_ACTIVE=1 ARG_MODULE_ACTIVE=${ OPTARG} ;; A) OP_MODULE_FROZEN=1 ARG_MODULE_FROZEN=${ OPTARG} ;; d) OP_DEBUG=1 ARG_DEBUG=${ OPTARG} ;; m) OP_MODULE_DETAIL=1 ARG_MODULE_DETAIL=${ OPTARG} ;; # 赋值IP I) TARGET_SERVER_IP=${ OPTARG} ;; # 赋值PORT P) TARGET_SERVER_PORT=${ OPTARG} ;; C) OP_CONNECT_ONLY=1 ;; S) OP_SHUTDOWN=1 ;; n) OP_NAMESPACE=1 ARG_NAMESPACE=${ OPTARG} ;; X) set -x ;; ?) usage exit_on_err 1 ;; esac done # 重置环境 reset_for_env # 校验权限 check_permission# 根据不同的参数，进行相应处理 # 如果没有指定IP，则使用默认值 [ -z "${ TARGET_SERVER_IP}" ] && TARGET_SERVER_IP="${ DEFAULT_TARGET_SERVER_IP}"# 如果没有指定port，使用默认值 [ -z "${ TARGET_SERVER_PORT}" ] && TARGET_SERVER_PORT=0# reset NAMESPACE [[ ${ OP_NAMESPACE} ]] && TARGET_NAMESPACE=${ ARG_NAMESPACE} [[ -z ${ TARGET_NAMESPACE} ]] && TARGET_NAMESPACE=${ DEFAULT_NAMESPACE}if [[ ${ OP_CONNECT_ONLY} ]]; then [[ 0 -eq ${ TARGET_SERVER_PORT} ]] && exit_on_err 1 "server appoint PORT (-P) was missing" SANDBOX_SERVER_NETWORK="${ TARGET_SERVER_IP};${ TARGET_SERVER_PORT}" else # -p was missing [[ -z ${ TARGET_JVM_PID} ]] && exit_on_err 1 "PID (-p) was missing." # attach jvm的核心方法 attach_jvm fi# -v show version [[ -n ${ OP_VERSION} ]] && sandbox_curl_with_exit "sandbox-info/version"# -l list loaded modules [[ -n ${ OP_MODULE_LIST} ]] && sandbox_curl_with_exit "sandbox-module-mgr/list"# -F force flush module [[ -n ${ OP_MODULE_FORCE_FLUSH} ]] && sandbox_curl_with_exit "sandbox-module-mgr/flush" "&force=true"# -f flush module [[ -n ${ OP_MODULE_FLUSH} ]] && sandbox_curl_with_exit "sandbox-module-mgr/flush" "&force=false"# -R reset sandbox [[ -n ${ OP_MODULE_RESET} ]] && sandbox_curl_with_exit "sandbox-module-mgr/reset"# -u unload module [[ -n ${ OP_MODULE_UNLOAD} ]] && sandbox_curl_with_exit "sandbox-module-mgr/unload" "&action=unload&ids=${ ARG_MODULE_UNLOAD}"# -a active module [[ -n ${ OP_MODULE_ACTIVE} ]] && sandbox_curl_with_exit "sandbox-module-mgr/active" "&ids=${ ARG_MODULE_ACTIVE}"# -A frozen module [[ -n ${ OP_MODULE_FROZEN} ]] && sandbox_curl_with_exit "sandbox-module-mgr/frozen" "&ids=${ ARG_MODULE_FROZEN}"# -m module detail [[ -n ${ OP_MODULE_DETAIL} ]] && sandbox_curl_with_exit "sandbox-module-mgr/detail" "&id=${ ARG_MODULE_DETAIL}"# -S shutdown [[ -n ${ OP_SHUTDOWN} ]] && sandbox_curl_with_exit "sandbox-control/shutdown"# -d debug if [[ -n ${ OP_DEBUG} ]]; then sandbox_debug_curl "module//post/

通用流量录制回放工具 jvm-sandbox-repeater 尝鲜 (二)——repeater-console 使用

       通用流量录制回放工具 jvm-sandbox-repeater 的repeater-console部分使用详解

       陈恒捷，TesterHome社区主编和第十届MTSC大会上海站开源专场出品人，以其丰富的测试效能提升经验，带我们深入了解repeater-console的实际应用。repeater-console作为jvm-sandbox-repeater的补充，除了基本的录制和回放功能，还需要配合数据中心、模块管理和配置管理来完成业务回归和监控等任务。

       repeater-console主要功能包括数据存储、配置管理和数据对比，但其官方文档较为简单，用户需通过源码解析来理解其使用方法。要实现批量流量录制回放，需自行开发，因为当前demo工程仅包含基础功能。将repeater的standalone模式从true切换为false，并调整相关配置，如端口号和配置文件，才能通过console进行存储和配置获取。

       在实际操作中，首先需要关闭现有进程，修改配置文件，然后启动repeater-console，接着启动应用和sandbox，确保配置获取的顺序。通过~/logs/sandbox/repeater/repeater.log的日志，可以确认配置是否正确加载。然而，可能会遇到请求回放接口返回success但实际未触发应用请求的问题，这需要对源码中的RepeaterBridge进行调整。

       本文的重点在于演示如何在repeater-console的指导下实现录制回放，虽然没有实现批量回放，但展示了整个流程。在使用过程中，务必注意可能遇到的配置和代码调整，以及一些未明原因的内存地址问题，这需要进一步的调试和研究。

       本文首发于TesterHome社区，通过链接可查看原文，对于测试开发技术的爱好者，第十届MTSC大会·上海是一个不容错过的平台，提供丰富的内容和专家分享。

Jvm sandbox mock机制实践

       在构建测试平台时， JVM sandbox 沙箱机制提供了一种不重启、无侵入方式调整目标应用返回值的面向切面编程解决方案。对于 RPC 接口、HTTP 接口的测试尤为适用，当需要构建一个全面的模拟平台，而不仅仅是模拟 HTTP 接口时，这种方案变得尤为重要。本文将通过具体案例，展示如何实践 JVM sandbox 并构建模拟平台。

       为深入理解，我们以 Linux 服务器为例。首先，创建一个 Springboot 工程，并在其中定义一个 Controller 类作为 URL 入口，调用名为 Clock 的类。Clock 类是官方提供的案例，模拟了一个损坏的钟。运行工程后，会发现一直存在异常。

       接下来，我们将构建一个名为 clock-tinker 的 Maven 工程，用于修复损坏的钟。在 pom.xml 中添加依赖“sandbox-module-starter”，并创建“BrokenClockTinkerModule”类，用于修复 Clock 类中的问题。

       编译并部署 clock-tinker 工程后，生成 jar 包。然后下载安装 jvm-sandbox，并通过命令行操作将其与修复的 jar 包关联。通过查询服务器进程，找到损坏的钟对应的进程号，并启动 sandbox。之后，执行修复逻辑，使得修复后的 clock#checkState() 方法生效，修复的钟开始正确刷新时间。

       为了验证修复效果，需恢复原先的 check() 方法，并停止 sandbox。此时，修复的钟再次开始报错，这是因为随着 sandbox 的卸载，修复逻辑也随之失效。

       本文展示了利用 JVM sandbox 实践修复模拟案例的过程，通过不中断应用运行，实现模拟环境的构建。后续文章将深入探讨如何利用此机制搭建一个全面的模拟平台，提供更深入的实践指导。