可插拔组件设计机制—SPI
作者:京东物流 孔祥东
1.SPI 是什么?
SPI 的全称是Service Provider Interface,即提供服务接口;是一种服务发现机制,SPI 的本质是将接口实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载实现类。这样可以在运行时,动态为接口替换实现类。正因此特性,我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。
如下图:
系统设计的各个抽象,往往有很多不同的实现方案,在面对象设计里,一般推荐模块之间基于接口编程,模块之间不对实现硬编码,一旦代码涉及具体的实现类,就违反了可插拔的原则。Java SPI 就是提供这样的一个机制,为某一个接口寻找服务的实现,有点类似IOC 的思想,把装配的控制权移到程序之外,在模块化涉及里面这个各尤为重要。与其说SPI 是java 提供的一种服务发现机制,倒不如说是一种解耦思想。
2.使用场景?
- 数据库驱动加载接口实现类的加载;如:JDBC 加载Mysql,Oracle...
- 日志门面接口实现类加载,如:SLF4J 对log4j、logback 的支持
- Spring中大量使用了SPI,特别是spring-boot 中自动化配置的实现
- Dubbo 也是大量使用SPI 的方式实现框架的扩展,它是对原生的SPI 做了封装,允许用户扩展实现Filter 接口。
3.使用介绍
要使用 Java SPI,需要遵循以下约定:
- 当服务提供者提供了接口的一种具体实现后,需要在JAR 包的META-INF/services 目录下创建一个以“接口全限制定名”为命名的文件,内容为实现类的全限定名;
- 接口实现类所在的JAR放在主程序的classpath 下,也就是引入依赖。
- 主程序通过java.util.ServiceLoder 动态加载实现模块,它会通过扫描META-INF/services 目录下的文件找到实现类的全限定名,把类加载值JVM,并实例化它;
- SPI 的实现类必须携带一个不带参数的构造方法。
示例:
spi-interface 模块定义
定义一组接口:public interface MyDriver
spi-jd-driver
spi-ali-driver
实现为:public class JdDriver implements MyDriver public class AliDriver implements MyDriver
在 src/main/resources/ 下建立 /META-INF/services 目录, 新增一个以接口命名的文件 (org.MyDriver 文件)
内容是要应用的实现类分别 com.jd.JdDriver和com.ali.AliDriver
spi-core
一般都是平台提供的核心包,包含加载使用实现类的策略等等,我们这边就简单实现一下逻辑:a.没有找到具体实现抛出异常 b.如果发现多个实现,分别打印
public void invoker(){ ServiceLoader<MyDriver> serviceLoader = ServiceLoader.load(MyDriver.class); Iterator<MyDriver> drivers = serviceLoader.iterator(); boolean isNotFound = true; while (drivers.hasNext()){ isNotFound = false; drivers.next().load(); } if(isNotFound){ throw new RuntimeException("一个驱动实现类都不存在"); } }
spi-test
public class App { public static void main( String[] args ) { DriverFactory factory = new DriverFactory(); factory.invoker(); } }
1.引入spi-core 包,执行结果
2.引入spi-core,spi-jd-driver 包
3.引入spi-core,spi-jd-driver,spi-ali-driver
4.原理解析
看看我们刚刚是怎么拿到具体的实现类的?
就两行代码:
ServiceLoader<MyDriver> serviceLoader = ServiceLoader.load(MyDriver.class); Iterator<MyDriver> drivers = serviceLoader.iterator();
所以,首先我们看ServiceLoader 类:
public final class ServiceLoader<S> implements Iterable<S>{ //配置文件的路径 private static final String PREFIX = "META-INF/services/"; // 代表被加载的类或者接口 private final Class<S> service; // 用于定位,加载和实例化providers的类加载器 private final ClassLoader loader; // 创建ServiceLoader时采用的访问控制上下文 private final AccessControlContext acc; // 缓存providers,按实例化的顺序排列 private LinkedHashMap<String,S> providers = new LinkedHashMap<>(); // 懒查找迭代器,真正加载服务的类 private LazyIterator lookupIterator; //服务提供者查找的迭代器 private class LazyIterator implements Iterator<S> { ..... private boolean hasNextService() { if (nextName != null) { return true; } if (configs == null) { try { //全限定名:com.xxxx.xxx String fullName = PREFIX + service.getName(); if (loader == null) configs = ClassLoader.getSystemResources(fullName); else configs = loader.getResources(fullName); } } while ((pending == null) || !pending.hasNext()) { if (!configs.hasMoreElements()) { return false; } pending = parse(service, configs.nextElement()); } nextName = pending.next(); return true; } private S nextService() { if (!hasNextService()) throw new NoSuchElementException(); String cn = nextName; nextName = null; Class<?> c = null; try { //通过反射获取 c = Class.forName(cn, false, loader); } if (!service.isAssignableFrom(c)) { fail(service, "Provider " + cn + " not a subtype"); } try { S p = service.cast(c.newInstance()); providers.put(cn, p); return p; } } ........
大概的流程就是下面这张图:
应用程序调用ServiceLoader.load 方法
应用程序通过迭代器获取对象实例,会先判断providers对象中是否已经有缓存的示例对象,如果存在直接返回
如果没有存在,执行类转载读取META-INF/services 下的配置文件,获取所有能被实例化的类的名称,可以跨越JAR 获取配置文件通过反射方法Class.forName()加载对象并用Instance() 方法示例化类将实例化类缓存至providers对象中,同步返回。
5.总结
优点:解耦
SPI 的使用,使得第三方服务模块的装配控制逻辑与调用者的业务代码分离,不会耦合在一起,应用程序可以根据实际业务情况来启用框架扩展和替换框架组件。
SPI 的使用,使得无须通过下面几种方式获取实现类
代码硬编码import 导入
指定类全限定名反射获取,例如JDBC4.0 之前;Class.forName("com.mysql.jdbc.Driver")
缺点:
虽然ServiceLoader也算是使用的延迟加载,但是基本只能通过遍历全部获取,也就是接口的实现类全部加载并实例化一遍。如果你并不想用某些实现类,它也被加载并实例化了,这就造成了浪费。获取某个实现类的方式不够灵活,只能通过Iterator形式获取,不能根据某个参数来获取对应的实现类。
6.对比

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
从稀疏表征出发、召回方向的前沿探索
作者 | lhy12138 导读 目前百度大搜主要有基于稀疏表征的倒排检索和稠密表征的语义检索双路召回。随着深度学习技术的发展,语义检索的召回效果得到了显著提高;与此同时,因为稀疏表征有着精确匹配、索引效率和可解释的优势,最近学术界重新将目光放回稀疏表征架构,研究稀疏表征如何从大规模语言模型中获益。本文将介绍学术界在倒排召回和语义召回的最新进展。 全文6386字,预计阅读时间16分钟。 一、搜索中的召回 召回一般会从海量候选库中选择与query相关的文档送给上层排序模块,因为效率原因,往往无法执行query-url细粒度交互。目前召回主要有基于term的传统倒排召回和基于向量表征的语义召回。本文将介绍两个方向在学术届的一些最新进展。 二、如何看待语义召回和传统倒排召回的关系? 随着预训练模型和样本技术的更新,语义召回表现了强大的检索效果,而传统倒排技术因为成本、效率问题并没有获得效果的显著提高。倒排召回基于term归并,因此具有较强的可解释性;而语义召回在向量空间搜索与query语义最相似的文档,对语义的表达能力更强。应该如何看待两者在召回链路上的关系呢? Are We There ...
- 下一篇
交易系统之数据库弱依赖解决方案
作者:京东科技 杜晓玉 前言 数据库,交易系统中最核心依赖,数据持久化属于最核心服务。 随着互联网的普及,大流量高并发的场景越来越多,7*24的交易系统对高可用要求越来越高,同时在“数据为王”大环境下,交易数据最终通过数据库进行持久化存储,数据库成为整个系统最终重要服务,不能出一点问题,尤其核心P0系统哪怕瞬间的DB操作异常可能造成大量异常交易,可能产生致命的问题,所以核心系统弱依赖数据库都是必须考虑的。 数据库弱依赖的整体思路:将最可靠链路再增加上备用链路替换,解决方案主要通过其他存储介质+补偿机制替换同步的DB操作,预期效果:数据库出现故障期间也能保证系统运行正常不影响线上业务开展。 本期介绍下实践过的三种解决方案:DB灾备机制方案、DB高并发替换方案、财富系统弱依赖DB方案。 一、DB灾备机制方案 日常引发数据库操作出现异常的常见情况:网络链路异常、执行工单导致数据库性能下降、慢SQL导致数据库异常等,并且从发现问题到解决往往时间不短,尤其核心交易链路都已无法容忍短时间的异常故障,所以首先考虑增加灾备机制,出现异常时间段内也要保证交易成功率,哪怕可以损失一点性能要求。DB灾备机制...
相关文章
文章评论
共有0条评论来说两句吧...