关于Java SPI的原理和实践

待我称王封你为后i 2024-03-26 14:29 33阅读 0赞

在Java中，我们经常会提到面向接口编程，这样减少了模块之间的耦合，更加灵活。

在一个项目中我们也通常将接口和实现类放在一起，但是如果哪天我们要替换其它的实现类，或者是修改实现类，涉及到实现类的代码也要相应地修改。

能不能这样：在调用服务的时候，我们只调用接口，不用关心实现类呢？无论我们怎么切换实现类，调用接口的部分代码都能正常运行？

当然是可以的，Java SPI (`Service Provider Interface`)就提供了这样的机制。

Java SPI机制中，我们**不再是手动指定接口和实现类的关系，而是让接口去寻找可用的实现类**。

事实上，我们经常使用的Spring框架、日志接口等等，都是使用了SPI机制实现了扩展。

### 1，`SPI`和`API` ###

在说起`SPI`之前，我们还是先看一下`API`，`API`我们已经很熟悉了，和`SPI`都可以被称作**接口**。

只不过`API`的**功能的实现，以及接口的定义全部是接口的实现者提供的**，调用者只需要调用接口即可：

![25d37e31f1a2413297e6dd90d90d4fd7.png][]

不过`SPI`就不一样了，在`SPI`机制中，**调用者仍然是调用接口，但是这个接口是独立存在的**，并且**可以由不同的实现者实现**：

![3efcc0d472394dfda97a389e187321a5.png][]

也就是说，这里接口只是一个标准，并且提供接口的那一方并不一定回去实现接口，而是根据接口的定义，由更多的第三方实现。

这个接口可以**由一个甚至是多个实现者去实现**。也因此，**调用者在调用接口时，可能还需要指定一下使用哪个实现者的实现类**。

> 实现者也叫做**服务提供者**。

事实上，我们日常生活中经常使用的U盘也很类似`SPI`机制，U盘使用的是USB接口，USB接口仅仅是一个规范（接口），但是发明USB接口的公司并没有去生产U盘，而是由不同的U盘厂商例如金士顿、闪迪（实现者）等等去根据这个规范生产U盘，然后我们就可以去选择自己喜欢的牌子（选择实现者）购买U盘，不过平时无论使用什么牌子的U盘，我们只需要插入到电脑的USB接口（调用接口）即可使用，而不用关心不同的厂商是怎么实现USB接口的功能的。

可见，`SPI`机制将实现者和接口再次解耦合了，使得接口更加易于扩展。

事实上，我们常常用的`SLF4J`就是一个Java的日志接口，但是它也仅仅是一个接口，所以被称作**门面**。而它的实现有`Logback`、`Log4j`等等，并且在切换实现的时候，我们只需要修改一下依赖配置即可，代码并不需要任何变动，因为代码中也仅仅是调用了接口。

### 2，自己完成一个`SPI` ###

那么现在，我们也来以一个最简单的日志接口为例，实现自己的`SPI`。

#### (1) 定义`SPI`接口 ####

先新建一个空的Maven项目`log-interface`，然后在里面创建一个日志接口，声明日志接口具备的方法（功能）：

package com.gitee.swsk33.loginterface.spi;
    
    /**
     * 定义日志接口
     */
    public interface Logger {
    
    	/**
    	 * INFO级别日志方法
    	 *
    	 * @param message 日志打印消息
    	 */
    	void info(String message);
    
    	/**
    	 * DEBUG级别日志方法
    	 *
    	 * @param message 日志打印消息
    	 */
    	void debug(String message);
    
    }

这样，我们便定义了这么一个日志接口，并声明日志接口需要有`info`和`debug`这两个日志功能。

然后就是编写服务类，这个服务类是这里最为重要的地方，它的作用是**扫描所有实现了`Logger`接口的实现类并加载进来，然后供调用者去调用**。

先看代码：

package com.gitee.swsk33.loginterface.service;
    
    import com.gitee.swsk33.loginterface.spi.Logger;
    
    import java.util.ArrayList;
    import java.util.List;
    import java.util.ServiceLoader;
    
    /**
     * 服务，用于加载所有服务使用者的实现类，以及供外部调用
     * 该类为一个单例
     */
    public class LoggerService {
    
    	/**
    	 * 该类唯一单例
    	 */
    	private static final LoggerService LOGGER = new LoggerService();
    
    	/**
    	 * 默认的Logger实现类
    	 */
    	private final Logger defaultLogger;
    
    	/**
    	 * 所有的Logger实现类列表
    	 */
    	private final List<Logger> allLoggers = new ArrayList<>();
    
    	/**
    	 * 私有化构造器
    	 */
    	private LoggerService() {
    		// 加载全部Logger接口的实现类
    		ServiceLoader<Logger> loader = ServiceLoader.load(Logger.class);
    		// 将实现类放入我们的Logger实现类列表
    		for (Logger logger : loader) {
    			allLoggers.add(logger);
    		}
    		// 这里取出第一个作为默认实现类
    		if (!allLoggers.isEmpty()) {
    			defaultLogger = allLoggers.get(0);
    		} else {
    			defaultLogger = null;
    		}
    		System.out.println("加载到" + allLoggers.size() + "个服务实现！");
    	}
    
    	/**
    	 * 获取该服务类的唯一单例
    	 *
    	 * @return 该服务类的唯一单例
    	 */
    	public static LoggerService getInstance() {
    		return LOGGER;
    	}
    
    	/**
    	 * 调用默认的实现类的info日志打印方法
    	 *
    	 * @param message 消息
    	 */
    	public void info(String message) {
    		if (defaultLogger == null) {
    			System.err.println("没有找到实现了Logger接口的类！");
    			return;
    		}
    		defaultLogger.info(message);
    	}
    
    	/**
    	 * 调用默认的实现类的debug日志打印方法
    	 *
    	 * @param message 消息
    	 */
    	public void debug(String message) {
    		if (defaultLogger == null) {
    			System.err.println("没有找到实现了Logger接口的类！");
    			return;
    		}
    		defaultLogger.debug(message);
    	}
    
    }

首先这个类是一个单例的类，在构造器中，我们使用`ServiceLoader`这个类来将实现了`Logger`接口的所有类都扫描进来，并存入我们的实现类列表，然后我们取出列表中的第一个作为默认实现。

在下面我们定义了`info`和`debug`来完成对接口的默认实现类的调用。

最后，在项目目录下执行`mvn install`命令将其安装至本地Maven仓库，以便后续服务提供者引入并实现。

#### (2) 完成一个接口的实现 ####

现在再新建一个空的Maven项目`logservice-one`，并引入上面接口项目为依赖：

![26b5ac59f91c4ddda107f43dd9c225ed.png][]

然后编写实现类：

package com.gitee.swsk33.logserviceone.service;
    
    import com.gitee.swsk33.loginterface.spi.Logger;
    
    /**
     * Logger SPI的实现类
     */
    public class LogOne implements Logger {
    
    	@Override
    	public void info(String s) {
    		System.out.println("[LogOne INFO] " + s);
    	}
    
    	@Override
    	public void debug(String s) {
    		System.out.println("[LogOne DEBUG] " + s);
    	}
    
    }

然后在`resources`目录下创建目录`META-INF/services`，这个目录中是用于**声明该服务实现中有哪些实现类实现了什么接口**。

在这个目录下我们新建一个文件名为`com.gitee.swsk33.loginterface.spi.Logger`，文件中的内容为：

com.gitee.swsk33.logserviceone.service.LogOne

可见，该目录下**文件名**是**要实现的接口的全限定类名**（包名 + 类名），而文件中**内容**是**实现了该接口的实现类的全限定类名**。

大家参考这里的文件名及其中的内容，与我们上述的接口全限定类名、实现类全限定类名对比一下就知道了！

如果说这个项目中有多个类实现了`Logger`接口，那么我们都需要在文件中声明，一行一个实现类的全限定类名。

最终整个项目结构如下：

![084695d1c03d4c528803314276a981cf.png][]

同样地，最后记得在项目目录下执行`mvn install`命令将其安装至本地Maven仓库，以便调用者调用。

#### (3) 测试接口 ####

这里再新建一个Maven空项目`log-test`，作为接口的**调用者**，在依赖中**引入实现者**：

![e07a33155b874317a6b3c9b7008b3792.png][]

然后创建一个主类调用一下接口试试：

package com.gitee.swsk33.logtest;
    
    import com.gitee.swsk33.loginterface.service.LoggerService;
    
    public class Main {
    
    	private static final LoggerService LOGGER = LoggerService.getInstance();
    
    	public static void main(String[] args) {
    		LOGGER.info("测试info消息");
    		LOGGER.debug("测试debug消息");
    	}
    
    }

结果：

![caa0815402344e009468521782944bb3.png][]

可见，我们成功地调用了`Logger`接口中的方法。

> 通常调用者的依赖中可能会同时引入`SPI`接口依赖和服务提供者（实现）的依赖，这样也没问题，不过通常服务提供者本身就依赖于`SPI`接口，因此只引入服务提供者依赖，也会间接地引入`SPI`接口依赖，不影响我们调用`SPI`接口。

我们这里只有一个服务提供者`logservice-one`，如果说还有`logservice-two`等等多个服务提供者，我们只需要在依赖中更换一下即可，代码完全不需要改变。

也可见调用者在调用接口的时候，只需要关注接口就行了，不需要关心实现类。

### 3，再看`ServiceLoader` ###

可见在`SPI`接口中，我们使用`ServiceLoader`完成了对所有实现了`Logger`接口的类的扫描和加载，那么具体的过程是什么样的呢？

如果大家去查看这个类的源码，可以发现它实现了`Iterable`接口，这也说明我们可以通过迭代的方式去完成多个实现类的切换。

然后在其源码中，有这么一个常量定义：

static final String PREFIX = "META-INF/services/";

这就说明，`ServiceLoader`会去扫描服务提供者的`classpath`路径下的`META-INF/services`目录，来扫描哪些类实现了指定接口，而其静态方法`load`的参数，正是指定了被实现的接口。也因此我们要在服务提供者的项目的`resources`目录下创建这个目录并申明接口和对应实现类的全限定类名。

> 在Maven项目中，`resources`目录就对应的是`classpath`的根目录。

简而言之，`ServiceLoader`加载实现类的过程如下：

*  先是调用`load`方法并指定要扫描的接口
 *  然后扫描项目中`META-INF/services`目录，这包括调用者项目以及它所引入的所有依赖包中的`META-INF/services`目录下的声明
 *  扫描到所有实现类后，根据其类名，先判断是否跟`SPI`接口为同一类型，如果是则利用反射的方式将所有实现类实例化，加载进内存，并返回所有实现类的实例列表

可见，这就是JDK中`SPI`机制加载服务的大致过程，事实上，现在很多框架也利用`SPI`机制实现了灵活地扩展。

[25d37e31f1a2413297e6dd90d90d4fd7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c9e53163d58e4bdcbb86856fad6ec9c5.png
[3efcc0d472394dfda97a389e187321a5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/e1f0c459148f44b389d75c036b8f1df5.png
[26b5ac59f91c4ddda107f43dd9c225ed.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d2e4c22a9bf84349b0eb7186125299f8.png
[084695d1c03d4c528803314276a981cf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/d3a195db846b4c0d9176bff9b52024b5.png
[e07a33155b874317a6b3c9b7008b3792.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/c9927b15a8384eb1bac3ef1387c0dcd1.png
[caa0815402344e009468521782944bb3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/0e14e851562a42f4ab5a7e46fbc01424.png