ExtensionLoader 的工作原理
ExtensionLoader是整个扩展机制的主要逻辑类,在这个类里面实现了配置的加载、扩展类缓存、自适应对象生成等所有工作。本节将结合核心源码讲解整个ExtensionLoader的工作流程。
工作流程
ExtensionLoader 的逻辑入口可以分为 getExtension、getAdaptiveExtension、getActivateExtension三个,分别是获取普通扩展类、获取自适应扩展类、获取自动激活的扩展类。总体逻辑都是从调用这三个方法开始的,每个方法可能会有不同的重载的方法,根据不同的传入参数进行调整,如图4-1所示。
三个入口中,getActivateExtension对getExtension 的依赖比较getAdaptiveExtension则相对独立。
由4.2.3节可以知道,getActivateExtension方法只是根据不同的条件同时激活多个普通扩展类。因此,该方法中只会做一些通用的判断逻辑,如接口是否包含©Activate注解、匹配条件是否符合等。最终还是通过调用getExtension方法获得具体扩展点实现类。
getExtension (String name)是整个扩展加载器中最核心的方法,实现了一个完整的普通扩展类加载过程。加载过程中的每一步,都会先检查缓存中是否已经存在所需的数据,如果存在则直接从缓存中读取,没有则重新加载。这个方法每次只会根据名称返回一个扩展点实现类。
初始化的过程可以分为4步:
(1)框架读取SPI对应路径下的配置文件,并根据配置加载所有扩展类并缓存(不初始化)。
(2) 根据传入的名称初始化对应的扩展类。
(3) 尝试查找符合条件的包装类:包含扩展点的setter方法,例如setProtocol(Protocolprotocol)方法会自动注入protocol扩展点实现;包含与扩展点类型相同的构造函数,为其注入扩展类实例,例如本次初始化了一个Class A,初始化完成后,会寻找构造参数中需要Class A的包装类(Wrapper),然后注入Class A实例,并初始化这个包装类。
(4) 返回对应的扩展类实例。
getAdaptiveExtension也相对独立,只有加载配置信息部分与getExtension共用了同一个方法。和获取普通扩展类一样,框架会先检查缓存中是否有已经初始化化好的Adaptive实例,
没有则调用createAdaptiveExtension重新初始化。初始化过程分为4步:
(1) 和getExtension 一样先加载配置文件。
(2) 生成自适应类的代码字符串。
(3) 获取类加载器和编译器,并用编译器编译刚才生成的代码字符串。Dubbo 一共有三种类型的编译器实现,这些内容会在4.4节讲解。
(4) 返回对应的自适应类实例。
接下来,我们就详细讲舟军 getExtension、getAdaptiveExtension> getActivateExtension 这三个流程的实现。
getExtension 的实现原理
getExtension的主要流程前面已经讲过了,本节主要会讲解每一步的实现原理。
当调用getExtension(String name)方法时,会先检查缓存中是否有现成的数据,没有则调用createExtension开始创建。这里有个特殊点,如果getExtension传入的name是true,则加载并返回默认扩展类。
在调用createExtension开始创建的过程中,也会先检查缓存中是否有配置信息,如果不存在扩展类,则会从 META-INF/services/> META-INF/dubbo/、META-INF/dubbo/internal/这几个路径中读取所有的配置文件,通过I/O读取字符流,然后通过解析字符串,得到配置文件中对应的扩展点实现类的全称(如
com.alibaba.dubbo.common.extensionloader.activate.impl.GroupActivateExtImpl)o扩展点配置信息加载过程的源码如代码清单4-10所示。
加载完扩展点配置后,再通过反射获得所有扩展实现类并缓存起来。注意,此处仅仅是把Class加载到JVM中,但并没有做Class初始化。在加载Class文件时,会根据Class上的注解来判断扩展点类型,再根据类型分类做缓存。缓存的分类已经在4.1.4节讲过。扩展类的缓存分类如代码清单4-11所示。
最后,根据传入的name找到对应的类并通过Class.forName方法进行初始化,并为其注入依赖的其他扩展类(自动加载特性)。当扩展类初始化后,会检查一次包装扩展类Set<Class<?»wrapperclasses,查找包含与扩展点类型相同的构造函数,为其注入刚初始化的扩展类,如代码清单4-12所示。
代码清单4・12依赖注入
injectExtension(instance); <一 向扩展类注入其依赖的属性,如扩展类A又依赖了扩展类B
Set<Class<?>> wrapperclasses = cachedWrapperClasses;
if (wrapperclasses != null && !wrapperclasses.isEmpty()) {
for (Class<?> wrapperclass : wrapperclasses) { 遍历扩展点包装类,用于初始化包装类实例
instance = injectExtension((T) wrapperclass.getConstructor(type).
newlnstance(instance));找到构造方法参数类型为type (扩展类的类型)的包装类,为1其注入扩展类实例
}
)
在injectExtension方法中可以为类注入依赖属性,它使用了 ExtensionFactory#getExtension(Class<T> type, String name)来获取对应的bean实例,这个工厂接口会在4.3.5节详细说明。
我们先来了解一下注入的实现原理。
injectExtension方法总体实现了类似Spring的IoC机制,其实现原理比较简单:首先通过反射获取类的所有方法,然后遍历以字符串set开头的方法,得到set方法的参数类型,再通过ExtensionFactory寻找参数类型相同的扩展类实例,如果找到,就设值进去,如代码清单4-13所示。
代码清单4-13注入依赖扩展类实现代码
从源码中可以知道,包装类的构造参数注入也是通过injectExtension方法实现的。
getAdaptiveExtension 的实现原理
由之前的流程我们可以知道,在getAdaptiveExtension()方法中,会为扩展点接口自动生成实现类字符串,实现类主要包含以下逻辑:为接口中每个有^Adaptive注解的方法生成默认实现(没有注解的方法则生成空实现),每个默认实现都会从URL中提取Adaptive参数值,并以此为依据动态加载扩展点。然后,框架会使用不同的编译器,把实现类字符串编译为自适应类并返回。本节主要讲解字符串代码生成的实现原理。
生成代码的逻辑主要分为7步,具体步骤如下:
(1) 生成package> import、类名称等头部信息。此处只会引入一个类ExtensionLoader。
为了不写其他类的import方法,其他方法调用时全部使用全路径。类名称会变为“接口名称+SAdaptive ” 的格式。例如:Transporter 接口 会生成 Transporter$Adpative。
(2) 遍历接口所有方法,获取方法的返回类型、参数类型、异常类型等。为第(3)步判断是否为空值做准备。
(3)生成参数为空校验代码,如参数是否为空的校验。如果有远程调用,还会添加Invocation参数为空的校验。
(4) 生成默认实现类名称。如果©Adaptive注解中没有设定默认值,则根据类名称生成,如YyylnvokerWrapper会被转换为yyy.invoker.wrappero生成的规则是不断找大写字母,并把它们用连接起来。得到默认实现类名称后,还需要知道这个实现是哪个扩展点的。
(5) 生成获取扩展点名称的代码。根据@Adaptive注解中配置的key值生成不同的获取代码,例如:如果是@Adaptive(nprotocoln),则会生成 ur1. getProtocol() 。
(6) 生成获取具体扩展实现类代码。最终还是通过getExtension(extName)方法获取自适应扩展类的真正实现。如果根据URL中配置的key没有找到对应的实现类,则会使用第(4)步中生成的默认实现类名称去找。
(7) 生成调用结果代码。
下面我们用Dubb。源码中自带的一个单元测试来演示代码生成过程,如代码清单4-14所示。
生成完代码之后就要对代码进行编译,生成一个新的Classo Dubbo中的编译器也是一个自适应接口,但@Adaptive注解是加在实现类AdaptiveCompiler上的。这样一来AdaptiveCompiler就会作为该自适应类的默认实现,不需要再做代码生成和编译就可以使用了。具体的编译器实现原理会在4.4节讲解。
如果一个接口上既有@SPI(”impl”)注解,方法上又有@Adaptive(”impl2”)注解,那么会以哪个key作为默认实现呢?由上面动态生成的SAdaptive类可以得知,最终动态生成的实现方法会是url.getParameter(nimpl2n, "impl”),即优先通过©Adaptive注解传入的key去查找扩展实现类;
如果没找到,则通过@SPI注解中的key去查找;如果@SPI注解中没有默认值,则把类名转化为key,再去查找。
getActivateExtension 的实现原理
接下来,我们讲解图4-1中的旧Activate的实现原理,先从它的入口方法说起。
getActivateExtension(URL url. String key. String group)方法可以获取所有自动激活扩展点。参数分别是URL.URL中指定的key(多个则用逗号隔开)和URL中指定的组信息(group)。
其实现逻辑非常简单,当调用该方法时,主线流程分为4步:
(1) 检查缓存,如果缓存中没有,则初始化所有扩展类实现的集合。
(2) 遍历整个©Activate注解集合,根据传入URL匹配条件(匹配group> name等),得到所有符合激活条件的扩展类实现。然后根据@入"浦3七。中配置的before、after、order等参数进行排序,这些参数在4.2.3节中已经介绍过。
(3) 遍历所有用户自定义扩展类名称,根据用户URL配置的顺序,调整扩展点激活顺序(遵循用户在 URL 中配置的顺序,例如 URL 为 test ://localhost/test?ext=orderlJdefault,则扩展点ext的激活顺序会遵循先orderl再default,其中default代表所有有@Activate注解的扩展点)。
(4) 返回所有自动激活类集合。
获取Activate扩展类实现,也是通过getExtension得到的。因此,可以认为getExtension是其他两种Extension的基石。
此处有一点需要注意,如果URL的参数中传入了-default,则所有的默认@Activate都不会被激活,只有URL参数中指定的扩展点会被激活。如果传入了符号开头的扩展点名,
则该扩展点也不会被自动激活。例如:-xxxx,表示名字为xxxx的扩展点不会被激活。
ExtensionFactory 的实现原理
经过前面的介绍,我们可以知道ExtensionLoader类是整个SPI的核心。但是,ExtensionLoader类本身又是如何被创建的呢?
我们知道RegistryFactory工厂类通ii@Adaptive(("protocol"})注解动态查找注册中心实现,根据URL中的protocol参数动态选择对应的注册中心工厂,并初始化具体的注册中心客户端。而实现这个特性的ExtensionLoader类,本身又是通过工厂方法ExtensionFactory创建的,并且这个工厂接口上也有SPI注解,还有多个实现。具体见代码清单4-15。
代码清单4-15 ExtensionFactory工厂接口
@SPI
public interface ExtensionFactory {
<T> T getExtension(Class<T> type. String name);
既然工厂接口有多个实现,那么是怎么确定使用哪个工厂实现的呢?我们可以看到AdaptiveExtensionFactory 这个实现类工厂上W@Adaptive 注解。因此,AdaptiveExtensionFactory会作为一开始的默认实现。工厂类之间的关系如图4.2所示。
可以看到,除了 AdaptiveExtensionFactory,还有 SpiExtensionFactory 和 SpringExtensionFactory两个工厂。也就是说,我们除了可以从Dubbo SPI管理的容器中获取扩展点实例,还可以从Spring容器中获取。
那么Dubbo和Spring容器之间是如何打通的呢?我们先来看SpringExtensionFactory的实现,该工厂提供了保存Spring上下文的静态方法,可以把Spring上下文保存到Set集合中。
当调用getExtension获取扩展类时,会遍历Set集合中所有的Spring上下文,先根据名字依次从每个Spring容器中进行匹配,如果根据名字没匹配到,则根据类型去匹配,如果还没匹配到则返回null,如代码清单4-16所示。
那么Spring的上下文又是在什么时候被保存起来的呢?我们可以通过代码搜索得知,在ReferenceBean和ServiceBean中会调用静态方法保存Spring上下文,即一个服务被发布或被引用的时候,对应的Spring ±下文会被保存下来。
我们再看一下SpiExtensionFactory,主要就是获取扩展点接口对应的Adaptive实现类。例如:某个扩展点实现类 ClassA 上有@Adaptive 注解,则调用 SpiExtensionFactory#getExtension会直接返回ClassA实例,如代码清单4-17所示。
经过一番流转,最终还是回到了默认实现AdaptiveExtensionFactory上.,因为该工厂上有©Adaptive注解。这个默认工厂在构造方法中就获取了所有扩展类工厂并缓存起来,包括SpiExtensionFactory 和 SpringExtensionFactory0 AdaptiveExtensionFactory 构造方法如代码清单4-18所示。
被AdaptiveExtensionFactory缓存的工厂会通过TreeSet进行排序,SPI排在前面,Spring排在后面。当调用getExtension方法时,会遍历所有的工厂,先从SPI容器中获取扩展类;如果没找到,则再从Spring容器中查找。我们可以理解为,AdaptiveExtensionFactory持有了所有的具体工厂实现,它的getExtension方法中只是遍历了它持有的所有工厂,最终还是调用SPI或Spring工厂实现的getExtension方法。getExtension方法如代码清单4-19所示。
扩展点动态编译的实现
Dubbo SPI的自适应特性让整个框架非常灵活,而动态编译又是自适应特性的基础,因为动态生成的自适应类只是字符串,需要通过编译才能得到真正的Class0虽然我们可以使用反射来动态代理一个类,但是在性能上和直接编译好的Class会有一定的差距。Dubbo SPI通过代码的动态生成,并配合动态编译器,灵活地在原始类基础上创建新的自适应类。本节将介绍DubboSPI动态编译器的种类及对应的现实原理。
总体结构
Dubbo中有三种代码编译器,分别是JDK编译器、Javassist编译器和AdaptiveCompiler编译器。这几种编译器都实现了 Compiler接口,编译器类之间的关系如图4.3所示。
从图4-3中可以看®J,Compiler接口上含有一个SPI注解,注解的默认值是@SPI(”javassist”),很明显,Javassist编译器将作为默认编译器。如果用户想改变默认编译器,则可以通过<dubbo:application compiler="jdk" />标签进行配置。
AdaptiveCompiler上面有^Adaptive注解,说明AdaptiveCompiler会固定为默认实现,这个Compiler的主要作用和AdaptiveExtensionFactory相似,就是为了管理其他Compiler,如代码清单4-20所示。
AdaptiveCompiler#setDefaultCompiler 方法会在 ApplicationConfig 中被调用,也就是 Dubbo在启动时,会解析配置中的<dubbo:application compiler="jdk" />标签,获取设置的值,初始化对应的编译器。如果没有标签设置,贝U使用@SPI(Hjavassistn)中的设置,即3avassistCompilero
然后看一下AbstpactCompiler,它是一个抽象类,无法实例化,但在里面封装了通用的模板逻辑。还定义了一个抽象方法decompile ,留给子类来实现具体的编译逻辑。
OavassistCompiler和DdkCompiler都实现了这个抽象方法。
Abstractcompiler的主要抽象逻辑如下:
(1) 通过正则匹配出包路径、类名,再根据包路径、类名拼接出全路径类名。
(2) 尝试通过Class.forName加载该类并返回,防止重复编译。如果类加载器中没有这个类,则进入第3步。
(3) 调用doCompile方法进行编译。这个抽象方法由子类实现。
下面将介绍两种编译器的具体实现。
Javassist动态代码编译
Java中动态生成Class的方式有很多,可以直接基于字节码的方式生成,常见的工具库有CGLIB、ASM> Javassist等。而自适应扩展点使用了生成字符串代码再编译为Class的方式。
在讲解Dubbo中Javassist动态代码编译之前,我们先看一个Javassist生成一个“Hello World”的例子,这样对理解后续实现原理很有帮助,如代码清单4.21所示。
看完Javassist使用示例,其实Dubbo中DavassistCompiler的实现原理也很清晰了。由于我们之前已经生成了代码字符串,因此在JavassistCompiler中,就是不断通过正则表达式匹配不同部位的代码,然后调用Javassist库中的API生成不同部位的代码,最后得到一个完整的Class对象。具体步骤如下:
(1) 初始化Javassist,设置默认参数,如设置当前的classpatho
(2) 通过正则匹配出所有import的包,并使用Javassist添加importo
(3) 通过正则匹配出所有extends的包,创建Class对象,并使用Javassist添加extendso
(4) 通过正则匹配出所有implements包,并使用Javassist添加implementso
(5) 通过正则匹配出类里面所有内容,即得到{}中的内容,再通过正则匹配出所有方法,并使用Javassist添加类方法。
(6) 生成Class对象。
JavassistCompiler继承了抽象类Abstractcompiler,需要实现父类定义的一个抽象方法doCompileo以上步骤就是整个doCompile方法在3avassistCompiler中的实现。
JDK动态代码编译
DdkCompiler是Dubbo编译器的另一种实现,使用了 JDK自带的编译器,原生JDK编译器包位于 javax. tools下。主要使用了三个东西:JavaFileObject 接口、ForwardingJavaFileManager 接口、
DavaCompiler.CompilationTask 方法。整个动态编译过程可以简单地总结为:首先初始化一个JavaFileObject对象,并把代码字符串作为参数传入构造方法,然后调用JavaCompiler.CompilationTask方法编译出具体的类。JavaFileManager负责管理类文件的输入/输出位置。以下是每个接口/方法的简要介绍:
(1) JavaFileObject接口。字符串代码会被包装成一个文件对象,并提供获取二进制流的接口。Dubbo框架中的JavaFileObjectlmpl类可以看作该接口一种扩展实现,构造方法中需要传入生成好的字符串代码,此文件对象的输入和输出都是ByteArray流。由于SimpleDavaFileObject> DavaFileObject之间的关系属于JDK中的知识,因此在本章不深入讲解,有兴趣的读者可以自行查看JDK源码。
(2) DavaFileManager接口。主要管理文件的读取和输出位置。JDK中没有可以直接使用的实现类,唯一的实现类ForwardingDavaFileManager构造器又是protect类型。因此Dubbo中定制化实现了一个DavaFileManagerlmpl类,并通过一个自定义类加载器ClassLoaderlmpl完成资源的加载。
(3)
DavaCompiler.CompilationTask 把 DavaFileObject 对象编译成具体的类。
小结
本章的内容比较多,首先介绍了 Dubbo SPI的一些概要信息,包括与JavaSPI的区别>DubboSPI的新特性、配置规范和内部缓存等。其次介绍了 Dubbo SPI中最重要的三个注解:@SPI、@Adaptive、@Activate,讲解了这几个注解的作用及实现原理。然后结合ExtensionLoader类的源码介绍了整个Dubbo SPI中最关键的三个入口: getExtension、getAdaptiveExtension>getActivateExtension,并讲解了创建 ExtensionLoader 的工厂(ExtensionFactory)的工作原理。最后还讲解了自适应机制中动态编译的实现原理。