Dubbo源码分析（三）Dubbo中的SPI和自适应扩展机制

前言

我们在往期文章中，曾经深入分析过Java的SPI机制，它是一种服务发现机制。具体详见：深入理解JDK的SPI机制

在继续深入Dubbo之前，我们必须先要明白Dubbo中的SPI机制。因为有位大神（佚名）曾这样说过：

要想理解Dubbo，必须要先搞明白Dubbo SPI机制，不然会非常晕。

一、背景

1、来源

Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。但还有所不同，它改进了JDK标准的 SPI的以下问题：

• JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。

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

• 增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。

2、约定

在扩展类的 jar 包内，放置扩展点配置文件 META-INF/dubbo/接口全限定名，内容为：配置名=扩展实现类全限定名，多个实现类用换行符分隔。

3、配置文件

Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，几乎所有的功能都有扩展点实现。

Dubbo扩展点配置文件

我们以Protocol接口为例，它里面有很多实现。

Protocol接口实现

二、Dubbo SPI

通过上图我们可以看到，Dubbo SPI和JDK SPI配置的不同，在Dubbo SPI中可以通过键值对的方式进行配置，这样就可以按需加载指定的实现类。
Dubbo SPI的相关逻辑都被封装到ExtensionLoader类中，通过ExtensionLoader我们可以加载指定的实现类，一个扩展接口就对应一个ExtensionLoader对象，在这里我们把它亲切的称为：扩展点加载器。

我们先看下它的属性：

public class ExtensionLoader {
    
    //扩展点配置文件的路径，可以从3个地方加载到扩展点配置文件
    private static final String SERVICES_DIRECTORY = "META-INF/services/";
    private static final String DUBBO_DIRECTORY = "META-INF/dubbo/";
    private static final String DUBBO_INTERNAL_DIRECTORY = DUBBO_DIRECTORY + "internal/";   
    //扩展点加载器的集合
    private static final ConcurrentMap, ExtensionLoader> EXTENSION_LOADERS = new ConcurrentHashMap, ExtensionLoader>();
    //扩展点实现的集合
    private static final ConcurrentMap, Object> EXTENSION_INSTANCES = new ConcurrentHashMap, Object>();
    //扩展点名称和实现的映射缓存
    private final ConcurrentMap, String> cachedNames = new ConcurrentHashMap, String>();
    //拓展点实现类集合缓存
    private final Holder>> cachedClasses = new Holder>>();
    //扩展点名称和@Activate的映射缓存
    private final Map cachedActivates = new ConcurrentHashMap();
    //扩展点实现的缓存
    private final ConcurrentMap> cachedInstances = new ConcurrentHashMap>();
}

ExtensionLoader会把不同的扩展点配置和实现都缓存起来。同时，Dubbo在官网上也给了我们提醒：扩展点使用单一实例加载（请确保扩展实现的线程安全性），缓存在 ExtensionLoader中。下面我们看几个重点方法。

1、获取扩展点加载器

我们首先通过ExtensionLoader.getExtensionLoader() 方法获取一个 ExtensionLoader 实例，它就是扩展点加载器。然后再通过 ExtensionLoader 的 getExtension 方法获取拓展类对象。这其中，getExtensionLoader 方法用于从缓存中获取与拓展类对应的 ExtensionLoader，若缓存未命中，则创建一个新的实例。

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 loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
    if (loader == null) {
        EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader(type));
        loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
    }
    return loader;
}

比如你可以通过下面这样，来获取Protocol接口的ExtensionLoader实例：
ExtensionLoader extensionLoader = ExtensionLoader.getExtensionLoader(Protocol.class);
就可以拿到扩展点加载器的对象实例：
com.alibaba.dubbo.common.extension.ExtensionLoader[com.alibaba.dubbo.rpc.Protocol]

2、获取扩展类对象

上一步我们已经拿到加载器，然后可以根据加载器实例，通过扩展点的名称获取扩展类对象。

public T getExtension(String name) {
    //校验扩展点名称的合法性
    if (name == null || name.length() == 0)
        throw new IllegalArgumentException("Extension name == null");
    // 获取默认的拓展实现类
    if ("true".equals(name)) {
        return getDefaultExtension();
    }
    //用于持有目标对象
    Holder