阿里妹导读：稳定性是历年双11的技术质量保障核心。从 2016 年开始淘宝技术质量部潜心修行，创新地研发了一套实时无侵入的字节码增强框架，于是“JVM-SANDBOX”诞生了，并且顺手在 MTSC 大会上拿了开源贡献奖，今天，我们来瞅瞅这个拿奖的专案。

在近日举行的中国移动互联网测试开发大会（简称MTSC大会），来自淘系技术质量开源专案“JVM-SANDBOX”以及淘系同学参与维护的“ ATX” 包揽了 MTSC 2019 年度开源贡献奖，表彰过去一年在测试领域开源专案中的突出贡献。其中，“JVM-SANDBOX”致力于为服务端稳定性领域提供实时无侵入的字节码增强框架。

一、JVM-Sandbox的诞生

功能回归、业务/系统监控、问题排查定位、强弱依赖、故障演练等是阿里 10 年双十一沉淀积累下来的稳定性专项，也是历年双十一质量保障的核心要素。要有效、轻量级地实现这些稳定性专项，都会触及到一块底层技术—— java 字节码增强。如果每个专项都能自己实现一套字节码增强逻辑，实现的门槛高、投入和维护成本高，且不同专项间相互影响造成不可预知的风险。如何遮蔽字节码增强技术的高门槛，降低成本，同时又能支援上层多个专项功能的快速实现和动态管理，成为淘宝技术质量部的目标。从 2016 年开始我们潜心修行，创新地研发了一套实时无侵入的字节码增强框架，于是 “JVM-SANDBOX” 诞生了。

对上面提到的专项进行抽象分析：

故障演练：在执行前，丢掷异常或增加执行时间，即：干预方法的执行顺序和改变返回值；强弱依赖梳理：系统执行时，实时记录系统的对外呼叫情况，即：感知方法的入参和返回值；录制回放：执行时，记录方法的入参和返回值，回放时，不真实对外呼叫，而是直接返回录制时的返回值。即：感知方法入参和返回值，干预方法执行顺序，改变返回值；精准回归：获取每个请求的行呼叫链路，根据行呼叫链路进行场景去重，根据程式码改动的情况和行呼叫链路确定需要回归范围，即：执行时行链路感知。不难发现，要解决这些问题本质就是如何完成 java 方法的环绕管控和执行时行链路的获取，即 AOP 框架的解决方案。目前常用 AOP 框架的解决方案有两种：proxy 和埋点。proxy 的优点在于已实现了统一的 API，减少了重复投入，但是不能实时生效，需要系统编译重启。埋点的优点在于动态生效灵活度高，但是没有统一 API。

要快速解决上边的三个问题，我们需要的 AOP 解决方案必须具备两个特性：

动态可插拔，即实现埋点方式的统一的 API；无侵入性，即解决 JVM 类隔离的问题。基于以上需求，我们研发了 JVM-Sandbox。

二、实现方式

JVM-Sandbox 由纯 Java 编码完成，基于 JVMTI 技术规范，为观察和改变程式码执行结果提供了即插即用模组界面的容器，提供两个核心功能：实时无侵入 AOP 框架和动态可插拔的模组管理容器。

2.1 JVM-Sandbox的核心功能

使用埋点技术提供统一的 API，来实现无需重启的 AOP 解决方案；使用容器完成 JVM 类隔离，来解决侵入性问题；提供容器管理机制，来完成各种容器的管理。2.2 JVM—Sandbox的核心事件模型

BEFORE、RETURN 和 THROWS 三个环节事件的正常流转和干预流转。

2.3 整体架构

沙箱一共由三大核心功能元件构成

程式码编织元件：负责完成预设程式码的重写和生效；事件处理分发元件：负责完成事件的分发和方法流控控制的执行；模组管理元件：负责控制和管理沙箱的各个模组。沙箱的底层提供了一个 HTTP-SERVER(Jetty)，通过 HTTP 协议完成 sandbox.sh和沙箱的控制互动，同时也给各个模组提供了基于 HttpServlet 和 WebSocket 规范的 API，各模组可以复用沙箱完成各自模组的控制与互动。

三、业务的实践效果

3.1、线上故障演练

17年故障演练平台在 JVM-Sandbox 基础上仅耗时1周即完成故障注入部分的系统重构。重构后的系统在挂载效率和挂载成功率方面有了明显的提升，极大地缩短故障演练的时间，演练效率提升了数十倍。基于 JVM-Sandbox 改造后的故障演练平台，通用性强，所有基于 JVM 启动的系统均支援，极大地拓展了故障演练的范围，故障演练已达到集团级部署。

与16年故障演练资料对比，17年的故障演练平台，覆盖 BU 提升了1.6倍，覆盖应用提升了5倍，覆盖场景提升了37倍。18年故障演练平台覆盖了阿里集团，并演化为现在的攻防演练。

3.2、依赖检测

17年强弱依赖自动化检测平台诞生。它提供了依赖检测、强弱分析、依赖扫描、故障注入等多种能力，底层能力基于 JVM-Sandbox 在1周内完成功能开发。利用其模组容器的特性，将前人开发的模组与新增模组一起挂载共同工作，完成平台功能。

强弱依赖梳理方面，承载了淘宝的系统强弱依赖梳理工作，260+个应用一键接入系统，并实现了0人工成本的自动化、智慧化梳理。18年与 Mock 回放相结合，实现写界面依赖自动检测功能，目前正在不断完善。

3.3、服务端录制隔离回放机制

在 JVM-Sandbox 基础上开发了一个 SS 模组，相当于一个录音机+回放机，在呼叫中介软件的时候，顺序录制下了我们的中介软件请求，并且储存这份‘磁带’到服务器上。当我们需要隔离回放的时候，将这份‘磁带’找到，并且在需要的时候直接从‘磁带’读取，并不需要真实地请求我们的中介软件，这样就保证了我们的读、写界面也能做到可重复使用，从而实现服务端的隔离回放。线上录制隔离回放不仅极大地缩短业务回归的耗时，把业务测试同学从繁琐的资料准备和界面自动化指令码的编写过程中解放出来，而且极大地拓展了覆盖范围，使回归的范围更贴近使用者，且场景更丰富。

3.4、精准回归

服务端录制隔离回放机制诞生之后，虽然有效地提升了覆盖范围，降低了自动化指令码的人工投入，但是也带来了新的问题。线上录制的场景是海量的，单个系统都可以达到万级、十万级甚至百万级别的录制，这些录制的场景中，存在大量的重复场景，如何识别重复场景，实现有效、精准的回放，成为新的待解决问题。在 JVM-Sandbox的基础上，利用 LineEvnet 实现了行链路识别和标记，有效地提升了回放的精准度和效率。