SPI机制原理及实战

写在前面

不知道大家在工作中有没有遇见这种类似的场景，一个复杂的业务需求有多种不同的实现场景，每种实现场景由不同的业务方来决定。举一个简单的例子：分布式场景下，需要一个共享的存储系统来实现资源的分布式共享，共享的存储系统我们可以选择Hadoop/S3/阿里的OSS/腾讯的COS等等。对于toB的公司，为了兼容更多的客户，不得不去兼容各种各样类似于共享文件系统这样的技术。这时候如果我们可以做出一个可插拔、可扩展的产品，就可以面对技术更新迭代快的问题。SPI提供了一个很好的模式，值得我们去学习。

一、简介

SPI全称Service Provider Interface，提供了一种服务接口与服务实现解耦，通过本地具体的服务实现来决定使用哪种服务的形式，从而大大提高服务的扩展性和灵活的可插拔性。我们可以看下面的图来加深理解：

调用方A拥有与配置文件A匹配的环境或者条件，后端将服务接口和服务A的jar包引入。调用方A调用SPI机制的ServiceLoader类，此时ServiceLoader类会去加载服务接口，并通过配置文件发现服务实现A，调用服务实现A的具体实现来完成业务需求。

二、使用

以文章开始的场景为例，调用方A想对文件系统进行读写操作，但是只有hadoop的环境，而服务提供方提供了hadoop和cos的服务实现。我们一起来看看SPI是如何实现与业务解耦、可方便插拔、可方便扩展的。

类比slf4j的实现，我们只需要将hadoop实现（hadoop-cli）和hadoop的接口（base-cli依赖）引入，就可以满足调用方A的使用，也无需引入其他不相关的服务实现。同时扩展接入其他的文件系统，只需实现公共接口即可，对其他的实现也没有影响。

代码目录结构如下：

业务代码pom引入依赖如下：

业务核心代码如下：

public static void main(String[] args) throws Exception {
   
    
    String hdfsFilePath="C:\Users\liush\conf\hdfs-site.xml";
    
    String coreFilePath="C:\Users\liush\conf\core-site.xml";
    
    String filePath = "hdfs://HDFS8001206/flink/completed-jobs/f5547d971de3ad54dd0f6559d622125e";
    
    ServiceLoader<BaseClientUtil> loaders = ServiceLoader.load(BaseClientUtil.class);
    
    for (BaseClientUtil loader : loaders)