共计 5460 个字符，预计需要花费 14 分钟才能阅读完成。
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 < ipArray.length; i++) {
result = result << 8;
result += Integer.parseInt(ipArray[i]);
}
}
return result;
}咱们将从两个方面阐明如何实现该函数的流量回放性能：
- ecord（流量采集）
当这个函数被调用时，咱们把对应的申请参数和返回后果保留下来，供前面流量回放应用，代码如下：
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 < ipArray.length; i++) {
result = result << 8;
result += Integer.parseInt(ipArray[i]);
}
}
if (needRecord()) {
// 录制的场景，将参数和执⾏后果保留进到数据库
DataService.save("pareseIp", ip, result);
}
return result;
}AREX 中的具体实现
AREX 实现的原理相似，不过会更简单⼀些，不须要开发人员手动在业务代码中增加录制和回放的代码。arex-agent 会在利用启动时，在须要的代码块中主动增加相应的代码来实现这个性能。这里以 MyBatis3 的 Query 为例，看看 AREX 中的具体实现。
浏览过 MyBatis 源码的应该都理解，Query 的操作都会收束在 org.apache.ibatis.executor.BaseExecutor 类的 query 办法上（Batch 操作除外），这个办法的签名如下：
public <E> List<E> 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<TypeDescription> typeMatcher() {
// 须要进行代码注入的类全名
return named("org.apache.ibatis.executor.BaseExecutor");
}
@Override
public List<MethodInstrumentation> 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 <E> List<E> 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 性能。
