AREX 是一款开源的基于真实请求与数据的自动化回归测试平台，利用 Java Agent 字节码注入技术，通过在生产环境录制和存储请求、应答数据，并在测试环境回放请求和注入 Mock 数据，存储新的应答，实现了自动录制、自动回放、自动比对，为接口回归测试提供便利。
AREX Mock 功能十分强大，不仅支持各种主流技术框架的自动数据采集和 Mock，还支持了本地时间、缓存数据以及各种内存数据的采集和 Mock，可以做到在回放时精准还原生产执行时的数据环境，且不会产生脏数据。
这篇文档将从代码实现的角度简单介绍下 AREX 是如何实现在流量回放时自动 Mock 数据的。
示例
让我们先以一个简单的函数为例，理解⼀下其实现原理。假定我们有下面⼀个函数，用于将给定的 IP 字符串转换成整型，代码如下：
public Integer parseIp(String ip) {
int result = 0;
if (checkFormat(ip)) { // 检查IP串是否合法
String[] ipArray = ip.split("\.");
for (int i = 0; i 我们将从两个方面说明如何实现该函数的流量回放功能：
- Record（流量采集）
当这个函数被调用时，我们把对应的请求参数和返回结果保存下来，供后面流量回放使用，代码如下：
if (needRecord()) {
// 数据采集，将参数和执⾏结果保存进DB
DataService.save("parseIp", ip, result);
}
- Replay（流量回放）
在进行流量回放时，就可以用之前采集的数据来自动实现这个函数的 Mock，代码如下：
if (needReplay()) {
return DataService.query("parseIp", ip);
}
通过查看完整的代码，我们可以更好地理解其实现逻辑：
public Integer parseIp(String ip) {
if (needReplay()) {
// 回放的场景，使⽤采集的数据做为返回结果，也就是 Mock
return DataService.query("parseIp", ip);
}
int result = 0;
if (checkFormat(ip)) {
String[] ipArray = ip.split("\.");
for (int i = 0; i AREX 中的具体实现
AREX 实现的原理类似，不过会更复杂⼀些，不需要开发人员手动在业务代码中添加录制和回放的代码。arex-agent 会在应用启动时，在需要的代码块中自动添加相应的代码来实现这个功能。这里以 MyBatis3 的 Query 为例，看看 AREX 中的具体实现。
阅读过 MyBatis 源码的应该都了解，Query 的操作都会收束在 org.apache.ibatis.executor.BaseExecutor 类的 query 方法上（Batch 操作除外），这个方法的签名如下：
public List query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException
这⾥包含了执行的 SQL 和参数，函数的结果包含了从数据库中查到的数据，显然在这里执行数据采集是合适的，在回放的时候也可以用采集的数据作为结果返回，从而避免实际的数据库操作。看看 AREX 中的代码，为了便于理解，这里做了⼀定的简化，如下:
public class ExecutorInstrumentation extends TypeInstrumentation {
@Override
protected ElementMatcher typeMatcher() {
// 需要进行代码注入的类全名
return named("org.apache.ibatis.executor.BaseExecutor");
}
@Override
public List methodAdvices() {
// 需要进行代码注入的方法名，因为query方法存在多个重载，所以带上了参数验证
return Collections.singletonList(new MethodInstrumentation(
named("query").and(isPublic())
.and(takesArguments(6))
.and(takesArgument(0, named("org.apache.ibatis.mapping.MappedStatement")))
.and(takesArgument(1, Object.class))
.and(takesArgument(5, named("org.apache.ibatis.mapping.BoundSql"))),
QueryAdvice.class.getName())
);
}
// 注入的代码
public static class QueryAdvice {
@Advice.OnMethodEnter(skipOn = Advice.OnNonDefaultValue.class, suppress = Throwable.class)
public static boolean onMethodEnter(@Advice.Argument(0) MappedStatement var1,
@Advice.Argument(1) Object var2,
@Advice.Argument(5) BoundSql boundSql,
@Advice.Local("mockResult") MockResult mockResult) {
RepeatedCollectManager.enter(); // 防止嵌套调用导致的数据重复采集
if (ContextManager.needReplay()) {
mockResult = InternalExecutor.replay(var1, var2, boundSql, "query");
}
return mockResult != null;
}
@Advice.OnMethodExit(onThrowable = Throwable.class, suppress = Throwable.class)
public static void onMethodExit(@Advice.Argument(0) MappedStatement var1,
@Advice.Argument(1) Object var2,
@Advice.Argument(5) BoundSql boundSql,
@Advice.Thrown(readOnly = false) Throwable throwable,
@Advice.Return(readOnly = false) List> result,
@Advice.Local("mockResult") MockResult mockResult) {
if (!RepeatedCollectManager.exitAndValidate()) {
return;
}
if (mockResult != null) {
if (mockResult.getThrowable() != null) {
throwable = mockResult.getThrowable();
} else {
result = (List>) mockResult.getResult();
}
return;
}
if (ContextManager.needRecord()) {
InternalExecutor.record(var1, var2, boundSql, result, throwable, "query");
}
}
}
}
其中 QueryAdvice 是需要在 query 方法中注入的代码。通过 onMethodEnter 注入的代码会在方法最开始地位置执行，而 onMethodExit 注入的代码则会在函数返回结果之前执行。
单纯地看这个可能比较难于理解，我们把注入代码后的 BaseExecutor 的 query 方法的代码 dump下来进行分析，如下：
public List query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
MockResult mockResult = null;
boolean skipOk;
try {
RepeatedCollectManager.enter();
if (ContextManager.needReplay()) {
mockResult = InternalExecutor.replay(ms, parameter, boundSql, "query");
}
skipOk = mockResult != null;
} catch (Throwable var28) {
var28.printStackTrace();
skipOk = false;
}
List result;
Throwable throwable;
if (skipOk) {
// 重放的场景，不再执行原来的 query 方法体
result = null;
} else {
try {
// BaseExecutor query 方法的原代码，此处省略，唯一会被调整的就是原方法里 return 的代码，会被修改为将结果赋值给 result
result = list;
} catch (Throwable var27) {
throwable = var27;
result = null;
}
}
try {
if (mockResult != null) {
if (mockResult.getThrowable() != null) {
throwable = mockResult.getThrowable();
} else {
result = (List)mockResult.getResult();
}
} else if (RepeatedCollectManager.exitAndValidate() && ContextManager.needRecord()) {
InternalExecutor.record(ms, parameter, boundSql, result, throwable, "query");
}
} catch (Throwable var26) {
var26.printStackTrace();
}
if (throwable != null) {
throw throwable;
} else {
return result;
}
}
可以看到 onMethodEnter 和 onMethodExit 里的代码被插⼊到了开头和结尾，再来理解下这段代码：
- 录制的场景
AREX 会判断这次访问数据是否需要录制（服务收到请求时，AREX 会根据配置的录制频率决定是否对这个请求进行录制，如果判断为需要录制，则这个请求执行过程中所有的外部依赖都会被录制，具体实现细节这里不做介绍了）。录制过程中，AREX 会调用 InternalExecutor.record(ms, parameter, boundSql, result, throwable, "query") 方法，将本次数据库访问的结果、核心参数等信息存入AREX的数据库中，完成对该数据库访问的录制。
- 回放的场景
从上面的代码可以看到，当把前面录制的请求再次发送给对应服务时，AREX 会将其视为回放，此时不会再执行原函数的代码了，而是直接返回之前录制下来的结果（包括当时异常的还原），通过调用 InternalExecutor.replay(ms, parameter, boundSql, "query”) 可以获取之前保存的录制数据。
内存数据的 Record&Replay（动态类）
当然，前面示例的函数是幂等的，对于幂等函数而言，由于每次调用时，其返回结果始终相同，不会受到外部因素的影响，因此在录制和回放过程中并不需要进行数据的采集和 Mock。
相反，对于非幂等的函数，每次调用的结果可能会受到外部环境的影响，并且执行结果会影响服务输出（例如各种本地缓存，不同的环境数据可能不同，从而影响输出结果）。在这种情况下，AREX 也提供配置动态类这种机制来实现这部分数据的 Record 和 Mock 功能，具体可以在 Setting 子菜单的 Record 配置项中配置：
在这里依次配置类名、方法名（非必需，不配置的话将会应用于所有有参数和返回值的公共方法）、参数类型（非必需）。配置完成后，arex-agent 将会自动在对应的方法中注入类似上面的 Record&Replay 代码，从而实现数据的采集和回放时的 Mock 功能。
