Dubbo源码--@SPI

松ge

已于 2023-02-05 22:42:54 修改

阅读量79

点赞数

分类专栏： RPC框架文章标签： java 数据库 apache

于 2023-02-04 20:45:33 首次发布

原文链接：https://blog.csdn.net/qq_35901087/article/details/77601162?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-77601162-blog-102761967.pc_relevant_3mothn_strategy_and_data_recovery&depth_1-utm_sourc

版权

RPC框架专栏收录该内容

5 篇文章 0 订阅

订阅专栏

SPI是一种服务发现机制，允许模块化设计中的接口实现动态加载。它通过在jar包的META-INF/services/目录下创建接口命名的文件来指定实现类。文章列举了common-logging和jdbc作为SPI的应用场景，说明了如何通过SPI加载日志提供商和数据库驱动。

摘要由CSDN通过智能技术生成

@SPI 学习

@SPI注解作用于扩展点的接口上，表明该接口是一个扩展点。可以被Dubbo的ExtentionLoader加载。如果没有此ExtensionLoader调用会异常。

1 SPI机制简介

SPI的全名为Service Provider Interface.大多数开发人员可能不熟悉，因为这个是针对厂商或者插件的。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java spi机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 java spi就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

2 SPI具体约定

java spi的具体约定为:当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader

3 应用场景

1.common-logging
apache最早提供的日志的门面接口。只有接口，没有实现。具体方案由各提供商实现，发现日志提供商是通过扫描 META-INF/services/org.apache.commons.logging.LogFactory配置文件，通过读取该文件的内容找到日志提工商实现类。只要我们的日志实现里包含了这个文件，并在文件里制定 LogFactory工厂接口的实现类即可。
2.jdbc
jdbc4.0以前，开发人员还需要基于Class.forName(“xxx”)的方式来装载驱动，jdbc4也基于spi的机制来发现驱动提供商了，可以通过META-INF/services/java.sql.Driver文件里指定实现类的方式来暴露驱动提供者.
链接：https://blog.csdn.net/qq_35901087/article/details/77601162?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-77601162-blog-102761967.pc_relevant_3mothn_strategy_and_data_recovery&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-77601162-blog-102761967.pc_relevant_3mothn_strategy_and_data_recovery&utm_relevant_index=1