Dubbo的SPI机制是啥啊？-技术圈

前言

之前大致的把Dubbo的运作流程简单的分析了一遍了，Dubbo还有一个很大的优点，就是采用的微内核+SPI扩展设计

这又是什么呢，这个可以很好的支持一些有特殊需求的三方的接入，可以自定义扩展，自主定制二次开发，良好的扩展性对于框架来说是很重要的

简单了解下SPI，全称为 Service Provider Interface，是一种服务发现机制。

它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制。

举个例子，比如你有个接口，现在这个接口有 3 个实现类，那么在系统运行的时候对这个接口到底选择哪个实现类呢？这就需要SPI了，需要根据指定的配置或者是默认的配置，去找到对应的实现类加载进来，然后用这个实现类的实例对象。

Java中JDK自身实现了SPI机制，基于策略模式来实现动态加载的机制。我们在程序只定义一个接口，具体的实现交个不同的服务提供者；在程序启动的时候，读取配置文件，由配置确定要调用哪一个实现

但是呢，存在一定的缺点，比如不能按照需要加载，会一次性加载所有可用的扩展点，很多是不需要的，会浪费系统资源；不支持AOP和依赖注入，实现类的方式也不够灵活，只能通过 Iterator 形式获取

你不够强，或者说你做的不符合我的需求，我就替换你

于是呢，dubbo重新实现了一套功能更强的 SPI 机制, 支持了AOP与依赖注入，并且利用缓存提高加载实现类的性能，同时支持实现类的灵活获取

Java中的SPI

首先，我们需要定义一个接口，SPIService

public interface SPIService {    void execute();}

然后，定义两个实现类，没别的意思，只输入一句话。

‍

public class SpiImpl1 implements SPIService{    public void execute() {        System.out.println("SpiImpl1.execute()");    }}
public class SpiImpl2 implements SPIService{    public void execute() {        System.out.println("SpiImpl2.execute()");    }}

最后呢，要在ClassPath路径下配置添加一个文件。文件名字是接口的全限定类名，内容是实现类的全限定类名，多个实现类用换行符分隔。内容就是实现类的全限定类名：

com.tech.dayu.spi.SpiImpl1com.tech.dayu.spi.SpiImpl2

测试

public class Test {    public static void main(String[] args) {            Iterator<SPIService> providers = Service.providers(SPIService.class);        ServiceLoader<SPIService> load = ServiceLoader.load(SPIService.class);
        while(providers.hasNext()) {            SPIService ser = providers.next();            ser.execute();        }        System.out.println("###################");        Iterator<SPIService> iterator = load.iterator();        while(iterator.hasNext()) {            SPIService ser = iterator.next();            ser.execute();        }    }}

两种方式的输出结果是一致的：

SpiImpl1.execute()SpiImpl2.execute()--------------------------------SpiImpl1.execute()SpiImpl2.execute()

我们来看下源码，位于java.util包下。我们就以ServiceLoader.load为例，通过源码看看它里面到底怎么做的

ServiceLoader.load()其实就是 Java SPI 入口

看到最后调用的是reload，最后生效的是在这个LazyIterator的内部，等同于是一个迭代器的遍历，遍历相应的文件中的service的实现类，就是我们上面命名的那些

这里无论是if还是else最后调用的都是nextService()方法，点进去看

可以看到无非就是通过名字获取到文件路径，获取全限定名来加载类，并且创建其实例放入到相应的缓存之后并且返回实例，这大体就是整个的实现逻辑，应该不难吧，咱们自己来实现个这个应该也是分分钟的事

好了，Java的SPI源码分析的差不多了，问题也随之而来，比如不能按照需要加载，会一次性加载所有可用的扩展点，很多是不需要的，会浪费系统资源；不支持AOP和依赖注入，实现类的方式也不够灵活，只能通过 Iterator 形式获取

接下来咱们来分析Dubbo的SPI

Dubbo中的SPI

Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。

Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下。

Dubbo要判断一下，在系统运行时，应该选用这个Protocol接口的哪个实现类。它会去找一个你配置的Protocol，将你配置的Protocol实现类，加载进JVM，将其实例化，微内核，可插拔，大量的组件，Protocol负责RPC调用的东西，你可以实现自己的RPC调用组件，实现Protocol接口，给自己的一个实现类就可以啦

Dubbo里很多都是保留一个接口和多个实现，然后在系统运行的时候动态根据配置去找到对应的实现类。如果你没配置，那就走默认的实现就可以啦

我们随便来看一下其中的