本文分享自华为云社区《Sermant类隔离架构解析——解决JavaAgent场景类冲突的实践》，作者：华为云开源。

Sermant是基于Java字节码增强技术的无代理服务网格，其利用Java字节码增强技术为宿主应用程序提供服务治理功能。因深知JavaAgent场景中类冲突问题会造成的影响，Sermant在设计之初便为此规划了全面的类隔离架构。经历多次迭代，如今Sermant的类隔离架构已可以轻松的应对各种复杂的类加载环境。

一、JavaAgent场景为什么要注意类冲突问题？

类冲突问题并非仅存在于JavaAgent场景中，在Java场景中一直都存在，该问题通常会导致运行时触发NoClassDefFoundError、ClassNotFoundException、NoSuchMethodError等异常。

从使用场景来看，基于JavaAgent技术所实现的工具，往往用于监控、治理等场景，并非企业核心业务程序。如果在使用时引入类冲突问题，可能会造成核心业务程序故障，得不偿失，所以避免向核心业务程序引入类冲突是一个JavaAgent工具的基本要求。

还有一个重要原因是在Java应用中可以于开发态采用依赖的升降级、统一依赖架构治理等手段解决该问题。但基于JavaAgent技术实现的工具作用于运行态，无法在开发态就和需要被增强的Java应用进行统一的依赖管理，所以引入类冲突问题的可能性更大。

二、JavaAgent场景如何解决该问题？

无论是在Java应用中，还是在JavaAgent场景，修复类冲突的逻辑都是一致的，就是避免引入会冲突的类。不同点在于基于JavaAgent技术实现的各式各样的工具，往往都具有业务无关性，在设计和实现之初，并不会为特定的Java应用类型而定制。对于JavaAgent程序而言，需要被字节码增强的应用即是黑盒，所以无法像Java应用那样去梳理依赖结构，排除、升级依赖项，统一进行依赖架构治理。并且JavaAgent往往在运行时使用，所以只能通过保障依赖绝对隔离的方式来避免引入冲突。

为何会产生类冲突，本文重点不在此，简单讲是因为我们在Java中因为重复引入传递依赖、类的加载顺序无法控制等问题，导致引入了相同【类加载器和全限定类名(Fully Qualified Class Name)都相同】但又表现不同【因为类版本不同而导致的类逻辑不一致】的类。所以为了避免冲突，我们就需要避免在运行时引入相同的类，如何让JavaAgent引入的类和宿主完全不相同，从全限定类名和类加载器下手才是根本：

• 基于maven shade plugin进行类隔离

该插件是Maven提供用于构建打包的插件，通过maven-shade-plugin的‘Relocating Classes’能力，来修改某些类的全限定类名。

此方法的原理便是通过改变全限定类名来让JavaAgent引入的类和Java程序的类完全不可能出现相同的情况，从根本上避免类冲突。但是我们在使用一种框架，或者使用一种产品时，往往约定要优于配置，基于maven-shade-plugin通过配置去改变全限定类名并不是一个简单的办法，在使用时就需要针对JavaAgent所涉及依赖进行梳理，在maven-shade-plugin中进行配置，并且需要在每次依赖变更后重新筛查。对持续迭代极不友好。

采用上述方法也对Debug造成阻碍，在Debug过程中被重定向的类的断点将不可达，严重降低调试效率。

• 基于类加载机制进行类隔离

基于maven-shade-plugin修改全限定类名往往用来解决单点的类冲突问题，虽然也能做到将JavaAgent所引入类完全隔离，但并不是一个好的解决方案。

基于类冲突原理，我们还可以通过限制两个相同全限定类名的类的加载器来让其不同，如Tomcat那样，通过自定义类加载器破坏Java的双亲委派原则，来隔离JavaAgent引入的类。这样既避免了繁重的配置，也避免了依赖变更而带来的影响。但也有其弊端，在JavaAgent场景中往往会利用到Java应用程序的类，所以基于类加载器的隔离机制，往往就让开发者只能通过反射等操作完成此类逻辑，这会对性能和开发效率产生不良影响。

三、Sermant如何做？

Sermant是基于Java字节码增强技术的无代理服务网格，不仅是一个开箱即用的服务治理工具，也同样是一个易用的服务治理能力开发框架。

“把简单留给别人，把麻烦留给自己！”

Sermant从设计之初就遵循上述重要原则，并规划了全方面的类隔离架构，利用Java的类加载机制对自身各模块做了充分类隔离，让使用者和开发者无需考虑因使用JavaAgent而导致类冲突问题，并且也针对开发者的使用场景做了优化，可以在开发中无缝使用被增强Java程序的类，避免因反射等行为带来的不利影响。Sermant是如何实现的呢，下文将对Sermant类隔离架构进行详细解析。

1) Sermant的类隔离架构解析

如上文所说，Sermant不仅是个开箱即用的服务网格，也同样是一个易用的服务治理能力开发框架，服务治理能力是多样的包括但不限于流量治理、可用性治理、安全治理等，所以Sermant采用插件化的架构来让用户能更灵活的接入和开发服务治理能力。

在Sermant的整体架构下，我们不仅需要保证不向宿主服务引入类冲突问题，避免在开箱即用时对宿主服务造成负面影响，同时也需要保障框架与插件、插件与插件之间不会引入类冲突问题，避免插件开发者因为和其他服务治理插件产生类冲突问题而苦恼，所以Sermant设计了如下类隔离结构：

• SermantClassLoader，破坏双亲委派，用于加载Sermant框架核心逻辑，并在AppClassLoader下隔离出Sermant的类加载模型。避免受到宿主服务自身复杂类加载结构的影响，减少应对不同类加载结构服务的适配需求。
• FrameworkClassLoader，破坏双亲委派，主要作用是隔离Sermant核心能力所引入的三方依赖，避免向宿主服务及服务治理插件引入类冲突问题。目前的主要场景 ①用于隔离Sermant的日志系统，避免对宿主服务的日志系统产生影响 ②隔离Sermant框架的核心服务（心跳、动态配置、统一消息网关）所需三方依赖。
• PluginClassLoader，遵循双亲委派，主要用于隔离Sermant各服务治理插件，避免不同服务治理插件之间产生类冲突问题。
• ServiceClassLoader，破坏双亲委派，主要用于隔离插件中的依赖，通过该类加载器加载插件服务的相关lib（插件服务会在插件加载时被Sermant初始化），开发者可任意引入三方依赖，无需关心对插件主逻辑的影响。

其中的PluginClassloader和ServiceClassloader不仅在类隔离中起到至关重要的作用，更是一种长远的考虑，为每个插件设计独立的类加载器，使得Sermant可以平滑的进行插件动态安装&卸载以及插件热更新。

2) 插件隔离的特殊之处

在上文中所述类隔离架构中，可以看到一处特别的逻辑（红框处），这也是Sermant中PluginClassLoader（插件类加载器）的特殊之处，在实际使用过程中，每个插件类加载器会在其中为每个线程