作者简介
Mo.,携程研发总监,专注系统性能、开发效能、业务架构等领域。
技术原理:
在JDK1.5中,Java引入了java.lang.Instrument包,该包提供了一些工具帮助开发人员在 Java 程序运行时,动态修改系统中的 Class,以此实现对原类的功能增强。现在有很多工具都是基于此技术实现的,例如阿里开源的arthas、监控工具SkyWalking等, AREX的数据采集和自动Mock也是基于此技术实现。
public class RunnableWrapper implements Runnable { private final Runnable runnable; private final TraceTransmitter traceTransmitter;
private RunnableWrapper(Runnable runnable) { this.runnable = runnable; this.traceTransmitter = TraceTransmitter.create(); }
@Override public void run() { try (TraceTransmitter tm = traceTransmitter.transmit()) { runnable.run(); } }
@Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false;
RunnableWrapper that = (RunnableWrapper) o; return runnable.equals(that.runnable); }
@Override public int hashCode() { return runnable.hashCode(); }
@Override public String toString() { return this.getClass().getName() + " - " + runnable.toString(); }
public static Runnable get(Runnable runnable) { if (null == runnable || TraceContextManager.get() == null) { return runnable; }
if (runnable instanceof RunnableWrapper) { return runnable; } return new RunnableWrapper(runnable); }}
然后代码修饰各种线程池,把Runnable/Callable替换掉,而Wrapper内部通过TraceTransmitter保证Trace的正确传递。
2)ForkJoinPool
CompletableFuture、数据集的并行stream处理默认使用的是ForkJoinPool,重并行计算的应用也经常采用,这个和常规的线程池实现有较大的区别,需要单独处理,我们对ForkJoinPool的任务单元ForkJoinTask进行了修饰,这个类实现比较复杂,难于像Runnable那样简单处理,而且为了不破坏原有的类结构(Agent on attach方式也不支持修改),没有在这个类上添加字段实现数据中转,而是采用了一个WeakCache做数据缓冲,可以保证任务生成和执行线程之间的Trace传递。
3)异步
Java生态中存在很多异步框架(Reactor、RxJava etc),也有很多类库提供了异步实现,如lettuce就提供了同/异步访问Redis的方式。不同的场景往往需要不同的解决方法。以ApacheAsyncClient为例,是以固定运行的线程监听响应,并发起Callback,我们要保证调用、监听、回调整个流程中多个跨线程的Trace传递,具体实现可以参见 ApacheAsyncClient。
4)其他
版本管理
流行的组件往往存在多个版本同时在不同的系统中使用,不同的版本实现方式差别可能很大,甚至不兼容,AREX中也有提供多个版本的支持(如Jedis),我们就要保证能按正确的版本进行字节码注入,避免运行错误。字节码注入是在类加载时进行的,这样我们就必须在这些类加载前识别出应用依赖的组件版本,从而在类加载时进行版本的匹配,保证正确的代码注入,一部分实现可参见VersionMatch。
时间管理
很多业务系统是时间敏感的,不同的时间访问往往会返回不同的结果,因此我们也实现了时间的Mock功能。由于回放是并行执行的,修改测试机器的机器时间是不合适的(而且很多服务器也不能修改当前时间),所以还是在代码层面上实现的时间的Mock。
在数据采集时,我们针对每个用例记录了当前时间,在回放时,会对System.currentTimeMills(Java的很多时间底层都是通过这个方法实现)方法进行代理,然后计算多次访问的时间差(System.nanoTime实现)来保证时间的准确性, 不过仍然可能存在毫秒级的差距。
本地缓存
业务应用中可能使用了各式的缓存来提升运行时的性能,不同的环境这些数据可能存在较大的差异(多个环境的数据同步往往是一个比较复杂的过程),这些数据差异可能会导致完全不同的执行结果,为了避免这个问题,AREX也支持了本地缓存数据的采集和Mock功能,只需要进行一些简单的配置,即可实现数据的自动采集和Mock,当然这个功能也可支持各种内存数据的Mock功能。
代码隔离、互通
为了系统的稳定性,AREX agent的框架代码是在一个独立的Class loader中加载,和应用代码并不互通,为了保证注入的代码可以正确在运行时被访问,我们也对ClassLoader进行了简单的修饰,保证运行时的代码会被正确的ClassLoader加载(想想SpringBoot的LaunchedURLClassLoader)。
五、项目现状
AREX项目在携程机票内部发起,经过一年多的发展,逐渐推广到酒店、旅游、商旅、平台等多个部门,而且携程内部的多个团队已经用AREX代替了其它自动化工具和手工测试来进行回归测试。
目前我们已将项目开源:AREX 。鉴于各种技术框架、类库茫茫多,支持的必然还不太够,欢迎各位有志之士共同来完成,让我们共同构造一个简单、高效的研发测试方式(试想针对每次迭代,代码提交后测试自动执行,并反馈测试报告,开发和测试人员只需要关注在新业务的研发、验证上即可,脱离那些繁琐的数据和脚本,以及测试了无数遍的旧功能)。联系VX入群:vx20180604。
【推荐阅读】
“携程技术”公众号
分享,交流,成长