引言
SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。
在谈dubbo的SPI扩展机制之前，我们需要先了解下java原生的SPI机制，有助于我们更好的了解dubbo的SPI。
java原生的SPI
先上例子：
1. 定义接口Animal ：
public interface Animal {
void run();
}2. 编写2个实现类，Cat和Dog
public class Cat implements Animal{
@Override
public void run() {
System.out.println("小猫步走起来～");
}
}
public class Dog implements Animal {
@Override
public void run() {
System.out.println("小狗飞奔～");
}
}3. 接下来在 META-INF/services 文件夹下创建一个文件，名称为 Animal 的全限定名 com.sunnick.animal.Animal，文件内容为实现类的全限定的类名，如下：
com.sunnick.animal.impl.Dog
com.sunnick.animal.impl.Cat4. 编写方法进行测试
public static void main(String[] s){
System.out.println("======this is SPI======");
ServiceLoader<Animal> serviceLoader = ServiceLoader.load(Animal.class);
Iterator<Animal> animals = serviceLoader.iterator();
while (animals.hasNext()) {
animals.next().run();
}
}目录结构如下：
测试结果如下：
======this is SPI======
小狗飞奔～
小猫步走起来～从测试结果可以看出，我们的两个实现类被成功的加载，并输出了相应的内容。但我们并没有在代码中显示指定Animal的类型，这就是java原生的SPI机制在发挥作用。
SPI机制如下：
SPI实际上是“接口+策略模式+配置文件”实现的动态加载机制。在系统设计中，模块之间通常基于接口编程，不直接显示指定实现类。一旦代码里指定了实现类，就无法在不修改代码的情况下替换为另一种实现。为了达到动态可插拔的效果，java提供了SPI以实现服务发现。
在上述例子中，通过ServiceLoader.load(Animal.class)方法动态加载Animal的实现类，通过追踪该方法的源码，发现程序会去读取META-INF/services目录下文件名为类名的配置文件（如上述例子中的META-INF/services/com.sunnick.animal.Animal文件），如下，其中PREFIX 常量值为”META-INF/services/”:
try {
String fullName = PREFIX + service.getName();
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}然后再通过反射Class.forName()加载类对象，并用instance()方法将类实例化，从而完成了服务发现。
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
fail(service,
"Provider " + cn + " not found");
}许多常用的框架都使用SPI机制，如slf日志门面和log4j、logback等日志实现，jdbc的java,sql.Driver接口和各种数据库的connector的实现等。
dubbo的SPI使用
Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，配置内容如下:
dog=com.sunnick.animal.impl.Dog
cat=com.sunnick.animal.impl.Cat与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样就可以按需加载指定的实现类。
另外，在使用 Dubbo SPI 时，需要在 Animal接口上标注 @SPI 注解，Cat与Dog类不变。下面来演示 Dubbo SPI 的用法：
@SPI
public interface Animal {
void run();
}编写测试方法：
public void testDubboSPI(){
System.out.println("======dubbo SPI======");
ExtensionLoader<Animal> extensionLoader =
ExtensionLoader.getExtensionLoader(Animal.class);
Animal cat = extensionLoader.getExtension("cat");
cat.run();
Animal dog = extensionLoader.getExtension("dog");
dog.run();
}测试结果如下：
======dubbo SPI======
小猫步走起来～
小狗飞奔～dubbo的SPI源码分析
Dubbo通过ExtensionLoader.getExtensionLoader(Animal.class).getExtension("cat")方法获取实例。该方法中，会先到缓存列表中获取实例，若未命中，则创建实例：
public T getExtension(String name) {
if (name == null || name.length() == 0)
throw new IllegalArgumentException("Extension name == null");
if ("true".equals(name)) {
// 获取默认的拓展实现类
return getDefaultExtension();
}
// Holder，顾名思义，用于持有目标对象
Holder<Object> holder = cachedInstances.get(name);
if (holder == null) {
cachedInstances.putIfAbsent(name, new Holder<Object>());
holder = cachedInstances.get(name);
}
Object instance = holder.get();
// 双重检查
if (instance == null) {
synchronized (holder) {
instance = holder.get();
if (instance == null) {
// 创建拓展实例
instance = createExtension(name);
// 设置实例到 holder 中
holder.set(instance);
}
}
}
return (T) instance;
}创建实例过程如下，即createExtension()方法：
private T createExtension(String name) {
// 从配置文件中加载所有的拓展类，可得到“配置项名称”到“配置类”的映射关系表
Class<?> clazz = getExtensionClasses().get(name);
if (clazz == null) {
throw findException(name);
}
try {
T instance = (T) EXTENSION_INSTANCES.get(clazz);
if (instance == null) {
// 通过反射创建实例
EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
instance = (T) EXTENSION_INSTANCES.get(clazz);
}
//此处省略一些源码......
return instance;
} catch (Throwable t) {
throw new IllegalStateException("...");
}
}获取所有的SPI配置文件，并解析配置文件中的键值对的方法getExtensionClasses()的源码如下:
private Map<String, Class<?>> getExtensionClasses() {
// 从缓存中获取已加载的拓展类
Map<String, Class<?>> classes = cachedClasses.get();
// 双重检查
if (classes == null) {
synchronized (cachedClasses) {
classes = cachedClasses.get();
if (classes == null) {
// 加载拓展类
classes = loadExtensionClasses();
cachedClasses.set(classes);
}
}
}
return classes;
}
这里也是先检查缓存，若缓存未命中，则通过 synchronized 加锁。加锁后再次检查缓存，并判空。此时如果 classes 仍为 null，则通过 loadExtensionClasses 加载拓展类。下面分析 loadExtensionClasses 方法的逻辑。
private Map<String, Class<?>> loadExtensionClasses() {
// 获取 SPI 注解，这里的 type 变量是在调用 getExtensionLoader 方法时传入的，即示例中的Animal
SPI defaultAnnotation = (SPI)this.type.getAnnotation(SPI.class);
if(defaultAnnotation != null) {
String extensionClasses = defaultAnnotation.value();
if(extensionClasses != null && (extensionClasses = extensionClasses.trim()).length() > 0) {
// 对 SPI 注解内容进行切分
String[] names = NAME_SEPARATOR.split(extensionClasses);
// 检测 SPI 注解内容是否合法，不合法则抛出异常
if(names.length > 1) {
throw new IllegalStateException("more than 1 default extension name on extension " + this.type.getName() + ": " + Arrays.toString(names));
}
if(names.length == 1) {
this.cachedDefaultName = names[0];
}
}
}
HashMap extensionClasses1 = new HashMap();
// 加载指定文件夹下的配置文件
this.loadFile(extensionClasses1, "META-INF/dubbo/internal/");
this.loadFile(extensionClasses1, "META-INF/dubbo/");
this.loadFile(extensionClasses1, "META-INF/services/");
return extensionClasses1;
}可以看出，最后调用了loadFile方法，该方法就是从指定的目录下读取指定的文件名，解析其内容，将键值对放入map中，其过程不在赘述。
以上就是dubbo的SPI加载实例的过程。
Dubbo SPI与原生SPI的对比
java原生SPI有以下几个缺点：
- 需要遍历所有的实现并实例化，无法只加载某个指定的实现类，加载机制不够灵活；
- 配置文件中没有给实现类命名，无法在程序中准确的引用它们；
- 没有使用缓存，每次调用load方法都需要重新加载
如果想使用Dubbo SPI，接口必须打上@SPI注解。相比之下，Dubbo SPI有以下几点改进：
- 配置文件改为键值对形式，可以获取任一实现类，而无需加载所有实现类，节约资源；
- 增加了缓存来存储实例，提高了读取的性能；
除此之外，dubbo SPI还提供了默认值的指定方式（例如可通过@SPI（“cat”）方式指定Animal的默认实现类为Cat）。同时dubbo SPI还提供了对IOC和AOP等高级功能的支持，以实现更多类型的扩展。
总结
SPI是一种服务发现机制，提供了动态发现实现类的能力，体现了分层解耦的思想。
在架构设计和代码编写过程中，模块之间应该针对接口编程，避免直接引用具体的实现类，可达到可插拔的效果。
Dubbo提供了增强版的SPI机制，在使用过程中，需要在接口上打上@SPI注解才能生效。