第三节_ Dubbo的可扩展机制SPI源码解析

文章目录

• 第三节_ Dubbo的可扩展机制SPI源码解析
• 正文

• Dubbo SPI 架构图
• Demo
• ExtensionLoader
• getExtension(String name)⽅法
• createExtension(String name)⽅法
• getExtensionClasses
• loadResource⽅法
• loadClass⽅法
• Dubbo中的IOC
• Dubbo中的AOP
• ⾃适应扩展点补充
• createAdaptiveExtensionClass⽅法
• Activate扩展点
• demo

正文

Dubbo SPI 架构图

Demo

1 ExtensionLoader<Protocol> extensionLoader = ExtensionLoader.getExt
ensionLoader(Protocol.class);
2 Protocol http = extensionLoader.getExtension("dubbo");
3 System.out.println(http);

上⾯这个Demo就是Dubbo常⻅的写法，表示获取"dubbo"对应的Protocol扩展点。Protocol是⼀个接

⼝。

在ExtensionLoader类的内部有⼀个static的ConcurrentHashMap，⽤来缓存某个接⼝类型所对应的

ExtensionLoader实例

ExtensionLoader

ExtensionLoader表示某个接⼝的扩展点加载器，可以⽤来加载某个扩展点实例。

在ExtensionLoader中除开有上⽂的static的Map外，还有两个⾮常重要的属性：

1. Class<?> type：表示当前ExtensionLoader实例是哪个接⼝的扩展点加载器
2. ExtensionFactory objectFactory：扩展点⼯⼚（对象⼯⼚），可以获得某个对象
   ExtensionLoader和ExtensionFactory的区别在于：
3. ExtensionLoader最终所得到的对象是Dubbo SPI机制产⽣的
4. ExtensionFactory最终所得到的对象可能是Dubbo SPI机制所产⽣的，也可能是从Spring容器中所获
   得的对象
   在ExtensionLoader中有三个常⽤的⽅法：
5. getExtension(“dubbo”)：表示获取名字为dubbo的扩展点实例
6. getAdaptiveExtension()：表示获取⼀个⾃适应的扩展点实例
7. getActivateExtension(URL url, String[] values, String group)：表示⼀个可以被url激活的扩展点
   实例，后⽂详细解释
   其中，什么是⾃适应扩展点实例？它其实就是当前这个接⼝的⼀个代理对象。

1 ExtensionLoader<Protocol> extensionLoader = ExtensionLoader.getExt
ensionLoader(Protocol.class);
2 Protocol protocol = extensionLoader.getExtension("dubbo");

当我们调⽤上述代码，我们会将得到⼀个DubboProtocol的实例对象，但在getExtension()⽅法中，

Dubbo会对DubboProtocol对象进⾏依赖注⼊（也就是⾃动给属性赋值，属性的类型为⼀个接⼝，记为A接⼝），这个时候，对于Dubbo来说它并不知道该给这个属性赋什么值，换句话说，Dubbo并不知道在进⾏依赖注⼊时该找⼀个什么的的扩展点对象给这个属性，这时就会预先赋值⼀个A接⼝的⾃适应扩展点实例，也就是A接⼝的⼀个代理对象。

后续，在A接⼝的代理对象被真正⽤到时，才会结合URL信息找到真正的A接⼝对应的扩展点实例进⾏调⽤

getExtension(String name)⽅法

在调⽤getExtension去获取⼀个扩展点实例后，会对实例进⾏缓存，下次再获取同样名字的扩展点实例时就会从缓存中拿了。

createExtension(String name)⽅法

在调⽤createExtension(String name)⽅法去创建⼀个扩展点实例时，要经过以下⼏个步骤：

1. 根据name找到对应的扩展点实现类
2. 根据实现类⽣成⼀个实例，把实现类和对应⽣成的实例进⾏缓存
3. 对⽣成出来的实例进⾏依赖注⼊（给实例的属性进⾏赋值）
4. 对依赖注⼊后的实例进⾏AOP（Wrapper）,把当前接⼝类的所有的Wrapper全部⼀层⼀层包裹在实例
   对象上，没包裹个Wrapper后，也会对Wrapper对象进⾏依赖注⼊
5. 返回最终的Wrapper对象

getExtensionClasses

getExtensionClasses()是⽤来加载当前接⼝所有的扩展点实现类的，返回⼀个Map。之后可以从这个

Map中按照指定的name获取对应的扩展点实现类。

当把当前接⼝的所有扩展点实现类都加载出来后也会进⾏缓存，下次需要加载时直接拿缓存中的。

Dubbo在加载⼀个接⼝的扩展点时，思路是这样的：

1. 根据接⼝的全限定名去META-INF/dubbo/internal/⽬录下寻找对应的⽂件，调⽤loadResource⽅法
   进⾏加载
2. 根据接⼝的全限定名去META-INF/dubbo/⽬录下寻找对应的⽂件，调⽤loadResource⽅法进⾏加载
3. 根据接⼝的全限定名去META-INF/services/⽬录下寻找对应的⽂件，调⽤loadResource⽅法进⾏加
   载
   这⾥其实会设计到⽼版本兼容的逻辑，不解释了

loadResource⽅法

loadResource⽅法就是完成对⽂件内容的解析，按⾏进⾏解析，会解析出"=“两边的内容，”="左边的内容

就是扩展点的name，右边的内容就是扩展点实现类，并且会利⽤ExtensionLoader类的类加载器来加载扩

展点实现类。

然后调⽤loadClass⽅法对name和扩展点实例进⾏详细的解析，并且最终把他们放到Map中去。

loadClass⽅法

loadClass⽅法会做如下⼏件事情：

1. 当前扩展点实现类上是否存在@Adaptive注解，如果存在则把该类认为是当前接⼝的默认⾃适应类（接⼝代理类），并把该类存到cachedAdaptiveClass属性上。
2. 当前扩展点实现是否是⼀个当前接⼝的⼀个Wrapper类，如果判断的？就是看当前类中是否存在⼀个构造⽅法，该构造⽅法只有⼀个参数，参数类型为接⼝类型，如果存在这⼀的构造⽅法，那么这个类就是该接⼝的Wrapper类，如果是，则把该类添加到cachedWrapperClasses中去，
   cachedWrapperClasses是⼀个set。
3. 如果不是⾃适应类，或者也不是Wrapper类，则判断是有存在name，如果没有name，则报错。
4. 如果有多个name，则判断⼀下当前扩展点实现类上是否存在@Activate注解，如果存在，则把该类添加到cachedActivates中，cachedWrapperClasses是⼀个map。
5. 最后，遍历多个name，把每个name和对应的实现类存到extensionClasses中去，extensionClasses
   就是上⽂所提到的map。
   ⾄此，加载类就⾛完了。
   回到createExtension(String name)⽅法中的逻辑，当前这个接⼝的所有扩展点实现类都扫描完了之后，就可以根据⽤户所指定的名字，找到对应的实现类了，然后进⾏实例化，然后进⾏IOC(依赖注⼊)和AOP。

Dubbo中的IOC

1. 根据当前实例的类，找到这个类中的setter⽅法，进⾏依赖注⼊
2. 先分析出setter⽅法的参数类型pt
3. 在截取出setter⽅法所对应的属性名property
4. 调⽤objectFactory.getExtension(pt, property)得到⼀个对象，这⾥就会从Spring容器或通过
   DubboSpi机制得到⼀个对象，⽐较特殊的是，如果是通过DubboSpi机制得到的对象，是pt这个类型
   的⼀个⾃适应对象(代理对象)。
5. 再反射调⽤setter⽅法进⾏注⼊

Dubbo中的AOP

dubbo中也实现了⼀套⾮常简单的AOP，就是利⽤Wrapper，如果⼀个接⼝的扩展点中包含了多个

Wrapper类，那么在实例化完某个扩展点后，就会利⽤这些Wrapper类对这个实例进⾏包裹，⽐如：现在有⼀个DubboProtocol的实例，同时对于Protocol这个接⼝还有很多的Wrapper，⽐如

ProtocolFilterWrapper、ProtocolListenerWrapper，那么，当对DubboProtocol的实例完成了IOC之

后，就会先调⽤new ProtocolFilterWrapper(DubboProtocol实例)⽣成⼀个新的Protocol的实例，再对

此实例进⾏IOC，完了之后，会再调⽤new ProtocolListenerWrapper(ProtocolFilterWrapper实例)⽣成

⼀个新的Protocol的实例，然后进⾏IOC，从⽽完成DubboProtocol实例的AOP。

⾃适应扩展点补充

上⾯提到的⾃适应扩展点对象，也就是某个接⼝的代理对象是通过Dubbo内部⽣成代理类，然后⽣成代理

对象的。

额外的，在Dubbo中还设计另外⼀种机制来⽣成⾃适应扩展点，这种机制就是可以通过@Adaptive注解来

指定某个类为某个接⼝的代理类，如果指定了，Dubbo在⽣成⾃适应扩展点对象时实际上⽣成的就是

@Adaptive注解所注解的类的实例对象。

如果是由Dubbo默认实现的，那么我们就看看Dubbo是如何⽣成代理类的。

createAdaptiveExtensionClass⽅法

createAdaptiveExtensionClass⽅法就是Dubbo中默认⽣成Adaptive类实例的逻辑。说⽩了，这个实例

就是当前这个接⼝的⼀个代理对象。⽐如下⾯的代码：

1 ExtensionLoader<Protocol> extensionLoader = ExtensionLoader.getExt
ensionLoader(Protocol.class);
2 Protocol protocol = extensionLoader.getAdaptiveExtension();

这个代码就是Protocol接⼝的⼀个代理对象，那么代理逻辑就是在new

AdaptiveClassCodeGenerator(type, cachedDefaultName).generate()⽅法中。

1. type就是接⼝
2. cacheDefaultName就是该接⼝默认的扩展点实现的名字
   看个例⼦，Protocol接⼝的Adaptive类：

1 package org.apache.dubbo.rpc;
2 import org.apache.dubbo.common.extension.ExtensionLoader;
3 public class Protocol$Adaptive implements org.apache.dubbo.rpc.Pr
otocol {
4
5 public void destroy() {
6 throw new UnsupportedOperationException("The method publi
c abstract void org.apache.dubbo.rpc.Protocol.destroy() of interf
ace org.apache.dubbo.rpc.Protocol is not adaptive method!");
7 }
8
9 public int getDefaultPort() {
10 throw new UnsupportedOperationException("The method publi
c abstract int org.apache.dubbo.rpc.Protocol.getDefaultPort() of
interface org.apache.dubbo.rpc.Protocol is not adaptive method!"
);
11 }
12
13 public org.apache.dubbo.rpc.Exporter export(org.apache.dubbo.
rpc.Invoker arg0) throws org.apache.dubbo.rpc.RpcException {
14 if (arg0 == null)
15 throw new IllegalArgumentException("org.apache.dubbo.
rpc.Invoker argument == null");
16 if (arg0.getUrl() == null)
17 throw new IllegalArgumentException("org.apache.dubbo.
rpc.Invoker argument getUrl() == null");
18
19 org.apache.dubbo.common.URL url = arg0.getUrl();
20
21 String extName = ( url.getProtocol() == null ? "dubbo" :
url.getProtocol() );
22
23 if(extName == null)
24 throw new IllegalStateException("Failed to get extens
ion (org.apache.dubbo.rpc.Protocol) name from url (" + url.toStri
ng() + ") use keys([protocol])");
25
26 org.apache.dubbo.rpc.Protocol extension = (org.apache.dub
bo.rpc.Protocol)ExtensionLoader.getExtensionLoader(org.apache.dub
bo.rpc.Protocol.class).getExtension(extName);
27
28 return extension.export(arg0);
29 }
30
31 public org.apache.dubbo.rpc.Invoker refer(java.lang.Class arg
0, org.apache.dubbo.common.URL arg1) throws org.apache.dubbo.rpc.
RpcException {
32
33 if (arg1 == null) throw new IllegalArgumentException("url
== null");
34
35 org.apache.dubbo.common.URL url = arg1;
36
37 String extName = ( url.getProtocol() == null ? "dubbo" :
url.getProtocol() );
38
39 if(extName == null) throw new IllegalStateException("Fail
ed to get extension (org.apache.dubbo.rpc.Protocol) name from url
(" + url.toString() + ") use keys([protocol])");
40
41 org.apache.dubbo.rpc.Protocol extension = (org.apache.dub
bo.rpc.Protocol)ExtensionLoader.getExtensionLoader(org.apache.dub
bo.rpc.Protocol.class).getExtension(extName);
42
43 return extension.refer(arg0, arg1);
44 }
45 }

可以看到，Protocol接⼝中有四个⽅法，但是只有export和refer两个⽅法进⾏代理。为什么？因为

Protocol接⼝中在export⽅法和refer⽅法上加了@Adaptive注解。但是，不是只要在⽅法上加了

@Adaptive注解就可以进⾏代理，还有其他条件，⽐如：

1. 该⽅法如果是⽆参的，那么则会报错
2. 该⽅法有参数，可以有多个，并且其中某个参数类型是URL，那么则可以进⾏代理
3. 该⽅法有参数，可以有多个，但是没有URL类型的参数，那么则不能进⾏代理
4. 该⽅法有参数，可以有多个，没有URL类型的参数，但是如果这些参数类型，对应的类中存在getUrl⽅
   法（返回值类型为URL），那么也可以进⾏代理
   所以，可以发现，某个接⼝的Adaptive对象，在调⽤某个⽅法时，是通过该⽅法中的URL参数，通过调⽤
   ExtensionLoader.getExtensionLoader(com.luban.Car.class).getExtension(extName);得到⼀个扩展
   点实例，然后调⽤该实例对应的⽅法。

Activate扩展点

上⽂说到，每个扩展点都有⼀个name，通过这个name可以获得该name对应的扩展点实例，但是有的场景

下，希望⼀次性获得多个扩展点实例

demo

1 ExtensionLoader<Filter> extensionLoader = ExtensionLoader.getExte
nsionLoader(Filter.class);
2 URL url = new URL("http://", "localhost", 8080);
3 url = url.addParameter("cache", "test");
4
5 List<Filter> activateExtensions = extensionLoader.getActivateExte
nsion(url,
6 new String[
]{"validation"},
7 CommonConst
ants.CONSUMER);
8 for (Filter activateExtension : activateExtensions) {
9 System.out.println(activateExtension);
10 }

会找到5个Filter

1 org.apache.dubbo.rpc.filter.ConsumerContextFilter@4566e5bd
2 org.apache.dubbo.rpc.protocol.dubbo.filter.FutureFilter@1ed4004b
3 org.apache.dubbo.monitor.support.MonitorFilter@ff5b51f
4 org.apache.dubbo.cache.filter.CacheFilter@25bbe1b6
5 org.apache.dubbo.validation.filter.ValidationFilter@5702b3b1

前三个是通过CommonConstants.CONSUMER找到的

CacheFilter是通过url中的参数找到的

ValidationFilter是通过指定的name找到的

在⼀个扩展点类上，可以添加@Activate注解，这个注解的属性有：

1. String[] group()：表示这个扩展点是属于哪组的，这⾥组通常分为PROVIDER和CONSUMER，表示
   该扩展点能在服务提供者端，或者消费端使⽤
2. String[] value()：表示的是URL中的某个参数key，当利⽤getActivateExtension⽅法来寻找扩展点
   时，如果传⼊的url中包含的参数的所有key中，包括了当前扩展点中的value值，那么则表示当前url可
   以使⽤该扩展点。