聊聊Dubbo - Dubbo可扩展机制源码解析

摘要： 在Dubbo可扩展机制实战中，咱们了解了Dubbo扩展机制的一些概念，初探了Dubbo中LoadBalance的实现，并本身实现了一个LoadBalance。是否是以为Dubbo的扩展机制很不错呀，接下来，咱们就深刻Dubbo的源码，一睹庐山真面目。

在Dubbo可扩展机制实战中，咱们了解了Dubbo扩展机制的一些概念，初探了Dubbo中LoadBalance的实现，并本身实现了一个LoadBalance。是否是以为Dubbo的扩展机制很不错呀，接下来，咱们就深刻Dubbo的源码，一睹庐山真面目。

ExtensionLoader

ExtentionLoader是最核心的类，负责扩展点的加载和生命周期管理。咱们就以这个类开始吧。
Extension的方法比较多，比较经常使用的方法有:

• public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type)
• public T getExtension(String name)
• public T getAdaptiveExtension()

比较常见的用法有:

• LoadBalance lb = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(loadbalanceName)
• RouterFactory routerFactory = ExtensionLoader.getExtensionLoader(RouterFactory.class).getAdaptiveExtension()

说明：在接下来展现的源码中，我会将无关的代码(好比日志，异常捕获等)去掉，方便你们阅读和理解。

*1. getExtensionLoader方法
这是一个静态工厂方法，入参是一个可扩展的接口，返回一个该接口的ExtensionLoader实体类。经过这个实体类，能够根据name得到具体的扩展，也能够得到一个自适应扩展。

*2. getExtension方法

getExtention方法中作了一些判断和缓存，主要的逻辑在createExtension方法中。咱们继续看createExtention方法。

createExtension方法作了如下事情:
*1. 先根据name来获得对应的扩展类。从ClassPath下META-INF文件夹下读取扩展点配置文件。

*2. 使用反射建立一个扩展类的实例

*3. 对扩展类实例的属性进行依赖注入，即IoC。

*4. 若是有wrapper，添加wrapper，即AoP。

下面咱们来重点看下这4个过程
*1. 根据name获取对应的扩展类
先看代码:

过程很简单，先从缓存中获取，若是没有，就从配置文件中加载。配置文件的路径就是以前提到的:

• META-INF/dubbo/internal
• META-INF/dubbo
• META-INF/services

*2. 使用反射建立扩展实例
这个过程很简单，使用clazz.newInstance())来完成。建立的扩展实例的属性都是空值。

*3. 扩展实例自动装配
在实际的场景中，类之间都是有依赖的。扩展实例中也会引用一些依赖，好比简单的Java类，另外一个Dubbo的扩展或一个Spring Bean等。依赖的状况很复杂，Dubbo的处理也相对复杂些。咱们稍后会有专门的章节对其进行说明，如今，咱们只须要知道，Dubbo能够正确的注入扩展点中的普通依赖，Dubbo扩展依赖或Spring依赖等。

*4. 扩展实例自动包装
自动包装就是要实现相似于Spring的AOP功能。Dubbo利用它在内部实现一些通用的功能，好比日志，监控等。关于扩展实例自动包装的内容，也会在后面单独讲解。

通过上面的4步，Dubbo就建立并初始化了一个扩展实例。这个实例的依赖被注入了，也根据须要被包装了。到此为止，这个扩展实例就能够被使用了。

Dubbo SPI高级用法之自动装配

自动装配的相关代码在injectExtension方法中:

要实现对扩展实例的依赖的自动装配，首先须要知道有哪些依赖，这些依赖的类型是什么。Dubbo的方案是查找Java标准的setter方法。即方法名以set开始，只有一个参数。若是扩展类中有这样的set方法，Dubbo会对其进行依赖注入，相似于Spring的set方法注入。
可是Dubbo中的依赖注入比Spring要复杂，由于Spring注入的都是Spring bean，都是由Spring容器来管理的。而Dubbo的依赖注入中，须要注入的多是另外一个Dubbo的扩展，也多是一个Spring Bean，或是Google guice的组件，或其余任何一个框架中的组件。Dubbo须要可以从任何一个场景中加载扩展。在injectExtension方法中，是用Object object = objectFactory.getExtension(pt, property)来实现的。objectFactory是ExtensionFactory类型的，在建立ExtensionLoader时被初始化:

objectFacory自己也是一个扩展，经过ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension())来获取。

ExtensionLoader有三个实现：
*1. SpiExtensionLoader：Dubbo本身的Spi去加载Extension

*2. SpringExtensionLoader：从Spring容器中去加载Extension

*3. AdaptiveExtensionLoader: 自适应的AdaptiveExtensionLoader

这里要注意AdaptiveExtensionLoader，源码以下:

AdaptiveExtensionLoader类有@Adaptive注解。前面提到了，Dubbo会为每个扩展建立一个自适应实例。若是扩展类上有@Adaptive，会使用该类做为自适应类。若是没有，Dubbo会为咱们建立一个。因此ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension())会返回一个AdaptiveExtensionLoader实例，做为自适应扩展实例。
AdaptiveExtentionLoader会遍历全部的ExtensionFactory实现，尝试着去加载扩展。若是找到了，返回。若是没有，在下一个ExtensionFactory中继续找。Dubbo内置了两个ExtensionFactory，分别从Dubbo自身的扩展机制和Spring容器中去寻找。因为ExtensionFactory自己也是一个扩展点，咱们能够实现本身的ExtensionFactory，让Dubbo的自动装配支持咱们自定义的组件。好比，咱们在项目中使用了Google的guice这个IoC容器。咱们能够实现本身的GuiceExtensionFactory，让Dubbo支持从guice容器中加载扩展。

Dubbo SPI高级用法之AoP

在用Spring的时候，咱们常常会用到AOP功能。在目标类的方法先后插入其余逻辑。好比一般使用Spring AOP来实现日志，监控和鉴权等功能。
Dubbo的扩展机制，是否也支持相似的功能呢？答案是yes。在Dubbo中，有一种特殊的类，被称为Wrapper类。经过装饰者模式，使用包装类包装原始的扩展点实例。在原始扩展点实现先后插入其余逻辑，实现AOP功能。

什么是Wrapper类

那什么样类的才是Dubbo扩展机制中的Wrapper类呢？Wrapper类是一个有复制构造函数的类，也是典型的装饰者模式。下面就是一个Wrapper类:

类A有一个构造函数

public A(A a)

，构造函数的参数是A自己。这样的类就能够成为Dubbo扩展机制中的一个Wrapper类。Dubbo中这样的Wrapper类有ProtocolFilterWrapper, ProtocolListenerWrapper等, 你们能够查看源码加深理解。

怎么配置Wrapper类

在Dubbo中Wrapper类也是一个扩展点，和其余的扩展点同样，也是在META-INF文件夹中配置的。好比前面举例的ProtocolFilterWrapper和ProtocolListenerWrapper就是在路径dubbo-rpc/dubbo-rpc-api/src/main/resources/META-INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol中配置的:

在Dubbo加载扩展配置文件时，有一段以下的代码:

这段代码的意思是，若是扩展类有复制构造函数，就把该类存起来，供之后使用。有复制构造函数的类就是Wrapper类。经过clazz.getConstructor(type)来获取参数是扩展点接口的构造函数。注意构造函数的参数类型是扩展点接口，而不是扩展类。
以Protocol为例。配置文件dubbo-rpc/dubbo-rpc-api/src/main/resources/META-INF/dubbo/internal/com.alibaba.dubbo.rpc.Protocol中定义了filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper。
ProtocolFilterWrapper代码以下：

ProtocolFilterWrapper有一个构造函数public ProtocolFilterWrapper(Protocol protocol)，参数是扩展点Protocol，因此它是一个Dubbo扩展机制中的Wrapper类。ExtensionLoader会把它缓存起来，供之后建立Extension实例的时候，使用这些包装类依次包装原始扩展点。

扩展点自适应

前面讲到过，Dubbo须要在运行时根据方法参数来决定该使用哪一个扩展，因此有了扩展点自适应实例。实际上是一个扩展点的代理，将扩展的选择从Dubbo启动时，延迟到RPC调用时。Dubbo中每个扩展点都有一个自适应类，若是没有显式提供，Dubbo会自动为咱们建立一个，默认使用Javaassist。
先来看下建立自适应扩展类的代码:

继续看createAdaptiveExtension方法

继续看getAdaptiveExtensionClass方法

继续看createAdaptiveExtensionClass方法，绕了一大圈，终于来到了具体的实现了。看这个createAdaptiveExtensionClass方法，它首先会生成自适应类的Java源码，而后再将源码编译成Java的字节码，加载到JVM中。

Compiler的代码，默认实现是javassist。

createAdaptiveExtensionClassCode()方法中使用一个StringBuilder来构建自适应类的Java源码。方法实现比较长，这里就不贴代码了。这种生成字节码的方式也挺有意思的，先生成Java源代码，而后编译，加载到jvm中。经过这种方式，能够更好的控制生成的Java类。并且这样也不用care各个字节码生成框架的api等。由于xxx.java文件是Java通用的，也是咱们最熟悉的。只是代码的可读性不强，须要一点一点构建xx.java的内容。
下面是使用createAdaptiveExtensionClassCode方法为Protocol建立的自适应类的Java代码范例:

大体的逻辑和开始说的同样，经过url解析出参数，解析的逻辑由@Adaptive的value参数控制，而后再根据获得的扩展点名获取扩展点实现，而后进行调用。若是你们想知道具体的构建.java代码的逻辑，能够看createAdaptiveExtensionClassCode的完整实现。
在生成的Protocol$Adpative中，发现getDefaultPort和destroy方法都是直接抛出异常的，这是为何呢？来看看Protocol的源码：

能够看到Protocol接口中有4个方法，但只有export和refer两个方法使用了@Adaptive注解。Dubbo自动生成的自适应实例，只有@Adaptive修饰的方法才有具体的实现。因此，Protocol$Adpative类中，也只有export和refer这两个方法有具体的实现，其他方法都是抛出异常。

原文连接