前言

在日常的我的项目开发中，咱们为了晋升程序的扩展性，常常应用面向接口的编程思维进行编程。这不仅体现了程序设计对于批改敞开，对于扩大凋谢的程序设计准则，同时也实现了程序可插拔。那么本文所论述的 SPI 机制正是这种编程思维的体现。明天就和大家聊聊 SPI 到底是个什么鬼。顺便和大家一起看下 Seata 框架中是怎么应用 SPI 机制来实现框架扩大的。

作为浏览福利，小编也整顿了一些 Java 学习材料（蕴含脑图、面试真题、手写 pdf 等），当初收费分享给浏览到本篇文章的 Java 程序员敌人们，须要的自行点击链接支付~
最全学习笔记大厂真题 + 微服务 +MySQL+ 分布式 +SSM 框架 +Java+Redis+ 数据结构与算法 + 网络 +Linux+Spring 全家桶 +JVM+ 高并发 + 各大学习思维脑图 + 面试汇合

什么是 SPI

在个别的开发逻辑中，都是服务提供方进行接口定义以及不同实现，服务调用方通过 API 的形式实现一次业务调用。然而这种形式对于服务调用方来说不足灵活性，不能依据本人的须要进行不同的实现加载。那么有没有一种机制能够赋予调用方更大的决策权呢？这个时候明天的配角 SPI 就隆重退场了。

SPI（Service Provider Interface），即服务提供者接口。听下来有点不明觉厉，不晓得表白什么意思。依照我的了解，它就是一种服务发现机制。其本质就是将接口与实现进行解偶拆散。区别于由服务实现方提供接口定义的 API 形式，SPI须要服务调用方进行接口申明，具体实现由第三方进行实现。简略来说，SPI就是生存中的甲方，你们这些乙方想要和我单干就必须依照我的要求来干活。通过这种形式调用方领有了更大的灵活性，能够依据本身理论须要加载符合条件的实现。从而晋升了程序的可扩展性，让服务提供方能够面向接口编程。

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

应用方提供规定阐明，理论服务提供方实现具体实现。其实这种思维和 Spring 中的组件扫描是相似的，都是先指定好规定，服务提供方依据标准让框架主动进行服务发现。

重点来了，知识点来了，敲黑板了。自此咱们能够发现，无论是本文谈到的 SPI，还是SpringBoot 中的主动配置原理，理论都是一种约定大于配置的开发思维，通过当时约定好的内容，进行具体实现，从而晋升程序的扩展性。所以心愿大家在看一项技术时，除了关注技术细节，进行纵向理解，也要关注横向技术比照，从而找到这些技术的共通之处，理解其背地的设计思维，我始终感觉这个是十分重要的，毕竟招式始终都是在变动，然而内功修炼更加重要。这大略是倚天屠龙记中。

SPI 实现剖析

1、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 的接口。