Java SPI 机制实在弄不明白，怎么进大厂？

真正的大师永远怀着一颗学徒的心

引言【资料获取】

在日常的项目开发中，我们为了提升程序的扩展性，经常使用面向接口的编程思想进行编程。这不仅体现了程序设计对于修改关闭，对于扩展开放的程序设计原则，同时也实现了程序可插拔。那么本文所阐述的 SPI 机制正是这种编程思想的体现。今天就和大家聊聊 SPI 到底是个什么鬼。顺便和大家一起看下 Seata 框架中是怎么使用 SPI 机制来实现框架扩展的。

什么是 SPI

在一般的开发逻辑中，都是服务提供方进行接口定义以及不同实现，服务调用方通过 API 的方式完成一次业务调用。但是这种方式对于服务调用方来说缺乏灵活性，不能根据自己的需要进行不同的实现加载。那么有没有一种机制可以赋予调用方更大的决策权呢？这个时候今天的主角 SPI 就隆重登场了。

SPI（Service Provider Interface） ，即服务提供者接口。听上去有点不明觉厉，不知道表达什么意思。按照我的理解，它就是一种服务发现机制。其本质就是将接口与实现进行解偶分离。区别于由服务实现方提供接口定义的 API 方式， SPI 需要服务调用方进行接口声明，具体实现由第三方进行实现。简单来说， SPI 就是生活中的甲方，你们这些乙方想要和我合作就必须按照我的要求来干活。通过这种方式调用方拥有了更大的灵活性，可以根据自身实际需要加载符合条件的实现。从而提升了程序的可扩展性，让服务提供方可以面向接口编程。

这么棒的扩展机制怎么使用呢？我们只需要在 jar 包的 META-INF/services/ 目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候，就能通过该 jar 包 META-INF/services/ 里的配置文件找到具体的实现类名，并装载实例化，完成实现类的的加载注入。

使用方提供规则说明，实际服务提供方完成具体实现。其实这种思想和 Spring 中的组件扫描是类似的，都是先指定好规则，服务提供方根据规范让框架自动进行服务发现。

重点来了，知识点来了，敲黑板了。自此我们可以发现，无论是本文谈到的 SPI ，还是 SpringBoot 中的自动配置原理，实际都是一种约定大于配置的开发思想，通过事先约定好的内容，进行具体实现，从而提升程序的扩展性。所以希望大家在看一项技术时，除了关注技术细节，进行纵向了解，也要关注横向技术对比，从而找到这些技术的共通之处，了解其背后的设计思想，我一直觉得这个是非常重要的，毕竟招式一直都是在变化，但是内功修炼可以催生出新的招式。

SPI 实现分析

SPI 使用【参考文献】

以 Mysql 的驱动加载为例，首先定义好需要进行扩展的模板接口，即为 java.sql.Driver 接口。各个数据库厂商可以更具自身数据库的特点进行对应的驱动开发，但是都要遵从这个模板接口。

在 Mysql 的驱动二方包中，在其 Classpath 路径下的 META-INF/services/ 目录中，创建一个以服务接口完全名称一致的的文件，在这个文件中保存的内容是模板接口具体实现类的完全限定名。

在对应的目录中进行具体的类实现，这些实现类都实现了 java.sql.Driver 接口。

具体的代码实现，通过 ServiceLoader 加载对应的实现类，完成类的实例化操作。当然这个 ServiceLoader 也可以自己定义，像 Dubbo 、 Seata 这样的框架都自己定义类加载器。

public final class ServiceLoader<S>
    implements Iterable<S>
{
  
   private static final String PREFIX = "META-INF/services/";
     ...
   public static <S> ServiceLoader<S> load(Class<S> service,
                                            ClassLoader loader)
{
        return new ServiceLoader<>(service, loader);
    }


  public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }


   private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }
    ...
}

我们一起来分析下这个服务加载器的工作流程，首先通过 ServiceLoader.load() 进行加载。先获取当前线程绑定的 ClassLoader ，如果当前线程绑定的 ClassLoader 为 null ，则使用 SystemClassLoader 进行代替，而后清除一下 provider 缓存，最后创建一个 LazyIterator 。LazyIterator 的部分源码如下：

private class LazyIterator implements Iterator<S>
    {


        Class<S> service;
        ClassLoader loader;
        Enumeration<URL> configs = null;
        Iterator<String> pending = null;
        String nextName = null;




  ...
  
   public boolean hasNext() {
            if (acc == null) {
                return hasNextService();
            } else {
                PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
                    public Boolean run() { return hasNextService(); }
                };
                return AccessController.doPrivileged(action, acc);
            }
        }
  ...
  
  private boolean hasNextService() {
            if (nextName != null) {
                return true;
            }
            if (configs == null) {
                try {
                  //key：获取完全限定名
                    String fullName = PREFIX + service.getName();
                    if (loader == null)
                        configs = ClassLoader.getSystemResources(fullName);
                    else
                        configs = loader.getResources(fullName);
                } catch (IOException x) {
                    fail(service, "Error locating configuration files", x);
                }
            }
            while ((pending == null) || !pending.hasNext()) {
                if (!configs.hasMoreElements()) {
                    return false;
                }
                pending = parse(service, configs.nextElement());
            }
            nextName = pending.next();
            return true;
        }
        ...




}

key ：通过预定好的目录地址以及类名来指定类的具体地址，类加载器根据这个地址来加载具体的实现类。

大致的 SPI 加载过程如下所示：

Seata 如何使用 SPI

Seata 是一个分布式事务的框架，具体的使用这里不再赘述，有时间可以出专门写它的文章。本节主要关注 Seata 是如何利用 SPI 的方式进行框架能力扩展的。

在 Seata 框架中使用 EnhancedServiceLoader 实现服务载入，通过名称我们可以知道他是一种增强型的 ServiceLoader 。那么相对于 JDK 自身的 ServiceLoader ，他到底强在哪里呢？

由下图可知， EnhancedServiceLoader 不仅支持 Java 原生的服务发现目录，同样支持自己自定义的 META-INF/seata/ 目录。

另外在具体接口实现类上都有 @LoadLevel 的注解，如果其中有多个配置中心实现类都被加载，那么可以根据对应注解上的属性 order 进行排序。将实际优先级最大的类进行加载。

我们都知道注册中心是微服务体系中的必不可少的基础组件，它记录了服务提供者的地址信息。那么在 Seata 中， Seata 的客户端如事务管理器 TM 、资源管理器 RM 需要与事务协调者TC 进行通信，那么就需要通过注册中心来获取服务端的地址信息。 Seata 注册中心支持多个第三方注册中心，如 Consul 、 Apollo 、 Etcd3 等。我们来看下 Seata 是怎么使用 SPI 机制来实现对于多个注册中心扩展支持的。

首先定义一个 ConfigurationProvider 的接口，你看是不是嗅到了熟悉的味道，只要使用 SPI 那么就需要首先把规矩给小弟们定好。

接着在对应的包 META-INF/services/ 中定义具体实现类，如此处的 Consul 配置中心中定义了 ConsulConfigurationProvider 。

我们可以看到 ConsulConfigurationProvider 实现了 ConfigurationProvider 的接口。

感谢各位小伙伴点赞、收藏和评论，文章持续更新，更多Java问题资料私聊我们下期再见！