版本

2.7.8

SPI机制

官方文档介绍如下

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。

说白了，SPI是一种第三方框架常用的扩展手段：第三方框架定义接口，使用者来写实现类，通过SPI机制框架运行时可以获取到这个实现类，通过反射创建对象，并使用这个对象来继续完成业务

SPI机制

所以通过SPI机制，第三方框架可以将某一段业务逻辑交由使用者自定义实现

比如Dubbo的负载均衡策略，内置提供了多种常用策略(Random/RoundRobin..)，但依然无法满足所有用户的需求

通过SPI机制，可以让用户自己实现负载均衡策略，Dubbo再发送RPC调用时通过SPI获取到用户实现的策略，并使用这个策略来决策最终选择调用的服务端

Java SPI

jdk提供了简单的SPI功能，可以再运行时获取某接口的所有扩展实现类，比如，定义一个接口:Car

public interface Car {
    void run();
}

定义两个实现:Audi(奥迪)和Buick(别克)

public class Audi implements Car {
    @Override
    public void run() {
        System.out.println("Audi is running");
    }
}
public class Buick implements Car {
    @Override
    public void run() {
        System.out.println("Buick is running");
    }
}

在 META-INF/services 文件夹下创建一个文件，名称为 Car 的全限定名 com.pq.pure.spi.Car。文件内容为实现类的全限定的类名，如下：

com.pq.pure.spi.Buick
com.pq.pure.spi.Audi

Java SPI Dubbo SPI 的相关逻辑被封装在了ServiceLoader下，测试一下

public class SPITest {
    @Test
    public void run() {
        ServiceLoader<Car> serviceLoader = ServiceLoader.load(Car.class);
        serviceLoader.forEach(Car::run);
    }
}

输出如下

JAVA SPI

成功加载了两个实现类，并实例化且循环执行了run方法

Dubbo SPI

Java提供的SPI可以获取某个接口的所有实现，一般后续代码就是全部循环执行，可以新增，但不能只指定其中某一个执行，比较使用的场景比如~后置处理器

而Dubbo需要的场景一般是从接口的实现中指定某一个(比如从多个负载均衡器中选用一个)去执行，这种场景Java SPI就很难实现了，所以Dubbo自己实现了一套SPI机制：

• 可以给每个实现取一个名字
• 可以按名字获取对应的实现

可以理解为JAVA SPI的所有实现是一个LIST，可以循环但不能指定某一个，而Dubbo SPI所有实现是一个MAP，可以根据key获取指定的一个

Dubbo SPI

接下来就测试一下Dubbo SPI的使用，还是刚才的一个接口和两个实现，在
META-INF/dubbo目录下文件夹下以 Car 的全限定名创建文件，内容如下

Buick=com.pq.pure.spi.Buick
Audi=com.pq.pure.spi.Audi

等号前面是key后面是value

Dubbo SPI 的相关逻辑被封装在了ExtensionLoader类中，测试一下(需要给Car接口加上@SPI注解)

public class DubboSPITest {
    public static void main(String[] args) {
        // 初始化Car接口的扩展类加载器
        ExtensionLoader<Car> extensionLoader = ExtensionLoader.getExtensionLoader(Car.class);
        // 获取名为"Buick"的扩展实现
        Car buick = extensionLoader.getExtension("Buick");
        // 运行
        buick.run();
    }
}

运行结果如下

Buick

这就是Dubbo SPI的更强的地方，可以按名称获取某一个实现，这样就可以实现通过配置来切换实现，也方便自定义扩展实现

模拟实现

接下来再深度研究下Dubbo SPI如何做到的

首先如果自己去实现，如何做到？大概整理一下实现流程，其实很简单

• 约定一个地址，让用户去里面定义文件，以key=value的形式填写实现名称和全限定名
• 当获取某个接口的某个名称实现时，去约定地址下读取名为接口全限定名文件，扫描文件内容，获取到key为该名称的value(即实现的全限定名)，通过类加载器加载这个类，然后通过反射创建实例返回

思路屡清了，很简单，接下来尝试实现一下

做一个接口扩展加载器，用泛型代表接口类型，并约定好扩展文件地址: META-INF/pq下

public class ExtensionLoader<T> {
    /**
     * 接口的类
     */
    private final Class<T> type;

    /**
     * 约定好的地址
     */
    private final static String dir = "META-INF/pq/";

    public ExtensionLoader(Class<T> type) {
        this.type = type;
    }
}

在约定路径 META-INF/pq 下创建扩展文件com.pq.pure.spi.Car，内容与之前一样

com.pq.pure.spi.Car

实现类加载功能，即把扩展文件中的内容转换为MAP内存结构

MAP内存结构

代码如下

/**
 * 获取当前接口的扩展类，即把扩展文件中的的数据转换为map结构
 *
 * @return
 */
private Map<String, Class<?>> loadExtensionClasses() {
    try {
        // 存储结果
        Map<String, Class<?>> extensionClasses = new HashMap<>();
        // 扩展文件名称
        String fileName = dir + type.getName();
        // jdk 类加载器
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        // 加载配置文件
        Enumeration<URL> urls = classLoader.getResources(fileName);

        if (urls != null) {
            while (urls.hasMoreElements()) {
                URL resourceURL = urls.nextElement();
                loadResource(extensionClasses, classLoader, resourceURL);
            }
        }
        return extensionClasses;
    } catch (Throwable t) {
        throw new IllegalStateException();
    }
}

/**
 * 读取扩展文件
 * @param extensionClasses
 * @param classLoader
 * @param resourceURL
 */
private void loadResource(Map<String, Class<?>> extensionClasses, ClassLoader classLoader,
                          URL resourceURL) {
    try {
        try (BufferedReader reader = new BufferedReader(new InputStreamReader(resourceURL.openStream(), StandardCharsets.UTF_8))) {
            String line;
            // 逐行读取
            while ((line = reader.readLine()) != null) {
                line = line.trim();
                if (line.length() > 0) {
                    // 找到等号
                    int i = line.indexOf('=');
                    // name
                    String name = line.substring(0, i).trim();
                    // 实现类全限定名
                    line = line.substring(i + 1).trim();
                    extensionClasses.put(name, Class.forName(line, true, classLoader));
                }
            }
        }
    } catch (Throwable t) {
       throw new IllegalStateException();
    }
}

主要用到了类加载的功能，和文件读取的一些逻辑

最后，根据名字获取某个实现的实例，很简单，从map中读取class，反射实例化即可

/**
 * 根据name获取实现实例
 * @param name
 * @return
 */
public T getExtension(String name) {
    // todo 省去了缓存逻辑
    // 获取改名字的实现类
    Class<?> clazz = loadExtensionClasses().get(name);
    try {
        // 反射实例化
        return (T) clazz.newInstance();
    } catch (Exception e) {
        throw new IllegalStateException();
    }
}

测试一下

package com.pq.pure.spi;

import com.pq.pure.spi.extension.ExtensionLoader;

public class MyDubboTest {
    public static void main(String[] args) {
        ExtensionLoader<Car> extensionLoader = new ExtensionLoader(Car.class);
        // 获取别克的实现
        Car buick = extensionLoader.getExtension("Audi");
        // 运行
        buick.run(); // 输出 Audi is running
    }
}

至此就实现了一个运行时按名称获取对应实现的SPI功能~

源码

回头看dubbo的实现源码，其实上一步的模拟实现就是从源码摘抄的主线代码，但是省略了很多功能、异常校验、线程安全、缓存等，下面来学习下Dubbo源码的优秀写法

缓存

因为读取文件，反射这些代码都是比较耗时的，而且读取一次之后完全可以缓存起来下次直接使用，所以Dubbo的ExtensionLoader源码中包含大量的缓存逻辑，比如

// 缓存每个可扩展接口的扩展加载器，是一个静态全局缓存
static ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS

// 缓存当前扩展加载器每个扩展实现类的实例
ConcurrentMap<Class<?>, Object> EXTENSION_INSTANCES

// 缓存当前扩展加载器每个实现名称对应的实现类
Holder<Map<String, Class<?>>> cachedClasses

// 缓存当前扩展加载器每个实现名称对应的实现类实例
ConcurrentMap<String, Holder<Object>> cachedInstances

配置路径

在我们的模拟实现中使用一个静态变量来约定配置的路径：

private final static String dir = "META-INF/pq/";

而dubbo的实现更具有扩展性，并且是使用Java SPI来实现这种扩展性

首先dubbo定义了一个加载策略的接口

LoadingStrategy

最重要的方法就是directory()，返回的就是配置路径
在ExtensionLoader类中存放静态的加载策略实现数组

public class ExtensionLoader<T> {
    //...
    private static volatile LoadingStrategy[] strategies = loadLoadingStrategies();
    private static LoadingStrategy[] loadLoadingStrategies() {
        // 通过JAVA SPI加载策略实现类
        return stream(ServiceLoader.load(LoadingStrategy.class).spliterator(), false)
                .sorted()
                .toArray(LoadingStrategy[]::new);
    }
    //...
}

可以到Dubbo jar包中META-INF/services下找到其实现配置文件

LoadingStrategy扩展配置文件

内容

内置三个策略，分别对应"META-INF/dubbo/internal/","META-INF/dubbo/","META-INF/services/"三个路径，而且可以继续扩展

AOP

Dubbo SPI还支持面向切面编程，回到Dubbo SPI那个例子，我们的Car接口有两种实现：别克&奥迪，如果有个需求是不管使用什么车，都要加一个行车记录仪，这时只需要加一个行车记录仪的装饰器即可

public class CarRecorderWrapper implements Car {

    private Car car;

    public CarRecorderWrapper(Car car) {
        this.car = car;
    }

    @Override
    public void run() {
        car.run()；
        System.out.println("driving recorder");
    }
}

配置文件也加入

CarRecorder=com.pq.pure.spi.CarRecorderWrapper

这时再次运行原测试用例，结果如下

AOP

而其实现方式：再扫描实现时看看你的这个类是不是装饰器类，如果是，就缓存起来

loadClass

而是否是装饰器类就是看是否有以该接口为参数的构造方法

isWrapperClass

熟悉装饰器模式的人应该一看就懂
再实例化时createExtension，会使用所有装饰器对其装饰一遍，以达到代理的目的

createExtension

线程安全

这事挺不足道的，但感觉写的挺巧妙就研究一下

源码中线程安全考虑主要是对以上这些缓存，比如 cachedInstances 保存的是一个名称到实例映射的 ConcurrentMap，但是依然会出问题：

比如两个线程同时要获取相同名称的实例，发现缓存中没有，于是两个线程同时开始进行读取配置创建实例一系列操作，但最终只有先实例化完的线程成功的把实例存入缓存(使用putIfAbsent)，而另一个线程就耗费了时间和资源去实例化了一个无用的对象

线程时序图1

一般自己写代码这种情况其实也可以接受，至少不会出现bug，只是有点性能浪费

如果想保证只有一个线程加载实例化，用锁即可，比如用synchronized给cachedInstances上锁就可以解决，但是锁的粒度太大，会导致其它实现的实例化过程都被阻塞

Dubbo解决问题的方法还是挺巧妙的：

如果细心看可以发现cachedInstances存储的并不是 ConcurrentMap<String, Object> 而是 ConcurrentMap<String, Holder<Object>>，使用了一个Holder来存放对象，看一下Holder类

public class Holder<T> {

    private volatile T value;
    public void set(T value) {
        this.value = value;
    }
    public T get() {
        return value;
    }
}

就是一个存放对象的类，使用volatile保证对象的可见性，初看感觉这个类莫名其妙，继续往下看getExtension中

getExtension

getOrCreateHolder

以上代码逻辑：当获取某名称实例时，会走getOrCreateHolder方法在缓存中该名称位置存放一个空Holder对象，且只有第一个线程创建，其它线程只是获取，该方法返回holder对象，通过synchronized给holder上锁，然后检查是否为空，如果为空就创建，这样就保证只有一个线程会实际执行实例化的代码，而且synchronized的锁粒度只是当前名称的实现，不妨碍其它实现的实例化

线程时序图2

所以可以说Holder的存在就是为了控制synchronized的锁粒度

其它

DUBBO SPI还支持IOC，并且涉及到一个扩展点自适应机制，相对复杂一点，留下一篇研究~