1 SPI的概述
在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。
1.1 SPI的主要作用
SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。
在面向的对象的设计里，不同模块之间推崇面向接口编程，不建议在模块中对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。SPI使得程序能在ClassPath路径下的META-INF/services文件夹查找接口的实现类，自动加载文件里所定义的实现类。
场景：
数据库驱动java.sql.Driver，Mysql，Oracle都有自己的驱动实现jar包，只需引入不同的jar包即可加载不同的数据库驱动，例如mysql-connector-java中，其META-INF/services下制定了mysql驱动的实现类
Java SPI 实际上是“基于接口的编程＋策略模式＋配置文件”组合实现的动态加载机制。
1.2 入门案例
首先，我们定义一个接口，名称为 Robot。
public interface Robot { void sayHello(); }
接下来定义两个实现类，分别为 OptimusPrime 和 Bumblebee。
public class OptimusPrime implements Robot { @Override public void sayHello() { System.out.println("Hello, I am Optimus Prime."); } } public class Bumblebee implements Robot { @Override public void sayHello() { System.out.println("Hello, I am Bumblebee."); } }
接下来 META-INF/services 文件夹下创建一个文件，名称为 Robot 的全限定名 com.oldlu.java.spi.Robot。文件内容为实现类的全限定的类名，如下：
com.oldlu.java.spi.impl.Bumblebee com.oldlu.java.spi.impl.OptimusPrime
做好所需的准备工作，接下来编写代码进行测试。
public class JavaSPITest { @Test public void sayHello() throws Exception { ServiceLoader<Robot> serviceLoader = ServiceLoader.load(Robot.class); System.out.println("Java SPI"); serviceLoader.forEach(Robot::sayHello); } }
最后来看一下测试结果，如下：
从测试结果可以看出，我们的两个实现类被成功的加载，并输出了相应的内容。
1.3 总结
调用过程
应用程序调用ServiceLoader.load方法，创建一个新的ServiceLoader，并实例化该类中的成员变量
应用程序通过迭代器接口获取对象实例，ServiceLoader先判断成员变量providers对象中(LinkedHashMap<String,S>类型)是否有缓存实例对象，如果有缓存，直接返回。 如果没有缓存，执行类的装载，
优点
使用 Java SPI 机制的优势是实现解耦，使得接口的定义与具体业务实现分离，而不是耦合在一起。应用进程可以根据实际业务情况启用或替换具体组件。
缺点
不能按需加载。虽然 ServiceLoader 做了延迟载入，但是基本只能通过遍历全部获取，也就是接口的实现类得全部载入并实例化一遍。如果你并不想用某些实现类，或者某些类实例化很耗时，它也被载入并实例化了，这就造成了浪费。
获取某个实现类的方式不够灵活，只能通过 Iterator 形式获取，不能根据某个参数来获取对应的实现类。
多个并发多线程使用 ServiceLoader 类的实例是不安全的。
加载不到实现类时抛出并不是真正原因的异常，错误很难定位。
2 Dubbo中的SPI
2.1 概述
Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。
2.2 入门案例
与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样我们可以按需加载指定的实现类。下面来演示 Dubbo SPI 的用法：
1、在使用Dubbo SPI 时，需要在接口上标注 @SPI 注解。
@SPI public interface Robot { void sayHello(); }
2、Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置（key自己指定，value为实现类的全路径），配置内容如下。
注意：每一对key=value，我们把它称之为dubbo的扩展点
optimusPrime = org.apache.spi.OptimusPrime bumblebee = org.apache.spi.Bumblebee
3、通过 ExtensionLoader，我们可以加载指定的实现类，下面来演示 Dubbo SPI ：
public class DubboSPITest { @Test public void sayHello() throws Exception { ExtensionLoader<Robot> extensionLoader = ExtensionLoader.getExtensionLoader(Robot.class); Robot optimusPrime = extensionLoader.getExtension("optimusPrime"); optimusPrime.sayHello(); Robot bumblebee = extensionLoader.getExtension("bumblebee"); bumblebee.sayHello(); } }
测试结果如下：
Dubbo SPI优点：
- 能够实现按需加载，JDK SPI仅仅通过接口类名获取所有实现，在通过迭代器获取指定实现，而ExtensionLoader则通过接口类名和key值获取一个实现
- 支持AOP(将实现类包装在Wrapper中，Wrapper中实现公共增强逻辑)
- 支持IOC(能够通过set方法注入其他扩展点)
IOC 和 AOP 等特性，这些特性将会在接下来的源码分析章节中一一进行介绍。
2.3 源码分析
上一章简单演示了 Dubbo SPI 的使用方法，首先通过 ExtensionLoader 的 getExtensionLoader 方法获取一个 ExtensionLoader 实例，然后再通过 ExtensionLoader 的 getExtension 方法获取拓展类对象。下面我们从 ExtensionLoader 的 getExtension 方法作为入口，对拓展类对象的获取过程进行详细的分析。
public T getExtension(String name) { if (StringUtils.isEmpty(name)) { throw new IllegalArgumentException("Extension name == null"); } if ("true".equals(name)) { // 获取默认的拓展实现类 return getDefaultExtension(); } // Holder，顾名思义，用于持有目标对象 Holder<Object> holder = getOrCreateHolder(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; }
上面代码的逻辑比较简单，首先检查缓存，缓存未命中则创建拓展对象。下面我们来看一下创建拓展对象的过程是怎样的。
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); } // 向实例中注入依赖 injectExtension(instance); Set<Class<?>> wrapperClasses = cachedWrapperClasses; if (CollectionUtils.isNotEmpty(wrapperClasses)) { // 循环创建 Wrapper 实例 for (Class<?> wrapperClass : wrapperClasses) { // 将当前 instance 作为参数传给 Wrapper 的构造方法，并通过反射创建 Wrapper 实例。 // 然后向 Wrapper 实例中注入依赖，最后将 Wrapper 实例再次赋值给 instance 变量 instance = injectExtension( (T) wrapperClass.getConstructor(type).newInstance(instance)); } } return instance; } catch (Throwable t) { throw new IllegalStateException("..."); } }
createExtension 方法的逻辑稍复杂一下，包含了如下的步骤：
- 通过 getExtensionClasses 获取所有的拓展类
- 通过反射创建拓展对象
- 向拓展对象中注入依赖
- 将拓展对象包裹在相应的 Wrapper 对象中
以上步骤中，第一个步骤是加载拓展类的关键，第三和第四个步骤是 Dubbo IOC 与 AOP 的具体实现。由于此类设计源码较多，这里简单的总结下ExtensionLoader整个执行逻辑：
getExtension(String name) #根据key获取拓展对象 -->createExtension(String name) #创建拓展实例 -->getExtensionClasses #根据路径获取所有的拓展类 -->loadExtensionClasses #加载拓展类 -->cacheDefaultExtensionName #解析@SPI注解 -->loadDirectory #方法加载指定文件夹配置文件 -->loadResource #加载资源 -->loadClass #加载类，并通过 loadClass 方法对类进行缓存
