起点服务端在Java Agent技术上的探索与实践

点击箭头处“蓝色字”，关注我们哦！！

 Java

随着程序功能的⽇益复杂,项⽬中依赖了越来越多的技术组件，有些是开源第三⽅的，有些是内部⾃研的，⽽这些技术组件更多是以 library ⽽不是 framework 的形态存在。随着程序的迭代运⾏，慢慢积累了以下问题：

1. 很多同学不知道这些 library 怎么⽤，如何进⾏恰当的配置部署，甚⾄都不知道有这么个东⻄存在。那么这些library 提供的能⼒就等于没⽤ (即:你再强，我不⽤，等于没有)。

2. 每个团队都有⾃⼰特殊的需求，很难有⼀个实现⽅案可以满⾜所有⼈的定制化需求。但是这些library 往往没有提供合适的扩展点供我们去定制化。

3. ⼤部分的 library 的⽣效都依赖于特定的配置，在实践过程中经常发现缺少特定的框架配置或者配置的参数有误，容易导致各种各样问题的发⽣。⽐如在⽣产环境中开启了 DEBUG 的⽇志级别造成磁盘空间不够；接⼝缺少熔断限流策略的保护；timeout 配置的过⻓等等.

4. 这些 library 的接⼊往往对项⽬代码具有⼀定的侵⼊性，我们更倾向于⼀个零侵⼊性的方案。综上所述，我们需要引⼊⼀个技术⽅案，⼀个 framework 去解决这些问题！

2.2 Java Agent 具体介绍

回顾⼀下，类是怎么被加载到 JVM ⾥⾯的？即加载->验证->准备->解析->初始化。在加载阶段，⼀定会有⼀个步骤是把类的字节码信息读⼊ JVM（可能是.class⽂件、可能是⽹络等）。那么我们可不可以在获取到类的字节码后，开始下⼀个步骤前，修改⼀下类的字节码信息呢？

Java Agent 是从 JDK1.5 开始引⼊的，算是⼀个⽐较⽼的技术了。作为 Java 的开发⼯程师，我们常⽤的命令之⼀就是java 命令，⽽ Java Agent 本身就是 java 命令的⼀个参数（即 -javaagent）。-javaagent 参数之后需要指定⼀个 jar 包。

在 Java 虚拟机启动时，执⾏ main() ⽅法之前，虚拟机会先找到 -javaagent 命令指定 Jar 包，然后执⾏指定的 premain-class 中的 premain() ⽅法。⽤⼀句概括其功能的话就是：premain() ⽅法是 main()⽅法执⾏之前的⼀个拦截器。

使⽤ Java Agent 的步骤⼤致如下

1. 定义⼀个 MANIFEST.MF ⽂件，在其中添加并指定 premain-class 配置项

2. 创建 premain-class 配置项指定的类，并在其中实现 premain() ⽅法，⽅法签名如下：

3. 将 MANIFEST.MF ⽂件和 premain-class 指定的类⼀起打包成⼀个 Jar 包.

4. 使⽤ -javaagent 指定该 Jar 包的路径即可执⾏其中的 premain() ⽅法。

 什么是instrumentation？

Instrumentation是⼀个接⼝，定义了字节码修改的规范，其位于 java.lang.instrument 包下⾯。

Instrumentation的⼀些主要⽅法如下：

重点关注⼀下 这个⽅法，在这个⽅法⼊参⾥⾯有⼀个关键的接⼝类是 ClassFileTransformer

顾名思义就是类⽂件转换器。它只有⼀个接⼝定义⽅法：

通过 addTransformer ⽅法将ClassFileTransformer注册之后,后续被加载的类都会被注册的ClassFileTransformer 拦截并转换。

然而,直接使用Java Agent 原生的API,实现一个ClassFileTransformer 来对类的二进制数据进行增强转换,其实并不容易.其中涉及到的底层原理和实现细节对开发人员的门槛较高!

      3.2 技术选型

MoonWalker 部分技术选型和实现⽅案借鉴⾃ SkyWalking  ，⼀款国⼈开源的APM产品，2019 年 4 ⽉17 ⽇ SkyWalking 从 Apache 基⾦会的孵化器毕业成为顶级项⽬。

框架利⽤Byte Buddy完成对字节码的修改，Byte Buddy 是⼀个开源 Java 库，其主要功能是帮助⽤户屏蔽字节码操作，以及复杂的 Instrumentation API 。Byte Buddy 提供了⼀套类型安全的 API 和注解，我们可以直接使⽤这些 API 和注解轻松实现复杂的字节码操作。另外，Byte Buddy 提供了针对 Java Agent 的额外 API，帮助开发⼈员在 Java Agent 场景下轻松增强已有代码。

     3.3 Quick Start

下⾯演示如何在应⽤中接⼊MoonWalker：

1. 在业务应⽤中通过 maven 引⼊MoonWalker的依赖

2. 在启动命令前加上

3. 启动后观察⽇志

   背景:  ProxyStatPlugin 这个插件需要对Rpc 框架的每次调用的耗时情况进行采集上报,需要拦截ProxyStat 这个类的addlnvoke Time 方法.在我们Rpc框架的运行环境中,这个类所在的

Jar包是由AppClassLoader 加载的,而插件依赖的第三方类库是由Rpc框架的自定义的Class Loader 加载的.

• 第一版

⼀开始，我将 plugin 和 agent 打成⼀个 Jar 包，由 Java Agent 命令执⾏的 Jar 是由AppClassLoader加载的，从⽽导致 Plugin 的 interceptor 也是由 AppClassLoader 所加载，⽽ interceptor 所依赖的第三⽅类库是由 Rpc 框架⾃定义的ClassLoader 所加载的。根据由⽗加载器加载的类不能看⻅⼦加载器加载的类，所以会导致失败报错。下图中标注的代码 引⼊了第三⽅类库，在类的初始化或者实例化阶段都会产⽣异常，导致增强失败。

• 第二版
  

后⾯进⾏修改，将 plugin 和 agent 打成两个 Jar 包，通过⾃定义 PluginClassLoader 根据配置相对路径的classpath 来加载 Plugin，同时将 TargetClass (⽬标类) 的定义类加载器（或者线程上下⽂加载器）作为PluginClassLoader 的 parent（⽗加载器），保证 interceptor 由较为“下层”的类加载器加载。因为类加载器越处于“下层”，它的“上层加载器”就越多，它的namespace（命名空间）范围就越⼤。

进⼀步的，为了保证 interceptor 是由较为“下层”的类加载器加载的，这⾥的PluginClassLoader 是打破了双亲委派机制的。双亲委派机制其实是⼀个 parent-first 的实现，与之相反就是 child-first 的实现，即在通过PluginClassLoader 加载类时，如果这个类是在 Plugin Jar 中定义的，那么就由 PluginClassLoader⾃⼰去加载，否则还是由  parent（⽗加载器）去加载。

具体代码实现:

左边是classLoader里面双亲委派的实现,右边是child-first的实现

3.扩展问题

   如何要去修改 BootStrapClassLoader 所加载的类，如何分析并解决其中的 classLoader 问题？

⼀个 V 站的例⼦：

原因很简单：ThreadPoolExecutor 是由 BootStrapClassLoader 加载的，织⼊的代码有⾃定义的MDCInheritableThreadLocal，肯定是由 BootStrapClassLoader 的⼦加载器所加载的，由⽗加载器加载的类不能看⻅⼦加载器加载的类。

类似得，在 MoonWalker 如果需要实现对修改 BootStrapClassLoader 所加载的类，也会有这种问题

上图中 InstanceMethodDelegationTemplate  就是上⾯所说的MethodDelegationTemplate（⽅法代理模板），作⽤是提供⼀个代码模板、⼀层桥接，将 InterceptChain（拦截链）织⼊到TargetMethod （⽬标⽅法）从⽽糅合形成最终增强后的⽅法代码。这个类以及所引⽤的第三⽅依赖（上图标注的代码）对于BootStrapClassLoader 都是不可⻅的。为了解决这个问题，就必须要让它们在 BootStrapClassLoader 中可⻅。

那怎么让指定的类 BootStrapClassLoader 中可见?

解决的思路:将这些类 Inject (注入)到 BootStrapClassLoader 使得 BootStrapClassLoader能够正常加载解析这些类,如同加载解析 java.lang.Object 一样.

方法有这么几种:

1.将这些类打成⼀个临时 jar ⽂件，通过 Instrumentation 的voidappendToBootstrapClassLoaderSearch(JarFile jarfile)  方法

2.通过 Unsafe 里的 public native Class<?> defineClass(String var1,byte[] var2,int var3,int var4,ClassLoader var5,ProtectionDomain var6) 方法

4.4 Agent Jar部署的问题

由于 Java Agent 的运⾏需要指定 Agent Jar 的全路径，所以需要考虑如何将 Agent Jar 安置到⼀个固定的路径。⽬前MoonWalker 采⽤通过 maven 引⼊的⽅式将 Agent Jar 和 Plugin Jar 和应⽤代码⼀起进

⾏打包部署，这种⽅式的代价较⼩。否则就需要通过运维介⼊，将 Agent Jar 和 Plugin Jar 投放到物理机中，或者打⼊到docker 的镜像中。

在⾮ springboot 项⽬中，这种⽅式是没有问题的，Agent Jar 和 Plugin Jar 会和第三⽅ Jar ⼀起解压到固定的 lib ⽬录下。但是在 springboot 项⽬中，这种⽅式⼀般情况下是⾏不通的。因为 springboot 是通过⾃定义的 springboot-maven-plugin 将项⽬打包成为⼀个 Fat Jar 来部署的。我们所有通过 maven 引⼊的依赖都在这个 Fat Jar ⾥的 BOOT-INF/lib 路径下，需要通过springboot ⾃定义的LauncherClassLoader 来加载。如果 Agent Jar 打包在这个 Fat Jar ⾥的 BOOT-INF/lib 路径下，相当于Agent Jar 内嵌在 Fat Jar ⾥⾯，是⽆法在 Java Agent 指令中指定它的路径的，从⽽⽆法在 Java Agent 机制下运⾏。

解决⽅案（尚处于开发测试中）

我们可以通过扩展 springboot-maven-plugin 这个 maven 插件，使得 Agent Jar 不会被打包到 Fat Jar ⾥的BOOT-INF/lib 路径下，⽽是直接解压到 Fat Jar ⾥的顶层⽬录下，即和 springboot 启动相关的类处在同⼀层级，⼀起被AppClassLoader 加载。

具体扩展点是

通过⾃定义 LayoutFactory，使得⽣产出的 Layout 实现 CustomLoaderLayout 这个接⼝，从⽽获得可以写⼊⾃定义loaderClass 的能⼒。通过这种⽅式，最终打包的 Fat Jar 就可以既具备 Executable Jar（可执⾏ Jar）的能⼒，⼜具备 Agent Jar 的能⼒，所以我们⽆需再考虑如何安置 Agent Jar ，只需将原来的启动命令 java-jar demo.jar  改成 java-javaagent:demo,jar-jar demo.jar

4.5 如何实现一个Plugin

1.实现 ClassEnhancePluginDefine 接口,定义插件的名字、需要增强哪些类、满足哪些条件下生效、是否需要进行版本见证、对应该类的 InterceptPoint 集合等.(注意: ClassEnhancePluginDefine  实现类中所有有关类的信息,方法信息,Interceptor 信息等必须都由字符串直接描述,比如“ test.moonwalker.plugin.benchmark.interceptor.TestBenchmarkInterceptor";不能用TestBenchmarkInterceptor.class.getName() 这种方式,因为在扫描解析 Plugin 的时候,还无法正确加载相关类)

2.编写具体的 Interceptor ,实现MethodInterceptor 或者 ConstructorInterceptor ,实现intercept 方法,在其中编写具体增强逻辑

一个例子,对有特定注解的方法进行监控: