Dubbo 源码分析之 SPI 详解

Dubbo 源码分析之 SPI 详解

前言

不得不说 ​​Dubbo​​​的自定义 ​​spi​​ 减轻了扩展者的负担，但减轻负担的代价是使用大量晦涩难懂的代码，调用层次深，使阅读者步步维艰。为了避免后来者再像我当初那样看源码的吃力，特意把我的阅读见解分享下来，希望大家一起学习。

我使用的是 ​​maven​​​ 仓库最新的 ​​dubbo2.6.5​​​ 的源码，在社区看到要 ​​2.7​​ 版本就要出了。为了更方便的学习，我们可以等这个版本掌握差不多了再看更高的版本。

SPI

究竟什么是 ​​SPI​​​ 呢，​​SPI​​​ 的英文名为 ​​Service Provider Interface​​​ 顾名思义服务提供者接口，是面向开发者的。使用 ​​SPI​​​ 我们可以把接口实现的全限定名放在文件中，通常在 ​​META-INF/services​​​ 目录下，文件名为接口名，文件内容为接口的实现类。由服务器加载读取配置文件，加载实现类，这样在运行时动态为接口替换实现类。正因此特性，我们可以很容易的通过 ​​SPI​​ 机制为我们的程序提供拓展功能。

其实 ​​JDK​​​ 自带了 ​​SPI​​ 功能。

JDK SPI

接口及其实现类

public interface Echo { void echo();}

public class DubboEcho implements Echo { @Override public void echo() { System.out.println("I am dubbo"); }}

public class JdkEcho implements Echo { @Override public void echo() { System.out.println("I am jdk"); }}

资源文件目录为：​​META-INF/services/接口全限定名​​​ 比如我的：​​META-INF/services/com.dfire.spi.Echo​​

com.dfire.spi.DubboEchocom.dfire.spi.JdkEcho

测试类：

public class App { public static void main(String[] args) { ServiceLoader says = ServiceLoader.load(Echo.class); for (Echo echo : says) { echo.echo(); } }}

执行后输出结果为

I am dubboI am jdk

目录结构如下

完成这个例子，大家就能简单了解了 ​​JDK SPI​​​ 。如果想要新增接口只需写个实现类配置在文件中即可。那么 ​​Dubbo​​​ 为什么没有使用​​JDK SPI​​​而使用了自定义​​SPI​​呢？

首先说我们能看到的缺点

一次性实例化所有的扩展点实现，即使该实现类没有用上，浪费资源

看不到的缺点

如果扩展点加载失败，连扩展点的名称都拿不到了。比如：​​JDK​​​ 标准的​​ScriptEngine​​​ ，通过​​getName​​​ 获取脚本类型的名称，但如果​​RubyScriptEngine​​​ 因为所依赖的​​jruby.jar​​​ 不存在，导致​​RubyScriptEngine​​​ 类加载失败，这个失败原因被吃掉了，和​​ruby​​​ 对应不起来，当用户执行​​ruby​​​ 脚本时，会报不支持​​ruby​​，而不是真正失败的原因。

Dubbo SPI

​​Dubbo SPI​​​除了修复 ​​JDK SPI​​​ 的缺点外还增加了​​AOP​​​和​​IOC​​功能。

在提供者的入口类 ​​ServiceConfig​​ 中有这样一行代码

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

其中 ​​ExtensionLoader​​​ 类即是 ​​Dubbo SPI​​​ 的实现类。 我们就从这行代码逐步分析。

public static ExtensionLoader getExtensionLoader(Class type) { if (type == null) throw new IllegalArgumentException("Extension type == null"); if(!type.isInterface()) { throw new IllegalArgumentException("Extension type(" + type + ") is not interface!"); } if(!withExtensionAnnotation(type)) { throw new IllegalArgumentException("Extension type(" + type + ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!"); } //根据接口在缓存中获得ExtensionLoader对象 ExtensionLoader loader = (ExtensionLoader) EXTENSION_LOADERS.get(type); if (loader == null) { //创建ExtensionLoader对象 EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader(type)); loader = (ExtensionLoader) EXTENSION_LOADERS.get(type); } return loader; }

在前两行首先是进行判空和该类是否为接口继续从缓存中根据接口类型来获得​​ExtensionLoader​​ 对象，如果为空就创建进入​​ExtensionLoader​​ 构造方法

private ExtensionLoader(Class type) { this.type = type; objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension()); }

哇，好复杂。 简单分析下 首先判断 ​​​type​​​ 是否为 ​​ExtensionFactory​​​类，如果是那么 ​​objectFactory​​​ 就为​​null​​​。如果不是就获得 ​​ExtensionFactory​​​ 的​​自适应扩展类​​​。​​ExtensionLoader.getExtensionLoader(T.class).getAdaptiveExtension()​​​ 这行代码其实就是我们刚刚进入分析的入口。下面继续分析 ​​getAdaptiveExtension​​ 方法。

获得所有的扩展类

public T getAdaptiveExtension() { //检测缓存中是否存在自适应扩展类实现 Object instance = cachedAdaptiveInstance.get(); //double check if (instance == null) { if(createAdaptiveInstanceError == null) { synchronized (cachedAdaptiveInstance) { instance = cachedAdaptiveInstance.get(); if (instance == null) { try { //新建 instance = createAdaptiveExtension(); //设置缓存 cachedAdaptiveInstance.set(instance); } catch (Throwable t) { createAdaptiveInstanceError = t; throw new IllegalStateException("fail to create adaptive instance: " + t.toString(), t); } } } } else { throw new IllegalStateException("fail to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError); } } return (T) instance; }

此方法，主要是为了获得自适应扩展类。首先从缓存的 ​​cachedAdaptiveInstance​​ 中检测是否已经存在。

private final Holder