[Spring Boot 源解系列] 从 Java SPI 到 Spring Factories 扩展

2,516 阅读4分钟

intro 前言

Hello , AV Body! 我是野区杰西。

相信大家都学习过设计模式。当我们设计框架的时候,设计模式或多或少为我们设计指明了方向。

今天我在想设计模式中的开闭原则,究竟在哪些地方有应用到了?我查了一下资料,原来 Java SPI / Spring / Dubbo 都有相应的机制实现了这一原则。

设计模式的六大原则中的开闭原则(Open Close Principle),意思是 对扩展开放,对修改关闭。所谓的“对外扩展”就是框架余留一个接口(途径)给外部进行修改内部的状态,实现不改变原有代码就可以改变代码

Service Provider Interface

Service Provider Interface,简写是 SPI。这是 Java 原生实现用于被第三方实现或余留的扩展 API。

上图为 SPI 实现的思路。我们可以看到,实际上是“调用方”只需要对接“标准的服务接口”,而实际上屏蔽了“服务提供方”的 A 和 B,这就给我们在实现上面提供了很大的灵活性。

相信你已经对 SPI 有个基本的了解了。那么我们来看看 按照 Java SPI 思路图来实现一个小栗子。

// 实现一个接口,作为标准服务接口
public interface StandardService {
    public void offerService();
}

我们根据标准服务接口,编写两个不同逻辑不同的实现类

public class AStandardService implements StandardService {
    public void offerService() {
        System.out.println("我是服务 A,我可以为你提供 A 服务");
    }
}

接着是服务 B

public class BStandardService implements StandardService {
    public void offerService() {
        System.out.println("我是服务 B,我可以为你提供 B 服务");
    }
}

这时候我们的“服务”已经写好了。但是怎么让别人发现呢?其实 Java SPI 的规范会告诉你,你只需要在 classpath 下的 META-INF/services 文件夹里,放一个以“标准服务接口”的全限定名为名的文件,然后文件内写“服务提供方”的全限定名即可。如有多个,分行写。

而当外部程序装配这个模块的时候,就能通过该 jar 包 META-INF/services/ 里的配置文件找到具体的实现类名,并装载实例化,完成模块的注入。

根据 SPI 的约定,那我就直接在 META-INF/services/ 下创建一个名为 com.jc.demov20200215.service.StandardService,内容为 com.jc.demov20200215.service.impl.AStandardService

接下来就是调用方见证奇迹的时候了

@SpringBootApplication
public class Demov20200215Application {

    public static void main(String[] args) {
        ServiceLoader<StandardService> serviceLoader = ServiceLoader.load(StandardService.class);
        serviceLoader.forEach(StandardService::offerService);
    }

}

Spring.factories In Spring Boot

Spring 中也有类似于 Java SPI 这样扩展的地方。

所以我们直接写一个关于如何使用 Spring Boot 的 Springfactories 机制进行扩展。

但是说明一点,Spring 余留这个扩展机制很大原因不是为了给我们去加载自定义 Bean,而是为了让我们去扩展 Spring 其内部的 Bean,自定义框架想要的效果。

例如说,我们学 Spring Framework 的时候,我们都知道在 web.xml 里面配置一个 ApplicationContextInitializer 的类。这个类的作用是框架启动时进行初始化数据/配置等。那么问题来了,假设我们有一些初始化参数想让 Spring 帮我们初始化,那我们怎么办呢?答案是:实现 ApplicationContextInitializer 接口,然后里面加入我们所初始化的参数。但是问题又来了,那我们怎么把我们的实现类告诉 Spring 呢?难不成是 @Autowired ?不,很显然不行的!

其实这里的原理跟 Java SPI 思考原理一样的。Spring 余留了 Spring factories 这种机制,就是它只关心你的东西放在哪里,不关心你怎么实现!

明白~开始操作! 首先我们要创建一个实现了 ApplicationContextInitializer 的类

public class FirstInitializer implements ApplicationContextInitializer {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        ConfigurableEnvironment environment = applicationContext.getEnvironment();
        Map<String, Object> map = new HashMap<>();
        map.put("key","value");
        MapPropertySource mapPropertySource = 
                new MapPropertySource("firstInitializer", map);
        environment.getPropertySources().addLast(mapPropertySource);
        System.out.println("firstInitializer finish");
    }
}

我们写好了自定义的 Initializer,现在我们要告诉 Spring 它我们的 Initializer 放在哪里!还记得上面的 Java SPI 吗?它是放在了classpath 的 META-INF/services 文件夹下的。而 Spring 是放在 它是放在了classpath 下的 META-INF/spring.factories 文件。

创建好文件后,我们写入内容

org.springframework.context.ApplicationContextInitializer=com.jc.demov20200215.initializer.FirstInitializer

(如果有多个 initializer 可以使用逗号分割)

那怎么测试是否 Spring 已经加载我们的配置?其实我们可以写一个 Controller 类或者 service 类(都可以),只要实现 ApplicationContextAware 接口,获取到 ApplcaitonContext 。再通过 ApplcaitonContext 获得环境即可。

public class TestService implements ApplicationContextAware {
    
    private ApplicationContext applicationContext;

    public ApplicationContext getApplicationContext() {
        return applicationContext;
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.getApplicationContext().getEnvironment().getProperty("key");   
    }
}

输入即可获得! 好以上已经讲完了本篇文章我学习到的知识点以及例子

conclusion 结论

从 SPI 到 Spring 我们可以得出以下结论:

Tips:扩展方式 = 基于接口编程 + 配置文件 + 策略模式

或许你想说:“骗人,说好的源码解析呢?还想知道 Sprint 是如何实现加载和解析这些扩展信息并加载进 Spring 的上下文呢!”

好的,下文见!