Dubbo学习笔记(二) SPI

1. Java SPI

1.1 概念

SPI全称是Service Provider Interface，是JDK内置的一种服务提供发现功能，一种动态替换发现的机制。

1.2 规范

使用SPI需要遵循下面的规范：

• 设置META-INF目录，并在下面新建一个services目录

• 在上面创建的目录下，放置配置文件

• 使用ServiceLoad.load()方法进行加载

1.3 示例

首先新建一个maven项目，结构如下：

1572792821854.png

下面分步骤进行描述。

首先新建一个HelloService接口：

public interface HelloInterface {
    public void sayHello();
}

以及该接口的两个实例：

public class ImageHello implements HelloInterface {
    public void sayHello() {
        System.out.println("Image hello!");
    }
}

public class TextHello implements HelloInterface {
    public void sayHello() {
        System.out.println("Text hello");
    }
}

然后在resources目录下的META-INF.services目录下新建一个配置文件，文件名要求是接口全路径名，内容是要实现的接口实现类：

com.spiexample.impl.ImageHello
com.spiexample.impl.TextHello

并且文件是UTF-8编码的。

最后在SPIMain这个启动类中进行测试：

public class SPIMain {
    public static void main(String[] args){
        ServiceLoader serviceLoader = ServiceLoader.load(HelloInterface.class);
        if (serviceLoader != null){
            for(HelloInterface helloInterface : serviceLoader){
                helloInterface.sayHello();
            }
        }
    }
}

最终输出结果为：

Image hello!
Text hello

说明已经成功创建出接口的两个实现类的对象并执行方法了。

2. Dubbo SPI

2.1 介绍

Dubbo SPI相比于Java SPI而言，做了一定的优化和改进。JDK标准的SPI会一次性实例化扩展点所有实现，如果有扩展实现则初始化很耗时，如果没有用上也加载，则浪费资源。如第一小节的例子中，HelloInterface接口有很多实现类，ServiceLoader.load方法返回的serviceLoader对象中封装了所有实现类的实例。所以ServiceLoader实现了Iterable接口，以遍历出所有的实现类。

Dubbo SPI则不然，它只加载配置文件中的类，并分成不同的种类缓存在内存中，而不会全部初始化，在性能上有更好的表现。

下面是一个例子，在第一小节的例子上通过Dubbo SPI进行改进。

2.2 示例

首先修改接口类：

@SPI("impl")
public interface HelloInterface {
    public void sayHello();
}

添加了一个注解，并且设置属性为impl，表示接口默认实现为impl。

@SPI注解：

当该注解标记在接口上时，表示这是一个Dubbo SPI接口，即是一个扩展点。SPI注解有一个value属性，通过这个属性，我们可以传入不同的参数来设置这个接口的默认实现类。

然后再定义一个这个接口的实现类：

public class NewHello implements HelloInterface {
    public void sayHello() {
        System.out.println("new hello!");
    }
}

然后在META-INF目录下新建一个dubbo目录，再新建一个配置文件，文件名也是要求是接口HelloInterface的全路径名，内容是：

impl=com.spiexample.impl.NewHello

impl即对应了接口的一个实现类。

写完这些后，最后main方法中调用如下：

HelloInterface helloInterface = ExtensionLoader.
  getExtensionLoader(HelloInterface.class).
  getDefaultExtension();
helloInterface.sayHello();

最终就成功打印new hello，说明调用实例的就是指定的NewHello。

2.3 规范

Dubbo SPI兼容了Java SPI的配置路径和内容配置方式。在Dubbo启动的时候，会默认扫这三个目录下的配置文件：META-INF/services/,META-INF/dubbo/,META-INF/dubbo/internal/。

3. 扩展点的特性

扩展类一共包含四种特性：自动包装，自动加载，自适应和自动激活。

3.1 自适应

在第二小节中提到，Dubbo通过@SPI("impl")注解中的属性来明确默认使用接口的哪个实现类，那如果实际场景中某些条件使用实现类A，其他条件使用实现类B呢？这种灵活的场景再直接硬编码写死就不合适了。为此下面再看下Dubbo提供的另外一个注解Adaptive，它实现了Dubbo扩展点的一个特性：自适应。

3.1.1 示例

这个注解一般声明在接口的方法上。下面在第二节的示例基础上进行修改。

首先还是定义接口：

@SPI
public interface HelloInterface {
  @Adaptive({"key"})  
  void printInfo(URL url);
}

其中：

• SPI注解上没有设置默认值了

• 方法定义上加了一个Adaptive注解，该注解可以传入多个字符串，表示的参数的名字

• 方法传入了参数，类型为URL。这个URL不是我们常用的那个URL，而是Dubbo自定义的一个类。那这个类有什么用呢？实际上，某一个接口有多个实现类的时候，就是通过往URL里面传参数，来指定我们想调用哪个实现类的该方法的。口说无凭，下面继续看。

之前我们定义了HelloInterface接口的一个实现类，名为NewHello，下面再定义一个：

public class NewHello2 implements HelloInterface {
    public void sayHello() {
        System.out.println("new hello2!");
    }
}

同样的，在dubbo配置文件中加上这个实现类的配置：

impl=com.spiexample.impl.NewHello
impl2=com.spiexample.impl.NewHello2

最后，写一个main方法进行测试：

URL url = URL.valueOf("test://localhost/test").
  addParameter("key","impl2");

HelloInterface helloInterface = ExtensionLoader.
  getExtensionLoader(HelloInterface.class).
  getAdaptiveExtension();
helloInterface.sayHello();

可以看到：

• 在URL中传入参数key，它的值设置为impl2，因此最后执行helloInterface.sayHello()的时候，实际执行的就是NewHello2.sayHello()。
• 要注意上述代码中获取接口实例是通过调用ExtensionLoader类的getAdaptiveExtension()方法，而不是第二小节的getDefaultExtension()方法。这里涉及到一个概念，叫Dubbo扩展点的自适应特性，这个特性在上述代码中也很好的体现出来了，就是通过Adaptive注解，可以动态地通过URL中的参数来确定要使用的是哪个具体的实现类。

3.2 自动包装

自动包装是Dubbo扩展点的另外一个特性，这个特性实现了装饰器设计模式（关于装饰器模式的思想，可以看另一篇博客的介绍）。

3.2.1 装饰器模式

装饰器模式的编程范式如下：

public class XxxWrapper implements Xxx {
    private Xxx xxx;

  public XxxWrapper(Xxx xxx){
    this.xxx = xxx;
  }
    
  @Override
  ... // 重写的方法
}

装饰器模式最重要的特点就是：构造函数的入参和要实现的接口类型一致。

3.2.2 示例

下面我们在前面的示例基础上修改，体验下这个自动包装是如何实现装饰器模式的。

首先添加一个装饰器类：

public class HelloInterfaceWrapper implements HelloInterface {

    private HelloInterface helloInterface;

    public HelloInterfaceWrapper(HelloInterface helloInterface){
        this.helloInterface = helloInterface;
    }

    @Override
    public void sayHello(URL url) {
        System.out.println("start print");
        helloInterface.sayHello(url);
        System.out.println("end print");
    }
}

一般如果没有使用dubbo的时候，如果想使用上面这个wrapper类来实现一个装饰器模式的时候，首先要做的就是注入一个接口的实现类，然后调用具体的方法的时候，就可以通过这个wrapper类在方法前后做一些额外的操作，实现类似于切面的效果。引入了Dubbo之后，就不需要自己手动注入这个接口实现类了，而是自动注入的。

为了实现自动包装，还是得把这个Wrapper类定义到dubbo的配置文件中：

impl=com.spiexample.impl.NewHello
impl2=com.spiexample.impl.NewHello
common=com.spiexample.impl.XxxWrapper

这样这个接口就有三个实现类了。

最后再把第三小节示例的main方法原样拷贝过来：

URL url = URL.valueOf("test://localhost/test").
  addParameter("key","impl2");

HelloInterface helloInterface = ExtensionLoader.
  getExtensionLoader(HelloInterface.class).
  getAdaptiveExtension();
helloInterface.sayHello();

最终输入如下：

start print
hello world2
end print

可以看到，在hello的前后都打印了start和end，说明先执行了Wrapper类，里面包含了我们指定的imp2对应的那个类。这个就是扩展点的自动包装功能：自动扫描配置文件中定义的类是否是Wrapper类，是的话就用其对实际要调用的类进行自动包装。

3.3 自动加载

我们知道Spring依赖注入有构造注入和属性注入等形式。上一小节提到了，Dubbo通过自动包装来实现构造注入，将一个扩展类注入到另一个扩展类中。那除了构造注入外，同样也有属性注入的形式，这种特性在Dubbo中可称为扩展点的自动加载。

下面对前一小节的包装类进行修改如下：

public class HelloInterfaceWrapper implements HelloInterface {

    private HelloInterface helloInterface;
  
    public void setHelloInterface(HelloInterface helloInterface) {
        this.helloInterface = helloInterface;
    }

    @Override
    public void sayHello(URL url) {
        System.out.println("start print");
        helloInterface.sayHello(url);
        System.out.println("end print");
    }
}

修改后，删除了构造函数，只写了一个setter方法，其他代码都不用调整，当main方法调用seyHello方法时发现，最终效果和前面自动包装实现的效果是一样的，这就说明自动加载（我更喜欢称为属性注入）成功了。

3.4 自动激活

@Activate注解可以标记在类，接口，枚举类和方法上。主要使用在有多个扩展点实现，需要根据不同条件被激活的场景中。

如我们使用过滤器都是多个同时使用，即Filter需要多个同时激活，因为每个Filter实现的是不同的功能：

// 无条件自动激活
@Activate
public class XxxFilter implements Filter {
    // ...
}

// 当配置了xxx参数，并且参数为有效值时激活，比如配了cache="lru"，自动激活CacheFilter
@Activate(cache="lru")
public class CacheFilter implements Filter {
    // ...
}

// 只对提供方激活，group可选"provider"或"consumer",用这个说明应用已经注册到Dubbo注册中心了
@Activate(group = "provider", value = "xxx")
public class XxxFilter implements Filter {
    // ...
}

定义好扩展类后，就可以通过下面的形式进行获取：

URL url = URL.valueOf("test://localhost/test");
url = url.addParameter("cache", "lru");

// 指明了使用参数cache=lru,group=provider的扩展类
List filters = ExtensionLoader.
  getExtensionLoader(Filter.class).
  getActivateExtension(url,new String[]{},"provider");

可以看到此时返回的扩展类实例是List形式的，即多个的。

4. ExtensionLoader原理

ExtensionLoader是扩展机制的主要逻辑类，前面说到获取扩展类有下面三种方式：

ExtensionLoader.getExtensionLoader(HelloInterface.class).getDefaultExtension();

ExtensionLoader.getExtensionLoader(HelloInterface.class).getAdaptiveExtension();

ExtensionLoader.getExtensionLoader(HelloInterface.class).getActivateExtension();

下面就详细讲解getDefaultExtension,getAdaptiveExtension,getActivateExtension这个三个方法的实现。

4.1 getDefaultExtension

该方法源码如下：

public T getDefaultExtension() {
  this.getExtensionClasses();
  return !StringUtils.isBlank(this.cachedDefaultName) && !"true".equals(this.cachedDefaultName) ? this.getExtension(this.cachedDefaultName) : null;
}

可以看到该方法判断cachedDefaultName变量，进而判断是否调用getExtension方法。在第二小节使用getDefaultExtension方法的示例中，我们给方法添加了SPI注解：

@SPI("impl")
public interface HelloInterface {
    public void sayHello();
}

并且在配置文件中定义：

impl=com.spiexample.impl.NewHello

Dubbo在初始化的时候，会自动扫描带有SPI注解的接口，并且根据注解中指定的参数在配置文件中找到默认要加载的类，并将该类名赋值给cachedDefaultName上。

所以getDefaultExtension方法的关键还是在getExtension方法上。下面就看下该方法的实现：

public T getExtension(String name) {
  if (StringUtils.isEmpty(name)) {
    throw new IllegalArgumentException("Extension name == null");
  } else if ("true".equals(name)) {
    return this.getDefaultExtension();
  } else {
    Holder