java spi机制_搞懂dubbo的SPI扩展机制

引言

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。

在谈dubbo的SPI扩展机制之前，我们需要先了解下java原生的SPI机制，有助于我们更好的了解dubbo的SPI。

java原生的SPI

先上例子：

1. 定义接口Animal ：

public 

2. 编写2个实现类，Cat和Dog

public 

3. 接下来在 META-INF/services 文件夹下创建一个文件，名称为 Animal 的全限定名 com.sunnick.animal.Animal，文件内容为实现类的全限定的类名，如下：

com

4. 编写方法进行测试

public 

目录结构如下：

测试结果如下：

======this is SPI======
小狗飞奔～
小猫步走起来～

从测试结果可以看出，我们的两个实现类被成功的加载，并输出了相应的内容。但我们并没有在代码中显示指定Animal的类型，这就是java原生的SPI机制在发挥作用。

SPI机制如下：

SPI实际上是“接口+策略模式+配置文件”实现的动态加载机制。在系统设计中，模块之间通常基于接口编程，不直接显示指定实现类。一旦代码里指定了实现类，就无法在不修改代码的情况下替换为另一种实现。为了达到动态可插拔的效果，java提供了SPI以实现服务发现。

在上述例子中，通过ServiceLoader.load(Animal.class)方法动态加载Animal的实现类，通过追踪该方法的源码，发现程序会去读取META-INF/services目录下文件名为类名的配置文件（如上述例子中的META-INF/services/com.sunnick.animal.Animal文件），如下，其中PREFIX 常量值为”META-INF/services/”:

try 

然后再通过反射Class.forName()加载类对象，并用instance()方法将类实例化，从而完成了服务发现。

String 

许多常用的框架都使用SPI机制，如slf日志门面和log4j、logback等日志实现，jdbc的java,sql.Driver接口和各种数据库的connector的实现等。

dubbo的SPI使用

Dubbo 并未使用 Java SPI，而是重新实现了一套功能更强的 SPI 机制。Dubbo SPI 的相关逻辑被封装在了 ExtensionLoader 类中，通过 ExtensionLoader，我们可以加载指定的实现类。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路径下，配置内容如下:

dog=com.sunnick.animal.impl.Dog
cat=com.sunnick.animal.impl.Cat

与 Java SPI 实现类配置不同，Dubbo SPI 是通过键值对的方式进行配置，这样就可以按需加载指定的实现类。另外，在使用 Dubbo SPI 时，需要在 Animal接口上标注 @SPI 注解，Cat与Dog类不变。下面来演示 Dubbo SPI 的用法：

@SPI

编写测试方法：

public 

测试结果如下：

======dubbo SPI======
小猫步走起来～
小狗飞奔～

dubbo的SPI源码分析

Dubbo通过ExtensionLoader.getExtensionLoader(Animal.class).getExtension("cat")方法获取实例。该方法中，会先到缓存列表中获取实例，若未命中，则创建实例：

public 

创建实例过程如下，即createExtension()方法：

private 

获取所有的SPI配置文件，并解析配置文件中的键值对的方法getExtensionClasses()的源码如下:

private 

这里也是先检查缓存，若缓存未命中，则通过 synchronized 加锁。加锁后再次检查缓存，并判空。此时如果 classes 仍为 null，则通过 loadExtensionClasses 加载拓展类。下面分析 loadExtensionClasses 方法的逻辑。

private 

可以看出，最后调用了loadFile方法，该方法就是从指定的目录下读取指定的文件名，解析其内容，将键值对放入map中，其过程不在赘述。

以上就是dubbo的SPI加载实例的过程。

Dubbo SPI与原生SPI的对比

java原生SPI有以下几个缺点：

• 需要遍历所有的实现并实例化，无法只加载某个指定的实现类，加载机制不够灵活；
• 配置文件中没有给实现类命名，无法在程序中准确的引用它们；
• 没有使用缓存，每次调用load方法都需要重新加载

如果想使用Dubbo SPI，接口必须打上@SPI注解。相比之下，Dubbo SPI有以下几点改进：

• 配置文件改为键值对形式，可以获取任一实现类，而无需加载所有实现类，节约资源；
• 增加了缓存来存储实例，提高了读取的性能；

除此之外，dubbo SPI还提供了默认值的指定方式（例如可通过@SPI（“cat”）方式指定Animal的默认实现类为Cat）。同时dubbo SPI还提供了对IOC和AOP等高级功能的支持，以实现更多类型的扩展。

总结

SPI是一种服务发现机制，提供了动态发现实现类的能力，体现了分层解耦的思想。

在架构设计和代码编写过程中，模块之间应该针对接口编程，避免直接引用具体的实现类，可达到可插拔的效果。

Dubbo提供了增强版的SPI机制，在使用过程中，需要在接口上打上@SPI注解才能生效。

历史文章推荐：