1、什么是SPI？

SPI：Service Provider Interface:服务提供接口，最常见在访问数据库时候用到的java.sql.Driver接口了。

市面上的数据库五花八门，不同的数据库底层协议的大不相同，所以首先需要定制一个接口，来约束一下这些数据库，而具体的实现可以交给数据库厂商，使得 Java 语言的使用者在调用数据库的时候可以方便、统一面向接口编程。

比如：我们的服务接口,有多个实现，那怎么确定使用那个实现,这就需要SPI了，我们统一在classpath下META-INF/services定义我们的接口全名称（包名+接口名），而在文件中定义我们要使用的实现类(包名+接口实现类名）

Jdk中的SPI是依靠ServiceLoader.load(接口名)实现的，会找到当前线程的classLoader，如果当前线程的classLoader为空，会使用系统AppClassLoader，会根据META-INF/services定义我们的接口全名称找到具体实现类，进行全部加载。

想一下 Java SPI 哪里不好？
相信大家一眼就能看出来，Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化，假设一个实现类初始化过程比较消耗资源且耗时，但是你的代码里面又用不上它，这就产生了资源的浪费。

所以说 Java SPI 无法按需加载实现类。

2、Dubbo SPI？

      Dubbo 就自己实现了一个 SPI，让我们想一下按需加载的话首先你得给个名字，通过名字去文件里面找到对应的实现类全限定名然后加载实例化即可，duboo中的SPI是一个key-value的形式。

我们先来看一下 Dubbo 对配置文件目录的约定，不同于 Java SPI ，Dubbo 分为了三类目录。

META-INF/services/ 目录：该目录下的 SPI 配置文件是为了用来兼容 Java SPI 。

META-INF/dubbo/ 目录：该目录存放用户自定义的 SPI 配置文件。

META-INF/dubbo/internal/ 目录：该目录存放 Dubbo 内部使用的 SPI 配置文件。
dubbo具体实现是通过ExtensionLoader 类似于JDK中的ServiceLoader，

大致流程就是先通过接口类找到一个ExtensionLoader ，然后再通过 ExtensionLoader.getExtension(name) 得到指定名字的实现类实例。

ExtensionLoader.getExtension(name) 中的name就是dubbo/internal文件中的key