Dubbo源码分析之 SPI（一）

一、概述

    dubbo SPI 在dubbo的作用是基础性的，要想分析研究dubbo的实现原理、dubbo源码，都绕不过 dubbo SPI，掌握dubbo SPI 是征服dubbo的必经之路。

    本篇文章会详细介绍dubbo SPI相关的内容，通过源码分析，目标是让读者能通过本篇文章，彻底征服dubbo SPI。

    文章的组织方式是先介绍SPI 的概念，通过Java SPI 让大家了解SPI 是什么，怎么用，有一个初步的概念，dubbo的SPI是扩展了Java SPI的内容，自己实现了一个SPI。

二、SPI概念介绍

    SPI全称 Service Provider Interface，是一种服务发现机制。我们编程实现一个功能时，经常先抽象一个interface，内部再定一些方法。具体的实现交给 implments了此接口的类，实现了功能和实现类的分离。

    我们设想一下，如果一个描述汽车功能的interface  Car，存在多个实现类BMW、Benz、Volvo，某个场景调用Car的行驶方法，程序就需要确认到底是需要BMW、Benz、Volvo中的那个类对象。如果硬编码到程序中，固然可以，但是出现了接口和实现类的耦合，缺点也显而易见。

    有办法做到在调用代码中不涉及BMW、Benz、Volvo字符，也随意的指定实现类么？当然，SPI就是解决这个问题。

    SPI的实现方式是，在指定的路径下增加一个文本文件，文件的名称是interface的全限定名(包名+接口名)，文件内容每行是一个此接口的实现类的全限定名，多个实现类就会有多行。接口进行调用时，根据接口全限定名，先读取文本文件，解析出具体的实现类，通过反射进行实例化，再调用之。如果增加新的实现类，不需要修改调用代码，只需要在文本文件中增加一行实现类的全限定名即可，删除实现类同理。

三、Java SPI 介绍

    我们先看看Java的SPI怎么实现的，通过一个demo，进行了解。

    先定一个小车的接口，有一个方法 goBeijing()：

1 package cn.hui.spi
2 //Car 接口
3 public interface Car {
4 
5     // 开车去北京
6     void goBeijing();
7 
8 }

    我们建三个实现类：

    

 1 package cn.hui.spi.impl;
 2 public class Bmw implements Car{
 3     @Override
 4     public void goBeijing() {
 5         // TODO Auto-generated method stub
 6         System.out.println("开着宝马去北京......");
 7     }
 8 }
 9 
10 package cn.hui.spi.impl;
11 public class Benz implements Car{
12     @Override
13     public void goBeijing() {
14         // TODO Auto-generated method stub
15         System.out.println("开着奔驰去北京........");
16     }
17 }
18 
19 package cn.hui.spi.impl;
20 public class Volvo implements Car {
21     @Override
22     public void goBeijing() {
23         // TODO Auto-generated method stub
24         System.out.println("开着沃尔沃去北京......");
25     }
26 }

    我们在 "META-INF/services" 文件夹下新建一个文件，名称为“cn.hui.spi.Car"，文件内容：

    

1 cn.hui.spi.impl.Bmw
2 cn.hui.spi.impl.Benz
3 cn.hui.spi.impl.Volvo

     方法调用的代码如下：

    

 1 import java.util.Iterator;
 2 import java.util.ServiceLoader;
 3 public class App {
 4     
 5     public static void main(String[] args) {
 6         ServiceLoader serviceLoader = ServiceLoader.load(Car.class);
 7         Iterator iterator = serviceLoader.iterator();
 8         while(iterator.hasNext()) {
 9             Car car = iterator.next();
10             car.goBeijing();
11         }
12     }
13 }

    打印结果：

1 开着宝马去北京......
2 开着奔驰去北京........
3 开着沃尔沃去北京......

    这个就是Java SPI简单实现方式。

三、Dubbo SPI介绍

    dubbo 在Java SPI的基础上进行了功能扩展，我们再看上面的Java SPI示例，可以发现很明显的问题，对文本文件的加载后，实例化对象是一次性全部进行实例化，得到一个实现类的对象集合，调用的时候循环执行。不能唯一指定一个实现类进行唯一调用。dubbo通过在文本文件中指定每个实现类的key，唯一标识出每个实现类，调用的时候可以指定唯一的一个实现类。同样实例化也不需要一次性全部实例化了，只需要实例化需要调用的类即可。

     同时dubbo还实现了IOC和AOP的功能，接口的实现类之间可以进行相互的注入，了解Spring的同学，应该很清楚IOC和AOP的逻辑，下面我们现在熟悉下dubbo SPI的相关概念，之后在通过一个简单的样例，了解dubbo SPI 的使用。

四、Dubbo SPI关键点

    dubbo SPI的功能主要是通过ExtensionLoader类实现，dubbo启动时，默认扫描三个目录：META-INF/services/、META-INF/dubbo/、META-INF/internal/，在这三个目录下的文本文件都会加载解析，文本文件的内容：key=实现类的全限定名。

    dubbo把接口定义为 扩展点，实现类定义为 扩展点实现，所有的扩展点（接口）需要进行@SPI注解，更多的功能和注解我们逐步介绍。

    dubbo在启动的时候扫描文本文件，对文件内容进行解析，但是不会全部进行实例化，只有在调用到具体的扩展点实现时，才会进行特定扩展点的实例化。

    同时dubbo SPI提供自适应扩展、默认扩展、自动激活扩展等功能，我们后面介绍。

五、Dubbo SPI示例

    我们把上面Car接口的例子，改造成基于dubbo SPI的实现。进行配置的文本文件内容。

    在扩展点实现类前都加上key，改为：

1 bmw=cn.hui.spi.impl.Bmw
2 benz=cn.hui.spi.impl.Benz
3 volvo=cn.hui.spi.impl.Volvo

 Car接口改造为：

1 @SPI
2 public interface Car {
3     // 开车去北京
4     void goBeijing();
5 }

扩展点，暂时不做修改，我们看看调用方法：

 1 public class App {
 2     public static void main(String[] args) {
 3         Car car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("bmw");
 4         car.goBeijing();
 5         car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("benz");
 6         car.goBeijing();
 7         car = ExtensionLoader.getExtensionLoader(Car.class).getExtension("volvo");
 8         car.goBeijing();
 9     }
10 }

此时，控制台会出现：

1 开着宝马去北京......
2 开着奔驰去北京........
3 开着沃尔沃去北京......

这个就是简单dubbo使用，复杂的功能我们放到源码分析的时候进行。

六、Dubbo SPI 源码分析

    dubbo SPI的功能主要几种在ExtensionLoader类中实现，分析源码也就主要分析此类，我们通过ExtensionLoader对外提供的方法作为入口进行源码分析。

    需要注意：一个type接口对应一个ExtensionLoader 实例。

    上面的示例中，我们通过 getExtensionLoader(..)方法，获得ExtensionLoader实例，ExtensionLoader类的构造方法是私有的，只能通过此方法获取实例。

    我们先看看此方法：

 1 @SuppressWarnings("unchecked")
 2 public static  ExtensionLoader getExtensionLoader(Class type) {
 3     if (type == null) {
 4         throw new IllegalArgumentException("Extension type == null");
 5     }
 6     // 必须是接口
 7     if (!type.isInterface()) {
 8         throw new IllegalArgumentException("Extension type(" + type + ") is not interface!");
 9     }
10     // 必须被@SPI注解
11     if (!withExtensionAnnotation(type)) {
12         throw new IllegalArgumentException("Extension type(" + type + ") is not extension, because WITHOUT @" + SPI.class.getSimpleName() + " Annotation!");
13     }
14     // extension_loaders 为成员变量，是 type---> ExtensionLoader 实例的缓存
15     ExtensionLoader loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
16     if (loader == null) {
17         // putIfAbsent put不覆盖
18         EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader(type));
19         loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
20     }
21     return loader;
22 }

我们看到该方法主要是先对type进行校验，再根据type为key，从缓存EXTENSION_LOADERS中获取ExtensionLoader实例，如果缓存没有，则新建一个ExtensionLoader实例，并放入缓存。
注意，我们说过一个type对应一个ExtensionLoader实例，为什么还需要缓存呢，我们再看看 EXTENSION_LOADERS的定义：

// 扩展点接口和对应ExtensionLoader实例的缓存
private static final ConcurrentMap, ExtensionLoader> EXTENSION_LOADERS = new ConcurrentHashMap, ExtensionLoader>();

没错，EXTENSION_LOADERS 是一个static、final修饰的类静态变量。

我们接着看上面，看一下ExtensionLoader的构造方法：

 1 private ExtensionLoader(Class type) {
 2     this.type = type;
 3     // type 为ExtensionFactory时，objectFactory为空
 4     if (type == ExtensionFactory.class) {
 5         objectFactory = null;
 6     } else {
 7         // type为普通接口时，objectFactory为AdaptiveExtensionFactory，负责dubbo spi 的IOC 功能
 8         objectFactory = ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension();
 9     }
10 //        objectFactory = (type == ExtensionFactory.class ? null
11 //                : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
12 }

构造方法私有，不能直接在外部new出实例。

方法内部，参数type赋值给成员变量type，还会进行ExtensionFactory类判断，ExtensionFactory是实现IOC功能的，我们此处暂时绕过，后面进行介绍。
我们总结一下getExtensionLoader(..)方法，绕开ExtensionFactory，就是new 了一个ExtensionLoader对象实例，为成员变量type赋值为扩展点type，对象实例放入EXTENSION_LOADERS 缓存中。
现在我们有了ExtensionLoader实例对象，我们再看看获取type实例的方法：getExtension(..)：

 1 @SuppressWarnings("unchecked")
 2 public T getExtension(String name) {
 3     if (name == null || name.length() == 0)
 4         throw new IllegalArgumentException("Extension name == null");
 5     if ("true".equals(name)) {
 6         // 获取默认的扩展实现类
 7         return getDefaultExtension();
 8     }
 9     // Holder仅用于持有目标对象，没有其他逻辑
10     Holder