dubbo源码分析2- SPI

在 Dubbo 中，SPI 贯穿在整个 Dubbo 的核心，所以把 Dubbo 里面用得比较多的 SPI 机制做一个详细的分析。

关于 Java SPI

了解 Dubbo 里面的 SPI 机制之前，我们先了解下 Java 提供的 SPI（service provider interface）机制，SPI 是 JDK 内置的一种服务提供发现机制。目前市面上有很多框架都是用它来做服务的扩展发现。简单来说，它是一种动态替换发现的机制。举个简单的例子，我们想在运行时动态给它添加实现，你只需要添加一个实现，然后把新的实现描述给 JDK 知道就行了。大家耳熟能详的如 JDBC、日志框架都有用到

image.png

实现 SPI 需要遵循的标准

实现一个标准的 SPI 发现机制：

• a.需要在 classpath 下创建一个目录，该目录命名必须是：META-INF/service
• b.在该目录下创建一个 properties 文件，该文件需要满足以下几个条件:

1. 文件名必须是扩展的接口的全路径名称
   2.文件内部描述的是该扩展接口的所有实现类
   3.文件的编码格式是 UTF-8

• c.通过 java.util.ServiceLoader 的加载机制来发现

  
  
  

  image.png

SPI 的实际应用

SPI 在很多地方有应用，可能大家都没有关注，最常用的就是 JDBC 驱动，我们来看看是怎么应用的
JDK 本身提供了数据访问的 api,在 java.sql 这个包里面

我们在连接数据库的时候，一定需要用到 java.sql.Driver 这个接口对吧。然后看了下 java.sql.Driver 的源码，发现Driver 并没有实现，而是提供了一套标准的 api 接口

因为我们在实际应用中用的比较多的是 mysql，所以我去 mysql 的包里面看到一个如下的目录结构

image.png

这个文件里面写的就是 mysql 的驱动实现。原来通过 SPI 机制把 java.sql.Driver 和 mysql 的驱动做了集成。这样就达到了各个数据库厂商自己去实现数据库连接，jdk 本身不关心你怎么实现。

SPI 的缺点

• 1. JDK 标准的 SPI 会一次性加载实例化扩展点的所有实现，什么意思呢？就是如果你在 META-INF/service 下的文件里面加了 N个实现类，那么 JDK 启动的时候都会一次性全部加载。那么如果有的扩展点实现初始化很耗时或者如果有些实现类并没有用到，那么会很浪费资源
• 2. 如果扩展点加载失败，会导致调用方报错，而且这个错误很难定位到是这个原因

Dubbo 优化后的 SPI 机制

基于 Dubbo SPI 的实现自己的扩展

Dubbo 的 SPI 扩展机制，有两个规则:

• 1. 需要在 resource 目录下配置 META-INF/dubbo 或者 META-INF/dubbo/internal 或者 META-INF/services，并基于 SPI 接口去创建一个文件

2. 文件名称和接口名称保持一致，文件内容和 SPI 有差异，内容是 KEY 对应 Value

Dubbo 针对的扩展点非常多，可以针对协议、拦截、集群、路由、负载均衡、序列化、容器… 几乎里面用到的所有功能，都可以实现自己的扩展，这个是 dubbo 比较强大的一点。

image.png

比如我们可以针对协议做一个扩展

1. 创建如下结构，添加 META-INF.dubbo 文件。类名和 Dubbo 提供的协议扩展点接口保持一致

   
   
   

   image.png

2. 创建 MyProtocol 协议类
   可以实现自己的协议，我们为了模拟协议产生了作用，修改一个端口

public class MyProtocol implements  Protocol {

    @Override
    public int getDefaultPort(){
        return "8888";
    }
}

3.在调用处执行如下代码

Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getExtension("myProtocol"); 
System.out.print(protocol.getDefaultPort);//输出为8888

4. 输出结果，可以看到运行结果，是执行的自定义的协议扩展点。

总的来说，思路和 SPI 是差不多。都是基于约定的路径下制定配置文件。目的，通过配置的方式轻松实现功能的扩展。
我们的猜想是，一定有一个地方通过读取指定路径下的所有文件进行 load。然后讲对应的结果保存到一个 map 中，key 对应为名称，value 对应为实现类。那么这个实现，一定就在 ExtensionLoader 中了。接下来我们就可以基于这个猜想去看看代码的实现。

Dubbo 的扩展点源码分析

在看它的实现代码之前，大家要思考一个问题，所谓的扩展点，就是通过指定目录下配置一个对应接口的实现类，然后程序会进行查找和解析，找到对应的扩展点。那么这里就涉及到两个问题：
1.怎么解析？
2.被加载的类如何存储和使用？

ExtensionLoader.getExtensionLoader.getExtension

我们从这段代码着手，去看看到底做了什么事情，能够通过这样一段代码实现扩展协议的查找和加载。

  @SuppressWarnings("unchecked")
    public static  ExtensionLoader getExtensionLoader(Class type) {
        if (type == null) {
            throw new IllegalArgumentException("Extension type == null");
        }
        if (!type.isInterface()) {
            throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
        }
        if (!withExtensionAnnotation(type)) {
            throw new IllegalArgumentException("Extension type (" + type +
                    ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() +
                    "!");
        }
        //初始化 ExtensionLoader 
        ExtensionLoader loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
        if (loader == null) {
            EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader(type));
            loader = (ExtensionLoader) EXTENSION_LOADERS.get(type);
        }
        return loader;
    }

实例化 ExtensionLoader

private ExtensionLoader(Class type) {
        this.type = type;
        objectFactory = (type == ExtensionFactory.class ? null : 
            ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }

如果当前的 type=ExtensionFactory,那么 objectFactory=null, 否则会创建一个自适应扩展点给到 objectFacotry,目前来说具体做什么咱们先不关心
objectFactory 在这里赋值了，并且是返回一个 AdaptiveExtension(). 这个暂时不展开，后面再分析

getExtension

接着分析getExtension方法，这个方法就是根据一个名字来获得一个对应类的实例，所以我们来猜想一下，回想一下前面配置的自定义协议，name 实际上就是 myprotocol，而返回的实现类应该就是 MyProtocol。

   public T getExtension(String name) {
        if (StringUtils.isEmpty(name)) {
            throw new IllegalArgumentException("Extension name == null");
        }
        if ("true".equals(name)) { //如果 name=true，表示返回一个默认的扩展点，思考一下什么是默认的？
            return getDefaultExtension();
        }
        Holder