--- theme: smartblue highlight: a11y-dark --- 公众号：慕枫技术笔记 --- 真正的大师永远怀着一颗学徒的心 --- # 引言在日常的项目开发中，我们为了提升程序的扩展性，经常使用面向接口的编程思想进行编程。这不仅体现了程序设计对于修改关闭，对于扩展开放的程序设计原则，同时也实现了程序可插拔。那么本文所阐述的SPI机制正是这种编程思想的体现。今天就和大家聊聊`SPI`到底是个什么鬼。顺便和大家一起看下`Seata`框架中是怎么使用`SPI`机制来实现框架扩展的。 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7ad292116e5433daa3d5775dfc37aa4~tplv-k3u1fbpfcp-watermark.image) # 什么是SPI 在一般的开发逻辑中，都是服务提供方进行接口定义以及不同实现，服务调用方通过`API`的方式完成一次业务调用。但是这种方式对于服务调用方来说缺乏灵活性，不能根据自己的需要进行不同的实现加载。那么有没有一种机制可以赋予调用方更大的决策权呢？这个时候今天的主角SPI就隆重登场了。 `SPI（Service Provider Interface）`，即服务提供者接口。听上去有点不明觉厉，不知道表达什么意思。按照我的理解，它就是一种服务发现机制。其本质就是将接口与实现进行解偶分离。区别于由服务实现方提供接口定义的`API`方式，`SPI`需要服务调用方进行接口声明，具体实现由第三方进行实现。简单来说，`SPI`就是生活中的甲方，你们这些乙方想要和我合作就必须按照我的要求来干活。通过这种方式调用方拥有了更大的灵活性，可以根据自身实际需要加载符合条件的实现。从而提升了程序的可扩展性，让服务提供方可以面向接口编程。这么棒的扩展机制怎么使用呢？我们只需要在`jar`包的`META-INF/services/`目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候，就能通过该`jar`包`META-INF/services/`里的配置文件找到具体的实现类名，并装载实例化，完成实现类的的加载注入。使用方提供规则说明，实际服务提供方完成具体实现。其实这种思想和`Spring`中的组件扫描是类似的，都是先指定好规则，服务提供方根据规范让框架自动进行服务发现。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b67a81089b4f48368730cd14c6a7408c~tplv-k3u1fbpfcp-watermark.image) 重点来了，知识点来了，敲黑板了。自此我们可以发现，无论是本文谈到的`SPI`，还是`SpringBoot`中的自动配置原理，实际都是一种约定大于配置的开发思想，通过事先约定好的内容，进行具体实现，从而提升程序的扩展性。所以希望大家在看一项技术时，除了关注技术细节，进行纵向了解，也要关注横向技术对比，从而找到这些技术的共通之处，了解其背后的设计思想，我一直觉得这个是非常重要的，毕竟招式一直都是在变化，但是内功修炼更加重要。这大概是倚天屠龙记中。 # SPI实现分析 ## 1、SPI使用以`Mysql`的驱动加载为例，首先定义好需要进行扩展的模板接口，即为`java.sql.Driver`接口。各个数据库厂商可以更具自身数据库的特点进行对应的驱动开发，但是都要遵从这个模板接口。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/55499ad5f2de4df39bf48b662cd65082~tplv-k3u1fbpfcp-watermark.image) 在Mysql的驱动二方包中，在其 `Classpath` `路径下的` META-INF/services/ 目录中，创建一个以服务接口完全名称一致的的文件，在这个文件中保存的内容是模板接口具体实现类的完全限定名。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/36d819ebcefa4cd09afc68cba63585b1~tplv-k3u1fbpfcp-watermark.image) 在对应的目录中进行具体的类实现，这些实现类都实现了`java.sql.Driver`接口。 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3634b69b01404516b4394b43f7c0a476~tplv-k3u1fbpfcp-watermark.image) 具体的代码实现，通过`ServiceLoader`加载对应的实现类，完成类的实例化操作。当然这个ServiceLoader也可以自己定义，像`Dubbo`、`Seata`这样的框架都自己定义类加载器。 ```java public final class ServiceLoader implements Iterable { private static final String PREFIX = "META-INF/services/"; ... public static ServiceLoader load(Class service, ClassLoader loader) { return new ServiceLoader<>(service, loader); } public static ServiceLoader load(Class service) { ClassLoader cl = Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); } private ServiceLoader(Class 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`的部分源码如下： ```java private class LazyIterator implements Iterator { Class service; ClassLoader loader; Enumeration configs = null; Iterator pending = null; String nextName = null; ... public boolean hasNext() { if (acc == null) { return hasNextService(); } else { PrivilegedAction action = new PrivilegedAction() { 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加载过程如下所示： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f22319454de64ec1a675d0bb536be389~tplv-k3u1fbpfcp-watermark.image) # Seata如何使用SPI `Seata`是一个分布式事务的框架，具体的使用这里不再赘述，有时间可以出专门写它的文章。本节主要关注Seata是如何利用SPI的方式进行框架能力扩展的。在`Seata`框架中使用 `EnhancedServiceLoader` 实现服务载入，通过名称我们可以知道他是一种增强型的`ServiceLoader`。那么相对于JDK自身的`ServiceLoader`，他到底强在哪里呢？由下图可知， `EnhancedServiceLoader `不仅支持`Java`原生的服务发现目录，同样支持自己自定义的`META-INF/seata/`目录。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d7f3e58fa81642f79181cfa5ddbcf471~tplv-k3u1fbpfcp-watermark.image) 另外在具体接口实现类上都有@LoadLevel的注解，如果其中有多个配置中心实现类都被加载，那么可以根据对应注解上的属性`order`进行排序。将实际优先级最大的类进行加载。 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/824fb6134b1a4d5790b22b38f336aca5~tplv-k3u1fbpfcp-watermark.image) 我们都知道注册中心是微服务体系中的必不可少的基础组件，它记录了服务提供者的地址信息。那么在`Seata`中，`Seata`的客户端如事务管理器`TM`、资源管理器RM需要与事务协调者`TC`进行通信，那么就需要通过注册中心来获取服务端的地址信息。`Seata`注册中心支持多个第三方注册中心，如`Consul`、`Apollo`、`Etcd3`等。我们来看下`Seata`是怎么使用SPI机制来实现对于多个注册中心扩展支持的。首先定义一个`ConfigurationProvider`的接口，你看是不是嗅到了熟悉的味道，只要使用`SPI`那么就需要首先把规矩给小弟们定好。 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2ede5baa2a1249298ef42b3163166f74~tplv-k3u1fbpfcp-watermark.image) 接着在对应的包`META-INF/services/`中定义具体实现类，如此处的`Consul`配置中心中定义了`ConsulConfigurationProvider`。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c56a79b9c8a14758b14f3ebc239acbda~tplv-k3u1fbpfcp-watermark.image) 我们可以看到`ConsulConfigurationProvider`实现了`ConfigurationProvider`的接口。 ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2f3c805f2b224a27b2cc27f754df7333~tplv-k3u1fbpfcp-watermark.image) --- 我是慕枫，感谢各位小伙伴点赞、收藏和评论，文章持续跟新，我们下期再见！ > 微信搜索：**慕枫技术笔记**，优质文章持续更新，我们有学习打卡的群可以拉你进，一起努力冲击大厂，另外有很多学习以及面试的材料提供给大家。