最近我们自己在重构项目,系统为了符合82
原则(希望是80%的业务能通过穷举的方式固定下来,只有20%的允许特殊的定义),那么在固定一些标准流程以后,比如我们放大了原子服务的能力,当放大原子服务能力的时候,你就会发现,虽然抽象上看做的事情是一个意思,但是到实际去实现的时候发现还是各不相同。
在这里为了解决一个实现不同,但流程相同的问题,以及团队协作上的问题。我们引入的SPI (Service Provider Interface)
。
使用案例
通常情况下,使用ServiceLoader
来实现SPI
机制。 SPI
全称为 (Service Provider Interface)
,是JDK
内置的一种服务提供发现机制。SPI
是一种动态替换发现的机制, 比如有个接口,想运行时动态的给它添加实现,你只需要添加一个实现。
SPI
机制可以归纳为如下的图:
如果大家看过源代码或者说看过一些博客文章大概都清楚,在一些开源项目中大量的使用了SPI
的方式,比如:mysql-connector-java
,dubbo
等。
我们大概看眼MySQL
的一个SPI
实现
JDBC中的接口即为:java.sql.Driver
SPI机制的实现核心类为:java.util.ServiceLoader
Provider则为:com.mysql.jdbc.Driver
1 | com.mysql.jdbc.Driver |
简单写个SPI
代码部分,接口与实现类定义:
1 | package com.vernon.test.spi; |
调用函数定义:
1 | package com.vernon.test.spi; |
执行结果:
1 | Connected to the target VM, address: '127.0.0.1:58517', transport: 'socket' |
ServiceLoader类的内部实现逻辑
1 | public static <S> ServiceLoader<S> load(Class<S> service) { |
SercviceLoader的初始化跑完如上代码就结束了。但是实际上联系待实现接口和实现接口的类之间的关系并不只是在构造ServiceLoader类的过程中完成的,而是在迭代器的方法hasNext()
中实现的。
动态调用的实现
在使用案例中写的forEach语句内部逻辑就是迭代器,迭代器的重要方法就是hasNext()
:
ServiceLoader是一个实现了接口Iterable接口的类。
hasNext()
方法的源代码:
1 | public boolean hasNext() { |
抛出复杂的确保安全的操作,可以将上述代码看作就是调用了方法:hasNextService
.
hasNextService()
方法的源代码:
1 | private boolean hasNextService() { |
上述代码中比较重要的代码块是:
1 | String fullName = PREFIX + service.getName(); |
此处PREFIX(前缀)是一个常量字符串(用于规定配置文件放置的目录,使用相对路径,说明其上层目录为以项目名为名的文件夹):
1 | private static final String PREFIX = "META-INF/services/"; |
那么fullName会被赋值为:META-INF/services/com.vernon.test.spi.IRepository
然后调用方法getSystemResources
或getResources
将fullName参数视作为URL,返回配置文件的URL集合 。
1 | pending = parse(service, configs.nextElement()); |
parse
方法是凭借 参数1:接口的Class对象 和 参数2:配置文件的URL来解析配置文件,返回值是含有配置文件里面的内容,也就是实现类的全名(包名+类名)字符串的迭代器;
最后调用下面的代码,得到下面要加载的类的完成类路径字符串,相对路径。在使用案例中,此值就可以为:
1 | com.vernon.test.spi.impl.MongoRepository |
这仅仅是迭代器判断是否还有下一个迭代元素的方法,而获取每轮迭代元素的方法为:nextService()
方法。
1 | public S next() { |
总结
1、SPI
的理念:通过动态加载机制实现面向接口编程,提高了框架和底层实现的分离;
2、ServiceLoader
类提供的 SPI
实现方法只能通过遍历迭代的方法实现获得Provider
的实例对象,如果要注册了多个接口的实现类,那么显得效率不高;
3、虽然通过静态方法返回,但是每一次Service.load
方法的调用都会产生一个ServiceLoader
实例,不属于单例设计模式;
4、ServiceLoader
与ClassLoader
是类似的,都可以负责一定的类加载工作,但是前者只是单纯地加载特定的类,即要求实现了Service
接口的特定实现类;而后者几乎是可以加载所有Java
类;
5、对于SPi
机制的理解有两个要点:
- 理解动态加载的过程,知道配置文件是如何被利用,最终找到相关路径下的类文件,并加载的;
- 理解
SPI
的设计模式:接口框架 和底层实现代码分离;
6、之所以将ServiceLoader
类内部的迭代器对象称为LazyInterator
,是因为在ServiceLoader
对象创建完毕时,迭代器内部并没有相关元素引用,只有真正迭代的时候,才会去解析、加载、最终返回相关类(迭代的元素);
参考地址
- https://blog.csdn.net/li_xunhuan/article/details/103017286
- http://dubbo.apache.org/zh-cn/blog/introduction-to-dubbo-spi.html
如果大家喜欢我的文章,可以关注个人订阅号。欢迎随时留言、交流。如果想加入微信群的话一起讨论的话,请加管理员简栈文化-小助手(lastpass4u),他会拉你们进群。