jdk和dubbo的SPI机制

小鱼儿 2022-12-15 12:44 219阅读 0赞

# [jdk和dubbo的SPI机制][jdk_dubbo_SPI] #

**前言**：开闭原则一直是软件开发领域中所追求的,开闭原则中的"开"是指对于组件功能的扩展是开放的,是允许对其进行功能扩展的,“闭”,是指对于原有代码的修改是封闭的,即不应该修改原有的代码。对于一个高度集成化的、成熟、稳健的系统来讲,永远不是封闭、固守的，它需要向外提供一定的可扩展的能力,外部的实现类或者jar包都可以调用它。在面向对象的开发领域中，接口是对系统功能的高度抽象，因为**SPI**可谓是"应运而生"，本篇博客就开始走进SPI,探究java自身的SPI和Dubbo的SPI到底是什么原理

**目录**

**一：SPI是什么**

**二：jdk的SPI**

**三：dubbo的SPI**

**四：总结**

正文

**一：SPI是什么？**

spi全称英文是service provider Interface，翻译成中文也就是服务提供接口，在jdk 1.6开始,就已经提供了SPI.它的使用比较简单。即在项目的类路径下提供一个META/services/xx文件，配置一个文件，文件名为接口的全路径的名称，内容为具体的实现类全路径名。jdk将会使用ServiceLoader.load（）方法去解析和加载接口和其中的实现类,按需执行不同的方法。

举个简单的例子：在jdbc中，jdk提供了driver(数据库)接口，但是不同的厂商实现起来的方式不同，比如mysql、oracle、sqlLite等厂商底层的实现逻辑都是不同的,因此在对数据库驱动driver实现方式上,可以采用SPI机制。比如在mysql-contactor.jar包中会在META/services路径下,这里相当于扩展了java.sql.Driver接口,jdk会在META/services路径下扫描该文件,然后加载mysql的diver实现类com.mysql.cj.jdbc.Driver，就相当于扩展了Driver的接口能力，按需加载mysql的实现类。oracle的连接jar包会有oracle的配置文件，这样不同的数据库根据自身的不同逻辑按需扩展了Driver的能力，这就是SPI的最大好处。

![5503f1a7bb7d02452928d5a199724fc8.png][]

java.sql.Driver的内容：

![c8b482da87dfdf00b8c404bf6c2e786b.png][]

**二：java的SPI机制**

从jdk1.6开始，java就提供了spi机制的支持,接下来我们就从一个例子来说明jdk的spi是如何实现的？

2.1：设计一个接口

public interface Animal {
        void sound();
    }

2.2：有两个实现类：

public class Cat implements Animal {
        public void sound() {
            System.out.println("小猫在叫");
        }
    }

public class Dog implements Animal {
        public void sound() {
            System.out.println("小狗在叫");
        }
    }

2.3:配置META-INF类

![1f32703f64d0716cea1910f8482b9765.png][]

![bb75434a61b0ca33d4cfabe4eead26e8.png][]

2.4:读取配置

public static void main(String[] args) {
            ServiceLoader<Animal> serviceLoader = ServiceLoader.load(Animal.class);
            final Iterator<Animal> iterator = serviceLoader.iterator();
            while (iterator.hasNext()) {
                Animal next =  iterator.next();
                next.sound();
            }
        }
    }

![b8f3baab8d1c2ee62c12367de04beff3.png][]

**2.5:原理**

在上面的例子中：定义了一个接口Animal,然后有两个实现类:Cat和Dog,在META-INF的文件目录下,两个接口都进行了相关的配置,接口实现类模块要同时加载两个类,具体的调用逻辑在客户端的ServiceLoader中来通过迭代器遍历来调用具体的配置实现类,那么代码具体的原理是什么呢？跟着我一起走进源码来分析一下jdk：

在ServiceLoader的load方法中首先会获取上下文类加载器,然后构造一个ServiceLoader，在ServiceLoader中有一个懒加载器，懒加载器会通过BufferedReader来从META-INF/services路径下读取对应的接口名的全路径名文件，也就是我们配置的文件,然后通过文件的类解析器读取文件中的内容,再通过类加载器加载类的全路径

![2feaae5022eeee587aaa274c16fc5c23.png][]

仔细分析下java的spi具有以下缺点：

①无法按需加载。虽然 ServiceLoader 做了延迟载入，使用了LazyIterator,但是基本只能通过遍历全部获取，接口的实现类得全部载入并实例化一遍。如果你并不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了,假如我只需要其中一个,其它的并不需要这就形成了一定的资源消耗浪费

②不具有IOC的功能,假如我有一个实现类,如何将它注入到我的容器中呢，类之间依赖关系如何完成呢？

③serviceLoader不是线程安全的,会出现线程安全的问题

##  **三：dubbo的SPI** ##

dubbo在原有的spi基础上主要有以下的改变,**①配置文件采用键值对配置的方式，使用起来更加灵活和简单** **②**** 增强了原本SPI的功能，使得SPI具备ioc和aop的功能**，这在原本的java中spi是不支持的。dubbo的spi是通过ExtensionLoader来解析的，通过ExtensionLoader来加载指定的实现类，配置文件的路径在META-INF/dubbo路径下，我们通过一个例子来了解dubbo的SPI运行机制：

3.1：dubbo的负载均衡机制其中就采用了spi机制,选择哪个负载均衡策略是通过@SPI注解来实现的：

![bd93e3354dabf27d685edaf90dbe04c7.png][]

利用ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(name)来获取具体的LoadBalance的实现类,其中name是对应配置文件(见下文)中的键；

![597959f80e05abb305ec8ec6318c5b96.png][]

其中用了@SPI来指定了dubbo的负载均衡策略为随机(random),我们再来了解一下@SPI注解和@Adaptive是如何工作的？

3.2：在dubbo的META\_INF.dubbo.internal路径下存在一个文件：

com.alibaba.dubbo.rpc.cluster.LoadBalance文件,文件内容是这样的：

![c5c02bea53200d957f2fb660ed2a8157.png][]

可以看出dubbo的spi配置是采用**键值对**的方式,键值对最大的好处就是可以以键来获取值，取值比较简单和方便。这点和java的spi配置方式是不同的，java的spi只有全路径名；

### 3.3:@SPI和@Adaptive注解的作用是什么？ ###

Dubbo通过注解@Adaptive作为标记实现了一个适配器类，dubbo将会为这个类动态生成代理对象；ExtensionLoader中获取默认实现类或者通过实现类名称(由@SPI注解指定的名称)来获取实现类

为什么会出现@Adaptive这个注解呢？主要原因是因为dubbo的加载扩展了是从配置文件加载的，是很动态的，但是实现类却要固定写死或者灵活实现，所以就得区分开。用@Adaptive就是表示由框架自己生成,不需要人为实现.

在dubbo加载SPI时会动态创建SPI `Adaptive`实现`ExtensionLoader`。从URL获取密钥，该密钥将通过`@Adaptive由`接口方法定义的注释提供

### 3.4:dubbo的spi读取配置和实现类原理 ###

3.4.1:从解析加载配置类的源码开始分析

ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(Constants.DEFAULT_LOADBALANCE)

上面的源码比较简单，首先是根据传入的接口从缓存(一个以class为键,ExtensionLoader为值的concurrentHashMap)中获取，如果拿不到就放入到缓存中；逻辑比较简单,这里就不做详细分析了。接下来主要是分析:ExtensionLoader.getExtension(name)

![6c935d69460095ec9defc473467daf82.png][]

我们来看下具体的createExtension方法的源码：

![8183d450a23136fcb501a9373020ac4b.png][]

createExtension 方法的逻辑稍复杂一下，包含了如下的步骤:

①通过 getExtensionClasses 获取所有的拓展类，也就是所有META-INF下的配置文件中的键值对名

②通过反射创建拓展对象

③向拓展对象中注入依赖

④将拓展对象包裹在相应的 Wrapper 对象中，后面需要从wrapper中取

来具体看一下dubbo是如何解析配置文件的：

![333b288c1889a1a8394068ce8ddeb8d5.png][]

上面可以看出三个路径,这和我们刚才上面看到的路径是一致的，dubbo就是读取该路径下的的文件 ![b7c8753e7a4d16f7e8b0d4d344f44f9a.png][]

加载配置文件下的文件内容，也就是上面的com.alibaba.dubbo.rpc.cluster.LoadBalance文件![5e20e9e06807639f9b6c908fa4f0377f.png][]

### 3.5：dubbo的IOC机制 ###

dubbo的IOC是通过setter方法来实现注入的,通过遍历对象实例的所有方法,找到其setter方法在进行截取，从objectFactory中获取扩展类再进行反射执行。这样的话,就算实现实例中有依赖的扩展实例，都可以注入完成，是dubbo的IOC体现。ojectFactory 变量的类型为 AdaptiveExtensionFactory，AdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表，用于存储其他类型的 ExtensionFactory。

![f397592fa34bc65b1408299ace6bbd15.png][]

# 四:总结  #

本篇博客简单分别介绍了 Java SPI 与 Dubbo SPI 用法，java的spi举了个简单的例子来进行了说明。并仔细分析了jdk的spi不足，dubbo是如何面对jdk的不足之处，然后自己定制开发出一套更加合理和更好的dubbo自我实现。以及详细分析了 Dubbo SPI 的加载拓展类的过程和源码的分析。其中可以看出来dubbo中对于缓存和反射的利用是相当之多的.SPI是软件设计中高扩展性的一个体现,通过spi机制可以灵活地实现厂商的规范订制和不同企业的具体规范自己实现.高度扩展了原程序，使得我们设计出来的程序更加具有扩展力。

** **

[jdk_dubbo_SPI]: https://www.cnblogs.com/wyq178/p/12171881.html
[5503f1a7bb7d02452928d5a199724fc8.png]: /images/20221123/c35285d662c64409a360c144310b06a8.png
[c8b482da87dfdf00b8c404bf6c2e786b.png]: /images/20221123/32efb6089006472b9ba53a78b946bebd.png
[1f32703f64d0716cea1910f8482b9765.png]: /images/20221123/f6081db05da14b4c8f15a6660ce5df9a.png
[bb75434a61b0ca33d4cfabe4eead26e8.png]: /images/20221123/859d09b3d3b4403e82211bf017d55dea.png
[b8f3baab8d1c2ee62c12367de04beff3.png]: /images/20221123/a8adc34dd518485a9a542dd0dba1635e.png
[2feaae5022eeee587aaa274c16fc5c23.png]: /images/20221123/c448ce3adc064bb480dcd9720c95a2c1.png
[bd93e3354dabf27d685edaf90dbe04c7.png]: /images/20221123/bf6a173743294140a639e01bf311b4e7.png
[597959f80e05abb305ec8ec6318c5b96.png]: /images/20221123/aae90b5410e94d25a0837ee7e1eb2b38.png
[c5c02bea53200d957f2fb660ed2a8157.png]: /images/20221123/b36c9bf7a03644e08646b809c112cb08.png
[6c935d69460095ec9defc473467daf82.png]: /images/20221123/c4844553bf574cefa87a635ce57c7a83.png
[8183d450a23136fcb501a9373020ac4b.png]: /images/20221123/5ee38456dc7e4d7688e35f331a93ee76.png
[333b288c1889a1a8394068ce8ddeb8d5.png]: /images/20221123/b53de75f67e34c42bb6364e3d3ef50ab.png
[b7c8753e7a4d16f7e8b0d4d344f44f9a.png]: /images/20221123/18e41e3cabe945769df30dbff2adcc5f.png
[5e20e9e06807639f9b6c908fa4f0377f.png]: /images/20221123/b40f67dd10ac480e95117493d7d559fa.png
[f397592fa34bc65b1408299ace6bbd15.png]: /images/20221123/b7c886d88ac54ff18960160a68c066b2.png