关于我们

质量为本、客户为根、勇于拼搏、务实创新

< 返回新闻公共列表

Java/Spring/Dubbo三种SPI机制,到底谁更好?(spring boot和dubbo的区别)

发布时间:2022-06-28 11:05:28

SPI 机制应用在了大家项目中的很多地方,在很多框架中也有普遍应用,只不过很多人并没有感知。

举个例子,为什么我们在项目中引入 mysql-connector 的 jar 包,就可以直接连接 MySQL 数据库了?

本篇文章就来介绍一下 SPI,聊聊 Java 、Spring、Dubbo 中的 SPI 机制。

SPI

SPI ( Service Provider Interface),是一种服务发现机制。

SPI 的本质是将接口的实现类的全限定名配置在文件中,并由服务加载器读取配置文件,加载对应接口的实现类。这样就可以在运行时,获取接口的实现类。

通过这一特性,我们可以很容易地通过 SPI 机制为程序提供拓展功能。

Java SPI

Java SPI 机制:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


Java SPI 是“基于接口的编程+策略模式+配置文件”组合实现的动态加载机制。

设计一个接口,将接口的实现类写在配置文件中,服务通过读取配置文件来发现实现类,进行加载实例化然后使用。

配置文件路径:classpath下的META-INF/services/

配置文件名:接口的全限定名

配置文件内容:接口的实现类的权限定名

应用举例:

1、自定义接口

// 接口public interface Superman {void introduce();}// 实现类1public class IronMan implements Superman{@Overridepublic void introduce() {System.out.println("我是钢铁侠!");}}// 实现类2public class CaptainAmerica implements Superman {@Overridepublic void introduce() {System.out.println("我是美国队长!");}}

配置文件:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


测试:

public static void main(String[] args) {ServiceLoader<Superman> serviceLoader = ServiceLoader.load(Superman.class);System.out.println("Java SPI:");serviceLoader.forEach(Superman::introduce);}

运行结果:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


2、java.sql.Driver 接口

MySQL 的实现:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


看到这里,你应该就知道开头问题的答案了,mysql-connector 的 jar 表中正是通过 SPI 的方式实现了 java 的 Driver 接口,所以我们的服务可以在运行时获取到 mysql 的驱动类,从而连接 mysql 。

Java SPI 原理:

Java SPI 地实现在 ServiceLoader 类:

这里截取部分代码,有兴趣的同学自行阅读。

Java/Spring/Dubbo三种SPI机制,到底谁更好?


获取prefix下的配置文件(包括 jar 包):

Java/Spring/Dubbo三种SPI机制,到底谁更好?


Java SPI 总结:

Java SPI 机制:为某个接口发现/寻找服务实现的机制。

优点:

核心思想:解耦,使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离。可以根据实际业务情况进行使用或扩展。

缺点:

1、获取接口的实现类的方式不灵活
serviceLoader 只能通过 Iterator 形式遍历获取,不能根据参数获取指定的某个实现类。

2、资源浪费

serviceLoader 只能通过遍历的方式将接口的实现类全部获取、加载并实例化一遍。如果不想用某些实现类,它也会被加载并实例化,造成浪费。

Spring SPI

与 JDK SPI 类似, 相对于 Java 的 SPI 的优势在于:

Spring SPI 指定配置文件为 classpath 下的 META-INF/spring.factories,所有的拓展点配置放到一个文件中。

配置文件内容为 key-value 类型,key 为接口的全限定名, value 为实现类的全限定名,可以为多个。

spring.factories 文件举例:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


应用举例:

以 dubbo 的使用举例:

为什么我们在项目中引入 dubbo jar 包,application.yml 中配置 registry,provider 等,就可以直接通过使用 dubbo 的 Service 注解和 Reference 注解来使用 dubbo 服务了?

哪有什么岁月静好,不过是有人替你负重前行。“负重前行的人”就是 "dubbo-spring-boot-starter" 。其实就是用到了 spring SPI :

Java/Spring/Dubbo三种SPI机制,到底谁更好?


以 EnableAutoConfiguration 的实现类 DubboAutoConfiguration 为例:

在 spring boot 启动过程中 ,在
SpringFactoriesLoader.loadFactoryNames(type, classLoader) 这一步中会将 EnableAutoConfiguration 的实现类全部进行加载、解析、初始化。

在实例化 EnableAutoConfiguration 的实现类时,会执行实现类 dubboAutoConfiguration 中的具体逻辑,将 dubbo 服务器启动并注册到 spring 容器中。

DubboAutoConfiguration的大概实现:

读取配置文件中的配置项值(配置项:DubboConfigConfiguration)生成多个配置 bean,扫描 dubbo @Service 和 @Reference 注解的类,生成对应的 bean。

其实在我们使用的第三方依赖包中,很多都使用了 Spring SPI,如 dubbo,mybatis,redisson 等等。

Java/Spring/Dubbo三种SPI机制,到底谁更好?


Dubbo SPI

dubbo的 Filter、Protocol、Cluster、LoadBalance 等都是通过 SPI 的方式进行拓展加载的。

特点:

1、dubbo SPI 为每个拓展点(接口)单独设置一个文件,文件名为接口的全限定名。如
org.apache.dubbo.rpc.Filter,org.apache.dubbo.rpc.Protocol,org.apache.dubbo.rpc.cluster.LoadBalance 等。

dubbo SPI 配置文件举例:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


2、支持"别名的概念“,可以通过别名获取拓展点的某个实现。

配置文件内容是 key -value 类型,key 是别名,value 是实现类的全限定名。

只使用指定的 filter ,就不会实例化其他 filter 。

Java/Spring/Dubbo三种SPI机制,到底谁更好?


3、支持 Dubbo 内部的依赖注入

Dubbo IOC

通过 setter 方法进行依赖注入。Dubbo 首先会通过反射获取到实例的所有方法,然后再遍历方法列表,检测方法名是否具有 setter 方法特征。若有,则通过 ObjectFactory 获取依赖对象,最后通过反射调用 setter 方法将依赖设置到目标对象中。

实现:

dubbo SPI 的实现在 ExtensionLoader 这个类。

以获取所有的 dubbo Filter 为例:

1、首先获取 Filter 的 ExtensionLoader

ExtensionLoader.getExtensionLoader(Filter.class)

2、由 ExtensionLoader 从配置文件中加载所有的拓展类

Java/Spring/Dubbo三种SPI机制,到底谁更好?


加载项目中及 jar 包下以下目录的配置文件:

Java/Spring/Dubbo三种SPI机制,到底谁更好?


配置文件名为接口的全限定名。

3、读取配置文件时,根据 ’=‘ 为界限,确认键值对。

由此得到“配置项名称”到“配置类”的映射关系表

4、过程中多处使用缓存提升性能。

缓存拓展类对应的 ExtensionLoader 等。

获取到 别名 – 实现类的全限定名后,即可直接通过别名去获取指定的拓展类。

Java、Spring、Dubbo SPI 对比

Java/Spring/Dubbo三种SPI机制,到底谁更好?



相关推荐

【2022年的云计算虚拟化市场现状和发展(云计算未来市场) >>点击查看详情<<

【习近平向“全球发展:共同使命与行动价值”智库媒体高端论坛致贺信 >>点击查看详情<<

/template/Home/Redyun/PC/Static