写点什么

不懂 Java SPI 机制,怎么进大厂

用户头像
Java架构师
关注
发布于: 2021 年 06 月 16 日

前言

在日常的项目开发中,我们为了提升程序的扩展性,经常使用面向接口的编程思想进行编程。这不仅体现了程序设计对于修改关闭,对于扩展开放的程序设计原则,同时也实现了程序可插拔。那么本文所阐述的 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/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候,就能通过该jarMETA-INF/services/里的配置文件找到具体的实现类名,并装载实例化,完成实现类的的加载注入。


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



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

SPI 实现分析

1、SPI 使用

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



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



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



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



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,如果当前线程绑定的 ClassLoadernull,则使用 SystemClassLoader进行代替,而后清除一下provider缓存,最后创建一个 LazyIteratorLazyIterator的部分源码如下:


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注册中心支持多个第三方注册中心,如ConsulApolloEtcd3等。我们来看下Seata是怎么使用 SPI 机制来实现对于多个注册中心扩展支持的。


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



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



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



用户头像

Java架构师

关注

还未添加个人签名 2021.05.28 加入

还未添加个人简介

评论

发布
暂无评论
不懂Java SPI机制,怎么进大厂