Java SPI 和 API 一文彻底帮你搞清？

qq_25073223

已于 2022-05-09 12:40:02 修改

阅读量370

点赞数

分类专栏： java 文章标签： java

于 2022-05-09 12:39:19 首次发布

本文链接：https://blog.csdn.net/qq_25073223/article/details/124663706

版权

java 专栏收录该内容

1373 篇文章 22 订阅

订阅专栏

最近新写了一个中间件「运行时动态日志等级开关」，其中使用 Java SPI 机制实现了自定义配置中心，保证良好的扩展性。

在使用过程中，突然发现 SPI 其实和日常写 API 接口，然后进行 implements 实现非常相似，那 SPI 到底和普通 API 实现有啥区别呢？带着这个问题，我们一起来梳理下 SPI 机制吧。

下文笔者将着重讲述SPI和API的相关简介说明

什么是 SPI 机制？
SPI 实践案例
SPI 和 API 有啥区别？

1、什么是 SPI 机制？

SPI（Service Provider Interface）字面意思是服务提供者接口，本质上是一种「服务扩展机制」。

为什么需要这样一种「服务扩展机制」呢？

因为系统里抽象的各个模块，比如日志模块、xml 解析模块、jdbc 模块等，往往有很多不同的实现方案。

为了满足可拔插的原则，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。这就需要一种「服务扩展机制」，然后就有了 SPI。

SPI 机制为我们的程序提供拓展功能。而不必将框架的一些实现类写死在代码里面。我们在相应配置文件中定义好某个接口的实现类全限定名，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。

最常见的就是 Java 的 SPI 机制，另外，还有 Dubbo 和 SpringBoot 自定义的 SPI 机制。

2、SPI 实践案例

2.1 业界 SPI 实践案例

简单了解了 SPI 的概念，我们看看业界有哪些 SPI 实践案例，如何利用 SPI 实现灵活扩展的。

JDBC 驱动加载

最常见的 SPI 机制实践案例就是 JDBC 的驱动加载。利用 Java 的 SPI 机制，我们可以根据不同的数据库厂商来引入不同的 JDBC 驱动包。

SpringBoot 的 SPI 机制

用过 SpringBoot 的同学应该都知道，我们可以在 spring.factories 中加上我们自定义的自动配置类，这个特性尤其在 xxx-starter 中应用广泛。

Dubbo 的 SPI 机制

Dubbo 基本上自身的每个功能点都提供了扩展点，把 SPI 机制应用的淋漓尽致，比如提供了集群扩展、路由扩展和负载均衡扩展等差不多接近 30 个扩展点。
如果 Dubbo 的某个内置实现不符合我们的需求，那么我们只要利用其 SPI 机制将我们的实现替换掉 Dubbo 的实现即可。

2.2 在实际项目中如何使用

以上三个例子是业界最常见的 SPI 机制的实现。下面，来看看我在实际项目中如何利用 Java SPI 机制实现了自定义配置中心，保证良好的扩展性

需求很简单，中间件「运行时动态日志等级开关」需要在应用运行时获取开关状态，然后动态改变应用日志等级。

如何获取开关状态呢？我们一般需要配置中心来进行处理。作为一个开源中间件，使用它的应用可能有自己的不同的配置中心（比如 Nacos、Apollo、spring cloud config、自研配置中心等），因此，必须支持自定义配置中心接入。

这时候就需要 SPI 机制来实现了！

1）定义接口 interface

package io.github.java265.log.level.sw.listener;

public interface ConfigListener<T> {
    /**
     * 获取初始开关状态
     * @return initial context of switch
     */
    SwitchContext getInitSwitch();

    /**
     * 获取变化的配置
     * @param changedConfig changed config context
     */
    void listenChangedConfig(T changedConfig);
}

2）SPI 加载

本项目通过 Java SPI 实现，不需要依赖额外的组件，通过 ServiceLoader 来动态加载

public class ChangeListenerFactory {
    public static ConfigListener getListener() {
        final ServiceLoader<ConfigListener> loader = ServiceLoader.load(ConfigListener.class);
        for (ConfigListener configListener : loader) {
            return configListener;
        }
        throw new IllegalArgumentException("please choose valid listener");
    }
}

3）应用自定义配置中心接入

使用这个中间件的应用，只需要三步即可接入自定义配置中心。

STEP 1: 应用中 pom 引入依赖

STEP 2: 构建 config Bean

@Configuration
public class LogLevelSwitchConfig {
    @Bean
    LogLevelSwitch logLevelSwitch() {
        return new LogLevelSwitch();
    }
}

STEP 3: 接入配置中心

声明配置中心的 SPI 实现。

在 resource 路径下新建 META-INF/services，创建文件名为

io.github.java265.log.level.sw.listener.ConfigListener 的文件，并写入自定义配置中心的「实现类名」。

3、SPI 和 API 有啥区别？

我们已经介绍了什么是 SPI，怎么使用 SPI 机制，现在，回头来看看一开始提出的问题，SPI 和 API 有啥区别呢？

它们都需要定义接口 interface，然后自定义实现类 implements，看起来基本一致呀。

区别在哪？各自的使用场景是啥？

别急，我们从头梳理一下。

从「面向接口编程」的思想来看，「调用方」应该通过调用「接口」而不是「具体实现」来处理逻辑。那么，对于「接口」的定义，应该在「调用方」还是「实现方」呢？

理论上来说，会有三种选择：

「接口」定义在「实现方」
「接口」定义在「调用方」
「接口」定义在独立的包中

1)「接口」定义在「实现方」

先来看看「接口」定义在「实现方」的情况。这个很容易理解，实现方同时提供了「接口」和「实现类」，「调用方」可以引用接口来达到调用某实现类的功能，这就是我们日常使用的 API。API 的最显著特征就是：

实现和接口在一个包中。自己定义接口，自己实现类。

2)「接口」定义在「调用方」

再来看看「接口」属于「调用方」的情况。这个其实就是 SPI 机制。以 JDBC 驱动为例，「调用方」（用户或者说 JDK) 定义了 java.sql.Driver 接口，这个接口位于「调用方」JDK 的包中，各个数据库厂商实现了这个接口，比如 mysql 驱动 com.mysql.jdbc.Driver。因此，SPI 最显著的特征就是：