分析优化的经验交流分享

一、背景介绍

Sermant是一个主打服务治理领域的Java Agent框架，在服务治理中难免会有针对业务流量进行解析和处理的过程，此类服务治理能力将会对微服务的服务能力产生一定的性能影响，作为一个基于Java Agent技术做服务治理的框架，我们需要在保证服务治理能力生效的同时，极小的影响微服务原有的服务性能。

虽然基于Java Agent的服务治理和基于SDK的服务治理在其原理上有所不同，但也避免不了微服务治理过程中产生对微服务原有性能的影响，基于Java Agent服务治理方式的相较于SDK的服务治理方式免去了侵入式的代码开发，是一种运行时技术，所以还需要考虑更多方面性能优化问题，例如在启动时间，运行时增强性能开销等，本文将以Sermant的SpringBoot 注册插件的性能测试及优化过程为例，分享在Java Agent场景如何进行更好的性能测试优化及在Java Agent下需要着重注意的性能陷阱。

SpringBoot 注册插件为SpringBoot应用提供服务注册发现能力，可用于在不修改原有代码的前提下快速从ESB架构演进为微服务架构，在该插件中包含针对域名的替换能力，服务注册发现能力，请求的超时重试等，为架构的成功演进，原有架构中基于域名的请求调用，将会被基于注册信息的请求调用（通过该插件的服务注册发现能力，获取服务提供者注册的信息）所取代，如下图所示：

在域名处理的过程是必然会参与到调用过程中的，这是服务治理能力对业务性能影响的典型场景。

二、测试方案

众所周知，Java Agent程序和被增强应用运行时同进程，Java Agent程序最重要的是不能对被挂载的应用产生异常影响，导致应用不可用，所以Sermant在运行时的处理性能及稳定性等做多方面的测试考量。在针对微服务进行测试的过程中，我们往往只需要关注该微服务的性能即可，通过压力测试来检验微服务的服务提供能力，由于服务治理能力并不直接提供服务，我们更多地需要关注在开启服务治理能力时，对微服务本身服务提供能力的影响，所以我们在测试方案中需要进行对比测试来评估服务治理能力的好坏。

本对照测试中，我们通过压力测试让系统达到极限场景（consumer端的CPU已经到达瓶颈），来分析携带Sermant并启用服务治理能力时，对应用原有服务提供能力的影响，此处采用两种部署方案

• 不携带Sermant，基于网关的场景，是架构改造前的运行模式
• 携带Sermant的场景，是迁移后的微服务架构运行模式

注：在这种对比测试中，基于Java Agent的服务治理只需要对携带Java Agent程序和不携带Java Agent程序的场景进行对照测试即可，无需两套代码进行对照测试。

由于Java Agent程序和被增强应用处于统一进程，资源共享，基于上述两种部署方案进行测试，以不携带Java Agent程序作为测试分析的对照组，就可以很清晰的看出引入Java Agent程序后产生的影响，并可根据对照结果进行优化，应用于Sermant上，就可以很容易的分析出Sermant的服务治理能力对微服务本身服务提供能力带来的影响。

三、性能分析

由于需要针对应用发起的请求通过字节码增量的方式做域名的替换，SpringBoot 注册插件通过对HttpClient、Openfeign、Okhttp等http客户端进行了字节码增强，我们根据上一章节中的测试方案对该插件提供的服务治理能力进行了测试，下面我们以HttpClien为例通过CPU火焰图来讲述如何在Java Agent场景下分析性能瓶颈：

在性能调优过程中，我们可通过CPU火焰图来分析性能瓶颈，火焰图可以称之为性能问题分析的"X光"，可以很一针见血的看出在程序运行中哪些代码片段产生了异常的CPU占用。当然，采集CPU火焰图的方式很多，我们只需要学会如何看懂火焰图即可。

分析步骤

1. 找到字节码增强逻辑的CPU占用

在分析过程中，首先需要找到字节码增强时选中的被增强方法（本文场景增强方法为InternalHttpClient::doExecute），字节码增强需要被增强程序的原有方法调用触发，所以也可以很清晰的在CPU火焰图中可以看到，Sermant实现的逻辑调用栈在被增强方法之上，在字节码增强逻辑执行结束后，被增强方法还会继续执行。

所以除被增强方法执行的调用栈及CPU时间片占用外，皆为字节码增强所引入逻辑，在性能优化中需着重关注。

2. 分析异常占用

根据CPU火焰图原理，找出字节码增强部分，找出异常占用CPU时间片的调用栈，并进行程序的优化，如下图所示红框选择部分，皆为字节码增强中引入的逻辑，占用了非常多的CPU时间片，由于字节码增强程序和被增强程序，这种异常的占用，将会严重影响原程序的性能，在针对Java Agent场景的优化中可着重优化

通过上述步骤，我们可以一目了然的看到我们通过Java Agent程序引入的CPU额外占用，具体占用原因本文就不一一分析。

四、性能陷阱

基于上述两个章节的测试和分析方法，在本文的最后，列举出在Java Agent开发过程中经常会遇到的性能陷阱，这里也给出解决方式，可以在开发中注意：

减少反射使用

在字节码增强开发过程中，很多情况下，如果类加载器不同，针对被增强应用的类和方法往往需要通过反射去获取并使用，在我们的性能分析中，反射是一个CPU占用的巨大陷阱，在有些被BootstrapClassLoader加载的类增强时，甚至反射占用了一个方法调用30%以上的CPU时间片。

下图选中方法中，反射占用该方法调用中的大部分CPU时间片:

但是由于类加载器的限制，有些反射是必须要使用的，我们也可以通过一定的手段进行优化，比如缓存通过反射获取的类和方法，在字节码增强中，多次触发增强逻辑时减少反射占用CPU时间片非常有效。

1. Method method = METHOD_CACHE.get(methodKey);  
2. if (method != null) {  
3.     return Optional.of(method);  
4. }  
5. method = clazz.getDeclaredMethod(methodName, paramsType);  
6. METHOD_CACHE.put(methodKey, method);  

通过上述步骤优化后，通过火焰图来看，效果是非常显著的：

注意字节码增强插桩选择

在做字节码增强时的增强点选择很重要，字节码增强添加Transformer后运行时分为两种情况：

• transform：针对尚未被类加载器加载的类，如果添加Transformer，在类被加载时就会触发字节码的转换。
• retransform：针对已经被类加载器加载的类，如果添加了Transformer，则需要被重新加载后再进行字节码的转换。

Java中被BootstrapClassLoader加载的类，如果想要进行字节码增强，就需要使用第二种字节码转换的方式，可想而知，如果重新加载类再进行转换必然没有在类第一次加载时就进行转换的效率高。

除上述原因之外，在增强启动类加载器加载的类时，由于双亲委派机制的限制（只能向上委托，不能向下委托），往往都是需要大量使用反射（用于调用其他类加载器加载的类）来实现增强逻辑。

上文中也讲到，不加节制的使用反射将会通过Java Agent程序严重影响被增强应用的性能，所以在开发Java Agent时，需要谨慎选择增强的类，非必要不增强被启动类加载器加载的类。

上述两点是在Java Agent开发过程中最容易发生