前言

前面用了十几篇文章讲了Dubbo的基本原理和代码实现，基本的调用过程覆盖的差不多了。后续文章讲讲在面试中经常被问到的Dubbo原理。大部分Dubbo源码解读文章都把SPI的解析放在第一篇，而我之所以放在最后，主要是因为先讲框架使用时接触不到的原理性的东西很容易打断逻辑思路。
SPI是Dubbo扩展的基石，无论是框架本身实现还是用户想要对模块进行扩展，都是无法绕开的。
这篇文章就将Dubbo SPI的实现原理刨析清楚，以后用它来吊打面试官吧。

SPI原理

什么是SPI

SPI不是Dubbo发明的，Java中为了扩展性很早就引入了SPI机制，平常使用最多的就是JDBC了。Java中只是定义了Driver，Connection， Statement这些接口，而没有具体的实现类。这些具体的实现是由数据库开发方提供的，那就需要提供一种机制让Java在运行时能够找到具体的Driver实现。Java中定义了一个约定，就是接口实现方需要提供一个文件在META-INF\services下面，文件名是实现的接口名，比如java.sql.Driver，文件内容是接口的实现类比如com.mysql.jdbc.Driver。这样当我想要初始化一个Driver实例的时候只需要使用工具类ServiceLoader.load(Class)方法，就能加载到实现类了。SPI机制很好的将接口定义和实现做了隔离。

Dubbo SPI原理

为什么需要SPI

作为一个开源的框架，扩展性肯定是第一要考虑的东西。作为RPC框架，Dubbo需要对接注册中心、配置中心，同时还要支持多种通信协议，多种网络框架。这些组件都是第三方提供的，比如zookeeper，consul等。Dubbo通过抽象成统一的接口，对每个第三方组件做一下适配。但是总有人用的不是Dubbo提供的组件，比如用户使用自己实现的注册中心而不是Dubbo对接过的。所以，最好的办法是对于新的第三方组件，由用户自己适配。Dubbo对所有的适配同样对待，只管在运行期加载实现类。SPI就是为这种场景量身打造的。
Java SPI的问题
既然SPI是Java中自带的功能，是不是Dubbo直接用的就可以了？真要这样的话面试中就没什么好问的了。Java中的SPI有个问题，就是只能指定接口，而不能指定实现类。也就是说如果classpath中有多个接口的实现类，并且有多个相同的配置文件在META-INF\services下面，调用方是没办法在运行期知道某一次调用应该用哪一个实现类的。
那JDBC是怎么做到同一个进程中，不同的DB使用合适的Driver呢？是因为Driver接口中额外定义了一个方法acceptsURL(String url)，当这个方法返回true时，代表这个实现类是支持这个db的url的。也就是在调用Driver.connect(url)之前，需要先调用acceptsURL(String url)并返回true。

Dubbo SPI扩展

以上JDBC的解决方案对于单一场景问题不大，但是去到Dubbo这种框架中包含多个接口，如果每个接口都添加一个方法用来判断是否支持，无论对于调用方还是实现方都过于繁琐了。而且通过添加support方法的方式有个问题就是会在代码中写死该实现类支持的场景，对于以后功能增强和缩减都需要代码升级。所以Dubbo对于SPI做了如下扩展：

支持一个SPI接口配置文件中包含多个实现类，使用key-value的结构，key就是这个实现类的简称，调用方通过key来获取实现类
支持默认实现类，当用户没有特殊指定时则使用默认实现类
支持接口适配器，每个SPI接口方法可指定调用哪个实现，直接调用接口的adapter类就行了，不需要每次都要if-else判断。
支持条件激活，指定实现类只有在调用满足特定条件时才可用

Dubbo SPI实现

注解定义

Dubbo中使用注解声明的方式来定义SPI接口和相关属性
@SPI注解
用来标识一个接口是SPI接口，value属性用来指定默认实现类是哪一个

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface SPI {
    /**
     * default extension name
     */
    String value() default "";
}

@Adaptive注解
可以添加在类或者方法上，如果加类上，说明这个类是SPI接口类的adapter类。如果加在方法上，则Dubbo会自动生成一个adapter类，这个类会根据@Adaptive注解的value属性来决定调用哪个实现类。

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Adaptive {
    String[] value() default {};
}

@Activate注解
可以添加在类或者方法上，如果加在类上，则表示这个SPI的实现类是条件激活的，最典型的场景就是用在Filter上，可以指定特定的Filter何时起作用。注解包含3个参数：

group，用来匹配url中的group参数，当前框架中只用到2个值：provider代表服务提供端，consumer代表消费端。比如下面这个Filter的定义，说明这个Filter只有在Provider端起左右，调用在Consumer端时不会经过这个Filter

@Activate(group = CommonConstants.PROVIDER, order = -30000)
public class ClassLoaderFilter implements Filter {
      ...
}

value，用来匹配url中带的key，如果设置了这个值，则只有url中带有指定的key，这个实现类才会被激活。比如下面这个Filter只有在provider端，并且调用的url中包含tps这个参数的时候才会起作用。

@Activate(group = CommonConstants.PROVIDER, value = TPS_LIMIT_RATE_KEY)
public class TpsLimitFilter implements Filter {
    ...
}

扩展类发现

文件目录
跟Java的SPI发现机制类似，Dubbo也是通过约定配置文件的方式来加载接口的扩展的。Dubbo默认会从3个地方加载文件:

META-INF/dubbo/internal/，这个是Dubbo框架自己用的扩展配置文件目录
META-INF/dubbo/，用户自定义扩展配置文件目录
META-INF/services/，Java SPI使用的目录，这个是为了兼容低版本Dubbo

SPI的配置文件放在以上任何一个目录下都可以被Dubbo成功加载，当然最好按照Dubbo的建议来放置文件。
文件格式
配置文件的文件名和Java SPI也是一样的，用接口名作为文件名，但是文件内容有区别，下面是Protocol接口的配置文件，文件名为META-INF/dubbo/internal/org.apache.dubbo.rpc.Protocol，文件内容如下：

filter=org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper
listener=org.apache.dubbo.rpc.protocol.ProtocolListenerWrapper
mock=org.apache.dubbo.rpc.support.MockProtocol

文件内容是key-value结构，key是扩展的名字，value是接口的实现类

扩展的类型

Dubbo中对于SPI接口的实现类分成4种：

Adaptive Class : 带@Adaptive注解的实现类
Wrapper Class ：构造函数的参数为当前接口的实现类
Activate Class：带@Activate注解的实现类
普通实现类：除上面3种之外的实现类

Dubbo在加载SPI配置文件的时候会按上面的标准来判断这些实现类，并区分对待。

Adaptive扩展

Dubbo的SPI接口被调用时，具体采用那个扩展类并不是在程序启动的时候就确定了的，而是可以根据url中的参数来确定的。这就决定了SPI需要有一个判断的机制，在每次调用的时候判断应该调用哪个实现类。这其实正是设计模式中Adapter模式的使用场景，通过提供一个Adapter实现类，对用户将实现透明化。下面以Transporter接口为例：

@SPI("netty")
public interface Transporter {
    @Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY})
    Client connect(URL url, ChannelHandler handler) throws RemotingException;
}

可以看到在connect()方法上有一个@Adaptive注解，说明需要根据url中的client和transporter参数来确定使用哪个实现。在调用Transporter的代码中使用如下的代码获取接口的实现：

    public static Transporter getTransporter() {
        return ExtensionLoader.getExtensionLoader(Transporter.class).getAdaptiveExtension();
    }

在第一次调用getAdaptiveExtension()Dubbo自动生成Adapter的代码，生成的代码大概如下面的样子，通过url参数值来获取指定name的实现：

package org.apache.dubbo.remoting;
import org.apache.dubbo.common.extension.ExtensionLoader;
public class Transporter$Adaptive implements org.apache.dubbo.remoting.Transporter {
    public org.apache.dubbo.remoting.Client connect(URL arg0, ChannelHandler arg1) throws RemotingException {
        if (arg0 == null) 
            throw new IllegalArgumentException("url == null");
        org.apache.dubbo.common.URL url = arg0;
        String extName = url.getParameter("client", url.getParameter("transporter", "netty"));
        if(extName == null) 
            throw new IllegalStateException("Failed to get extension (Transporter) name from url (" + url.toString() + ") use keys([client, transporter])");
        Transporter extension = (Transporter)ExtensionLoader.getExtensionLoader(Transporter.class).getExtension(extName);
        return extension.connect(arg0, arg1);
    }
}

如果用户不想使用Dubbo自动生成的Adapter类，可以自己提供一个Adapter类。Dubbo在加载配置文件时会自动识别出来。

Wrapper扩展

Wrapper扩展实现的是设计模式中装饰器模式实现，Dubbo在加载扩展时如果发现扩展类的构造函数的参数是接口本身时，会将这个扩展识别为Wrapper扩展。代码中使用到SPI时，会在获取到实现类后将Wrapper封装上去。如下面的Wrapper类就是将Filter组合到Protocol扩展类上：

public class ProtocolFilterWrapper implements Protocol {
    private final Protocol protocol;
    public ProtocolFilterWrapper(Protocol protocol) {
        if (protocol == null) {
            throw new IllegalArgumentException("protocol == null");
        }
        this.protocol = protocol;
    }
}

以Dubbo协议为例，当获取到DubboProtocol后做一层封装，实际返回的是ProtocolFilterWrapper(DubboProtocol)，Dubbo支持同一个接口多个Wrapper。

Activate扩展

当有些扩展类只有部分调用场景才用到的时候，就可以在扩展类上加上@Activate注解，这样在获取SPI扩展的时候，默认是获取不到这个实现的。需要指定获取Activate扩展。比如在获取Filter的时候，需要通过如下的方法获取所有可用的Filter：

ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);

ExtensionLoader工具类

Dubbo中每个SPI对应一个ExtensionLoader类的实例，同Java中的ServiceLoader类一样，这个类提供类加载扩展实现。同时提供了获取指定类型扩展的方法。

总结

Dubbo的SPI机制是Dubbo的灵活扩展的基础，通过这一机制Dubbo可以在不断地功能增强时都能够保持对老版本的兼容性。在新浪开源的motan和蚂蚁开源的sofa框架中，SPI都采用了Dubbo类似的实现，可见Dubbo的SPI确实是一个出色的设计。

详解Dubbo（十）：SPI实现原理

前言