Dubbo之SPI机制的实现原理和优势分析

Dubbo中SPI机制的实现原理和优势

确保系统的扩展性是我们开展架构设计工作的核心目标之一。实现扩展性的方法有很多，JDK 本身内置了一个 SPI（Service Provider Interface，服务提供者接口）机制，来帮开发人员动态加载各种不同的实现类，只要这些实现类遵循一定的开发规范即可。

另一方面，JDK 自带的 SPI 机制存在一定的缺陷，因此市面上有些框架对 JDK 中的 SPI 机制做了一些增强，这方面的代表性框架就是 Dubbo。

JDK 中的 SPI 机制解析

如果我们采用 JDK 中的 SPI，具体的开发工作会涉及三个步骤。

对于 SPI 的开发者而言，我们需要设计一个服务接口，然后根据业务场景提供不同的实现类，这是第一步。

接下来的第二步是关键，我们需要创建一个以服务接口命名的配置文件，并把这个文件放置到代码工程的 META-INF/services 目录下。请注意，在这个配置文件中，我们需要指定服务接口对应实现类的完整类名。通过这一步，我们可以得到了一个包含 SPI 类和配置的 jar 包。

最后，SPI 的使用者就可以加载这个 jar 包并找到其中的这个配置文件，并根据所配置的实现类完整类名对这些类进行实例化。

上图中的后面两个步骤实际上都是为了遵循 JDK 中 SPI 的实现机制而进行的配置工作。

为了实现对 SPI 实现类的动态记载，JDK 专门提供了一个 ServiceLoader 工具类，这个工具类的使用方法如下所示：

public static void main(String[] args) {
  ServiceLoader<LogProvider> loader = ServiceLoader.load(LogProvider.class);
  for (LogProvider provider : loader) {
   System.out.println(provider.getClass());
   provider.info(“testInfo”);
  }
}

这里有一个 LogProvider 接口，并通过 ServiceLoader 的 load 方法将这个接口所配置的实现类加载到内存中，从而可以方便地使用这些 SPI 实现类所提供的功能。

接下来，让我们来分析一下这个 ServiceLoader 工具类的实现原理。

ServiceLoader 本身实现了 JDK 中的 Iterable 接口，因此在上面的代码示例中，通过 ServiceLoader.load 方法我们获取的是一个迭代器，而底层则用到了 ServiceLoader.LazyIterator 这个迭代器类。

从命名上看，LazyIterator 是一个具备延迟加载机制的迭代器，它有 hasNextService 和 nexServicet 这两个核心方法。我们先来看 hasNextService 方法：

//配置文件路径
static final String PREFIX = "META-INF/services/";
private boolean hasNextService() {
    if (nextName != null) {
        return true;
    }
    if (configs == null) {
        // 通过 PREFIX 前缀与服务接口的名称，我们可以找到目标 SPI 配置文件
        String fullName = PREFIX + service.getName();
        // 加载配置文件
        if (loader == null)
            configs = ClassLoader.getSystemResources(fullName);
        else
            configs = loadejsr.getResouryIJnevKEKces(fullName);
    }
    // 对 SPI 配置文件进行遍历，并解析配置内容
    while ((pending == null) || !pending.hasNext()) {
        if (!configs.hasMoreElements()) {
            return false;
  China编程      }
        // 解析配置文件
        pending = parse(service, configs.nextElement());
 }
 // 更新 nextName 字段
    nextName = pending.next();
    return true;
}

可以看到，hasNextService 方法的核心作用是找到并解析配置文件。而接下来要展开的 nextService 方法则负责对所配置的类进行实例化，核心实现如下所示：

private S nextService() {
    String cn = nextName;
    nextName = null;
    // 加载 nextName 字段指定的类
 Class<?> c = Class.forName(cn, false, loader);
 // 检测类型
    if (!service.isAssignableFrom(c)) {
        fail(service, "Provider " + cn  + " not a subtype");
 }
 // 创建实现类的对象
 S p = service.cast(c.newInstance());
 // 缓存已创建的对象
 providers.put(cn, p);
    return p;
}

这里通过 newInstance 方法创建了目标实例，并将已创建的实例对象放到 providers 集合中进行缓存，从而提高访问效率。

Dubbo 中的 SPI 机制解析

为了实现框架自身的扩展性，Dubbo 也采用了类似 JDK 中 SPI 的设计思想，但提供了一套新的实现方式，并添加了一些扩展功能。

Dubbo 中与 SPI 机制相关的注解主要包括@SPI、@Adaptive 和@Activate，其中@SPI 注解提供了与 JDK 中 SPI 类似的功能。

这三个注解的应用场景各不相同，其中@SPI 注解为 Dubbo 提供了最基础的 SPI 机制，而@Adaptive 和@Activate 注解都是构建在这个注解之上，因此我们重点介绍@SPI 注解。如果在某个接口上添加了这个注解，那么 Dubbo 在运行过程中就会去查找接口对应的扩展点实现。

在 Dubbo 中，随处可以看到@SPI 注解的应用场景。

举个例子，Protocol 接口定义如下：

@SPI("dubbo")public interface Protocol

可以看到，在这个接口上使用的就是@SPI(“dubbo”) 注解。

请注意，在@SPI 注解中可以指定默认扩展点的名称，例如这里的“dubbo”用来表明在 Protocol 接口的所有实现类中，DubboProtocol 是它的默认实现。

有了 SPI 的定义，我们接下来看一看 Dubbo 中 SPI 配置信息的存储方式。我们已经知道，JDK 只会把 SPI 配置存放在 META-INF/services/这个目录下，而 Dubbo 则提供了三个类似这样的目录：

作为示例，我们继续围绕上面提到的 Protocol 接口展开讨论。

针对 Protocol 接口，Dubbo 提供了 gRPCProtocol、DubboProtocol 等多个实现类，并通过 SPI 机制完成对具体某种实现方案的加载过程。

让我们分别来到提供这些实现类的代码工程 dubbo-rpc-grpc 和 dubbo-rpc-dubbo，会发现在 META-INF/dubbo/internal/目录下都包含了一个 com.apache.dubbo.rpc.Protocol 配置文件。其中，dubbo-rpc-grpc 工程的代码结构如图所示：

类似的，dubbo-rpc-dubbo 工程的代码结构如下图所示：

我们分别打开这两个工程的 com.apache.dubbo.rpc.Protocol 配置文件，可以发现它们分别指向了 org.apache.dubbo.rpc.protocol.grpc.GrpcProtocol 和 org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol 类。

• //dubbo-rpc-grpc 工程：

grpc=org.apache.dubbo.rpc.protocol.grpc.GrpcProtocol

• //dubbo-rpc-dubbo 工程：

dubbo=org.apache.dubbo.rpc.protocol.dubbo.DubboProtocol

当 Dubbo 在引用具体某一个代码工程时，就可以通过这个工程中的配置项就可以找到 Dubbo 接口对应的扩展点实现。

同时，我们从上面配置项中也可以看出，Dubbo 中采用的定义方式与 JDK 中的不一样。Dubbo 使用的一个 Key 值（如上面的 gRPC 和 Dubbo）来指定具体的配置项名称，而不是采用完整类路径。

介绍完@SPI 注解，我们接下来看 Dubbo 中的 ExtensionLoader 类，这个类扮演着与 JDK 中 ServiceLoader 工具类相同的角色。

ExtensionLoader 是实现扩展点加载的核心类，如果我们想要获取 DubboProtocol 这个实现类，那么可以采用以下方式：

DubboProtocol dubboProtocol = ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(DubboProtocol.NAME);

我们来看一下这里 getExtension 方法的细节，这个方法代码如下所示：

public T getExtension(String name) {
     ...
     //从缓存中获取目标对象
        Holder<Object> holder = cachedInstances.get(name);
        if (holder == null) {
         //将目标对象放到缓存中
            cachedInstances.putIfAbsent(name, new Holder<Object>());
            holder www.chinasem.cn= cachedInstances.get(name);
        }
        Object instance = holder.get();
        if (instance == null) {
            synchronized (holder) {
                instance = holder.get();
                if (instance == null) {
                 //创建目标对象
                    instance = createExtension(name);
                    holder.set(instance);
                }
            }
        }
        return (T) instaphpnce;
}

我们看到这里同样用到了缓存机制。这个方法会首先检查缓存中是否已经存在扩展点实例，如果没有则通过 createExtension 方法进行创建。

我们一路跟踪 createExtension 方法，终于看到了熟悉的 SPI 机制，如下所示：

private Map<String, Class<?>> loadExtensionClasses() {
        final SPI defaultAnnotation = type.getAnnotation(SPI.class);
        if (defaultAnnotation != null) {
             //确定缓存名称
        }
        Map<String, Class<?>> extensionClasses = new HashMap<String, Class<?>>();
     //分别从三个目录中加载类实例
        loadFile(extensionClasses, DUBBO_INTERNAL_DIRECTORY);
        loadFile(extensionClasses, DUBBO_DIRECTORY);
        loadFile(extensionClasses, SERVICES_DIRECTORY);
        return extensionClasses;
}

在这里，我们调用了三次 loadFile 方法，分别在 META-INF/dubbo/、META-INF/services/和 META-INF/dubbo/internal/这三个目录中加载扩展点。在 loadFile 方法中，Dubbo 是直接通过 Class.forName 的形式加载这些 SPI 的扩展类，并进行缓存。

到这里，我们发现，为了提升实例类的加载速度，Dubbo 和 JDK 都采用了缓存机制，这是它们的一个共同点。但实际上，我们也已经可以梳理 Dubbo 中 SPI 机制与 JDK 中 SPI 机制的区别，核心有两点，就是 配置文件位置和 获取实现类的条件。

从加载 SPI 实例的配置文件位置来看，Dubbo 支持更多的加载路径。JDK 只能加载一个固定的 META-INF/services，而 Dubbo 有三个路径。

就获取实现类的条件而言，Dubbo 采用的是直接通过名称对应的 Key 值来定位具体实现类，而 ServiceLoader 内部使用的是一个迭代器，在获取目标接口的实现类时，只能通过遍历的方式把配置文件中的类全部加载并实例化，显然这样效率比较低下。

简单来说，Dubbo 没有直接沿用 JDK SPI 机制，而是自己实现一套的主要目的就是克服这种效率低下的情况，并提供了更多的灵活性。

总结

从 Dubbo 配置项的定义中发现，Dubbo 采用了与 JDK 不同的实现机制。虽然 Dubbo 也采用了 SPI 机制，也是从 jar 包中动态加载实现类，但它的实现方式与 JDK 中基于 ServiceLoader 是不一样的。于是，详细分析了 JDK 和 Dubbo 在 SPI 机制设计和实现上的差异，并阐明了 Dubbo 内部的实现原理和所具备的优势。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持China编程(www.chinasem.cn)。