手写Dubbo SPI机制和源码解析

版本

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，并且涉及到一个扩展点自适应机制，相对复杂一点，留下一篇研究~

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 214,951评论 6赞 497
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,606评论 3赞 389
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 160,601评论 0赞 350
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,478评论 1赞 288
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,565评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,587评论 1赞 293
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,590评论 3赞 414
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,337评论 0赞 270
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,785评论 1赞 307
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,096评论 2赞 330
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,273评论 1赞 344
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,935评论 5赞 339
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,578评论 3赞 322
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,199评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,440评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,163评论 2赞 366
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,133评论 2赞 352