「原理分析」Spring Boot 启动时基于 spring.factories 自动读取远端 Environment 实现的原理源码分析

采用Spring标准的事件/监听器模型,通过Spring SPI的方式,在Spring Boot启动时,自动读取远端「远程服务器、本地硬盘等」Environment配置,方便在Spring Boot启动前,对配置进行灵活调整,增加灵活性,减少硬编码。

本文先从原理进行分析,表明其可行性,下一篇文章再展示具体的代码实现。首先从SPI的基础开始讲起。

1. 服务发现的基础:SPI

注:此小节内容描述主要参考此文章 spring.factories
在Spring Boot中有一种非常解耦的扩展机制:Spring Factories。这种扩展机制实际上是仿照Java中的SPI扩展机制来实现的。

1.1 背景描述

系统中各个模块,往往有很多不同的实现方案,如日志组件、JDBC驱动、XML解析组件等。面向对象的程序设计中,推荐使用面向接口编程,业务程序中如需使用某项功能,须依赖通用的标准接口。基于可拔插的设计原则,此时如需更换功能模块的底层实现,直接予以替换即可「如替换Jar、替换maven依赖等」,业务代码无需任何改动。上述想法很美好,但是程序使用依赖的功能模块时,必须进行指明,不然程序运行时可能找不到相应的实现类,但是为了解耦,我们不想在业务代码中声明具体的实现,有什么解决方法吗?

这就需要一种服务发现机制。Java SPI就是提供这样的一个机制。Java SPI机制「Service Provider Interface」主要用于插件等,如需详细了解可参考java.util.ServiceLoader的文档。

1.2 Java SPI约定

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

1.3 Spring Boot中的SPI机制

在Spring中也有一种类似与Java SPI的加载机制。它在META-INF/spring.factories文件中配置接口的实现类名称,然后在程序中读取这些配置文件并实例化。这种自定义的SPI机制是Spring Boot Starter实现的基础。

2. Spring Boot实现SPI的源码分析

下面就根据Spring Boot应用的启动过程,对源码进行简要分析。当然Spring Boot本质是对Spring的再封装,故以下内容适用于Spring,只是部分源码是Spring Boot专属的。要注意的是,为了节省篇幅,避免喧宾夺主,会对实际源码进行精简,以突出要表述的内容。

首先展示最经典的Spring Boot启动代码,本节从此处讲起,如下:

1
2
3
4
5
6
public class Application {
public static void main(String[] args) {
SpringApplication application = new SpringApplication(Application.class);
application.run(args);
}
}

2.1 实例化SpringApplication对象

在实例化SpringApplication对象时,可以看到程序调用了如下构造方法。在执行到setInitializers((Collection)getSpringFactoriesInstances(ApplicationContextInitializer.class));时,即触发了Spring实现的SPI。

1
2
3
4
5
6
7
8
9
10
public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
this.resourceLoader = resourceLoader;
Assert.notNull(primarySources, "PrimarySources must not be null");
this.primarySources = new LinkedHashSet<>(Arrays.asList(primarySources));
this.webApplicationType = WebApplicationType.deduceFromClasspath();
setInitializers((Collection) getSpringFactoriesInstances(
ApplicationContextInitializer.class));
setListeners((Collection) getSpringFactoriesInstances(ApplicationListener.class));
this.mainApplicationClass = deduceMainApplicationClass();
}

继续深入看该方法的具体实现,定位到该方法:org.springframework.boot.SpringApplication#getSpringFactoriesInstances,该方法的源码如下:

1
2
3
4
5
6
7
8
9
10
private <T> Collection<T> getSpringFactoriesInstances(Class<T> type,
Class<?>[] parameterTypes, Object... args) {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
Set<String> names = new LinkedHashSet<>(
SpringFactoriesLoader.loadFactoryNames(type, classLoader));
List<T> instances = createSpringFactoriesInstances(type, parameterTypes,
classLoader, args, names);
AnnotationAwareOrderComparator.sort(instances);
return instances;
}

Spring-Core包里定义了SpringFactoriesLoader类,该类实现了检索META-INF/spring.factories文件,并获取指定接口的配置的功能。在这个类中定义了两个对外的方法:
loadFactories:根据接口类获取其实现类的实例,这个方法返回的是对象列表。
loadFactoryNames:根据接口获取其接口类的名称,这个方法返回的是类名的列表。
上面的两个方法的关键都是从指定的ClassLoader中获取spring.factories文件,并解析得到类名列表,

此处使用的是loadFactoryNames方法。继续深入发现实际调用的是loadSpringFactories方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
private static Map<String, List<String>> loadSpringFactories(@Nullable ClassLoader classLoader) {
MultiValueMap<String, String> result = cache.get(classLoader);
if (result != null) {
return result;
}
try {
Enumeration<URL> urls = (classLoader != null ?
classLoader.getResources(FACTORIES_RESOURCE_LOCATION) :
ClassLoader.getSystemResources(FACTORIES_RESOURCE_LOCATION));
result = new LinkedMultiValueMap<>();
while (urls.hasMoreElements()) {
URL url = urls.nextElement();
UrlResource resource = new UrlResource(url);
Properties properties = PropertiesLoaderUtils.loadProperties(resource);
for (Map.Entry<?, ?> entry : properties.entrySet()) {
List<String> factoryClassNames = Arrays.asList(
StringUtils.commaDelimitedListToStringArray((String) entry.getValue()));
result.addAll((String) entry.getKey(), factoryClassNames);
}
}
cache.put(classLoader, result);
return result;
}
catch (IOException ex) {
throw new IllegalArgumentException("Unable to load factories from location [" +
FACTORIES_RESOURCE_LOCATION + "]", ex);
}
}

其中静态常量FACTORIES_RESOURCE_LOCATION = "META-INF/spring.factories"

2.2 加载factories文件

java.lang.ClassLoader#getResources方法会遍历整个项目「包含依赖」的META-INF/spring.factories文件,取得其绝对路径,如/Users/bitkylin/.m2/repository/cn/bitkylin/test/1.0.0/test.jar/META-INF/spring.factories,使用PropertiesLoaderUtils#loadProperties方法从路径加载,并最终将接口和其实现类的全名缓存在cache对象中。cache对象的结构如下:

一颗多叉树。将spring.factories中配置的所有接口和其实现类的全名都读取了出来。此接口将接口org.springframework.context.ApplicationListener的实现类的类名的集合作为结果返回,而后org.springframework.boot.SpringApplication#createSpringFactoriesInstances方法将上述实现类均进行实例化,此时监听器就都创建好并注册了。

spring.factories是通过Properties解析得到的,我们可以按照如下规则编写:

1
com.xxx.interface=com.xxx.classname

key是接口,value是实现类。系统会自动将其初始化为如图所示的结构,方便使用。

2.3 Spring Boot启动

调用org.springframework.boot.SpringApplication#run方法,开始启动Spring Boot。在启动最开始阶段,程序就会调用到org.springframework.boot.SpringApplication#prepareEnvironment方法,并最终调用到经典的org.springframework.context.event.SimpleApplicationEventMulticaster#invokeListener方法「典型的观察者模式,标准的Spring事件/监听器模型」,源码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
protected void invokeListener(ApplicationListener<?> listener, ApplicationEvent event) {
ErrorHandler errorHandler = getErrorHandler();
if (errorHandler != null) {
try {
doInvokeListener(listener, event);
}
catch (Throwable err) {
errorHandler.handleError(err);
}
}
else {
doInvokeListener(listener, event);
}
}

通过该方法,将事件ApplicationEnvironmentPreparedEvent传递到所有已注册的监听器,可以借此实现Spring Boot启动时自动读取远端Environment。具体做法下节再讲述。

参考链接

spring.factories