采纳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启动代码，本节从此处讲起，如下：

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。

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，该办法的源码如下：

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办法：

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解析失去的，咱们能够依照如下规定编写：

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事件/监听器模型」，源码如下：

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