dubbo的SPI应用与原理是什么，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

创新互联公司专注于郊区网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供郊区营销型网站建设，郊区网站制作、郊区网页设计、郊区网站官网定制、小程序开发服务，打造郊区网络公司原创品牌,更为您提供郊区网站排名全网营销落地服务。

dubbo

SPI(Service Provider Interface)

• 本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。

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

• 通过 SPI 机制为我们的程序提供拓展功能，在dubbo中，基于 SPI，我们可以很容易的对 Dubbo 进行拓展。例如dubbo当中的protocol，LoadBalance等都是通过SPI机制扩展。

想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们了解下JAVA SPI与dubbo SPI的用法，再分析DUBBO SPI的源码，本文的dubbo源码是基于2.7.5版本。

JAVA 原生SPI 示例

• 先简单介绍JAVA SPI的应用。首先，我们定义一个Car接口

public interface Car {    String getBrand();
}

• 定义该接口的两个实现类。

public class BM implements Car {    public String getBrand() {
        System.out.println("BM car");        return "BM";
    }
}public class Benz implements Car {    public String getBrand() {
        System.out.println("benz car");        return "Benz";
    }
}

• 再在resources下创建META-INF/services 文件夹，并创建一个文件，文件名称为Car接口的全限定名com.dubbo.dp.spi.Car。内容为接口实现类的全限定类名。

  com.dubbo.dp.spi.Benzcom.dubbo.dp.spi.BM

• 使用如下，调用Car接口在配置文件中的所有实现类。

  public class JavaSPITest {  @Test
    public void sayHello() throws Exception {
        ServiceLoader serviceLoader = ServiceLoader.load(Car.class);
        serviceLoader.forEach(car -> System.out.println(car.getBrand()));
    }
  }

  JAVA SPI实现了接口的定义与具体业务实现解耦，应用进程可以根据实际业务情况启用或替换具体组件。

举例：JAVA的java.sql包中就定义一个接口Driver，各个服务提供商实现该接口。当我们需要使用某个数据库时就导入相应的jar包。

缺点

• 不能按需加载。Java SPI在加载扩展点的时候，会一次性加载所有可用的扩展点，很多是不需要的，会浪费系统资源；

• 获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。

• 不支持AOP与依赖注入。

• JAVA SPI可能会丢失加载扩展点异常信息，导致追踪问题很困难；

dubbo SPI示例

• dubbo重新实现了一套功能更强的 SPI 机制,支持了AOP与依赖注入，并且利用缓存提高加载实现类的性能，同时支持实现类的灵活获取，文中接下来将讲述SPI的应用与原理。

Dubbo的SPI接口都会使用@SPI注解标识，该注解的主要作用就是标记这个接口是一个SPI接口。源码如下:

@Documented@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.TYPE})public @interface SPI {    /**
     * default extension name
     * 设置默认拓展类
     */
    String value() default "";
}

该注解只作用在接口上，value用来设置默认拓展类

• 首先讲解下dubbo SPI的使用。在上述Car接口加上@SPI注解，它的实现类暂时不变，配置文件的路径与文件名也暂时不变，文件内容调整如下：

  @SPIpublic interface Car {  String getBrand();
  }

  benz=com.dubbo.dp.spi.Benzbm=com.dubbo.dp.spi.BM

  配置文件通过键值对的方式进行配置，这样我们可以按需加载指定的实现类。使用如下:

public class JavaSPITest {    @Test
    public void sayHello() throws Exception {
        ExtensionLoader carExtensionLoader = ExtensionLoader.getExtensionLoader(Car.class);        //按需获取实现类对象
        Car car = carExtensionLoader.getExtension("benz");
        System.out.println(car.getBrand());
    }
}

输出结果为

benz car
Benz

Dubbo SPI 源码分析

在dubbo SPI示例方法中，我们首先通过ExtensionLoader的 getExtensionLoader 方法获取一个接口的 ExtensionLoader 实例，然后再通过 ExtensionLoader 的 getExtension 方法获取拓展类对象，源码如下，首先是getExtensionLoader 方法：

    /**
     * 扩展类加载器缓存，就是扩展点ExtendsLoader实例缓存； key=扩展接口 value=扩展类加载器
     */
    private static final ConcurrentMap, ExtensionLoader> EXTENSION_LOADERS = new ConcurrentHashMap<>();    public static  ExtensionLoader getExtensionLoader(Class type) {        //校验传进的type类是否为空
        if (type == null) {            throw new IllegalArgumentException("Extension type == null");
        }        //校验传进的type类是否为接口
        if (!type.isInterface()) {            throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
        }        //校验传进的type类是否有@SPI注解
        if (!withExtensionAnnotation(type)) {            throw new IllegalArgumentException("Extension type (" + type +                    ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
        }        //从ExtensionLoader缓存中查询是否已经存在对应类型的ExtensionLoader实例
        ExtensionLoader loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);        if (loader == null) {            //没有就new一个ExtensionLoader实例，并存入本地缓存
            EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader(type));
            loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
        }        return loader;
    }

getExtensionLoader会对传进的接口进行校验，其中包括是否有@SPI注解校验，这也是在接口上需加@SPI的原因。然后从EXTENSION_LOADERS缓存中获取该接口类型的ExtensionLoader,如果获取不到，则创建一个该接口类型的ExtensionLoader放入到缓存中，并返回该ExtensionLoader。

注意这里创建ExtensionLoader对象的构造方法如下：ExtensionLoader.getExtensionLoader获取ExtensionFactory接口的拓展类，再通过getAdaptiveExtension从拓展类中获取目标拓展类。它会设置该接口对应的 objectFactory常量为AdaptiveExtensionFactory。因为AdaptiveExtensionFactory类上加了@Adaptive注解，为什么是AdaptiveExtensionFactory原因在之后的文章会解释，且objectFactory也会在后面用到。

    private ExtensionLoader(Class type) {        this.type = type;        //type通常不为ExtensionFactory类，则objectFactory为ExtensionFactory接口的默认扩展类AdaptiveExtensionFactory
        objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }

当通过ExtensionLoader.getExtensionLoader取到接口的加载器Loader之后，在通过getExtension方法获取需要拓展类对象。该方法的整个执行流程如下图所示

参照执行流程图，拓展类对象的获取源码如下：

    /**
    * 扩展点实例缓存 key=扩展点名称，value=扩展实例的Holder实例
    */
    private final ConcurrentMap> cachedInstances = new ConcurrentHashMap<>();    /**
     * 获取接口拓展类实例
     * 1.检查缓存中是否存在
     * 2.创建并返回拓展类实例
     * @param name  需要获取的配置文件中拓展类的key
     * @return
     */
 public T getExtension(String name) {        if (StringUtils.isEmpty(name)) {            throw new IllegalArgumentException("Extension name == null");
        }        if ("true".equals(name)) {            // 获取默认的拓展实现类,即@SPI注解上的默认实现类, 如@SPI("benz")
            return getDefaultExtension();
        }        // Holder，顾名思义，用于持有目标对象，从缓存中拿，没有则创建
        final Holder