Spring Boot 中有一种非常解耦的扩展机制：Spring Factories.这种机制实际上是仿照java中的SPI扩展机制实现的。
什么是SPI 机制
SPI 的全名为 Service Provider Interface.大多数开发人员可能不熟悉，因为这个是是针对厂商或者插件的。在java.util.ServiceLoader 的文档里有比较详细的介绍。
简单总结下Java SPI机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如 日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及了具体的实现类，就违反了可插拔的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。
Java SPI 就是提供这样的一种机制：为某个接口寻找服务的实现的机制，有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制很重要。
Spring Boot 中的SPI 机制
在Spring boot 中也有一种类似的加载机制，它在META-INFO/spring.factories文件中配置接口的实现类名称，然后在程序中读取这些配置文件并实例化。
这种自定义的SPI 机制就是Spring Boot Starter 实现的基础。
Spring Factories实现原理
spring -core 包里定义了SpringFactoriesLoader 类，这个类实现了检索META-INF/spring.factories文件，并获取指定接口的配置的功能。 在这个类中定义了两个对外的方法：
- loadFactories 根据接口类获取其实现类的实例，这个方法返回的是对象列表
- loadFactoryNames 根据接口获取其接口类的名称，这个方法返回的是类名的列表。
上面两个方法的关键都是从指定的ClassLoader中获取spring.factories文件，并解析得到类名列表，具体代码如下
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()) {
String factoryClassName = ((String) entry.getKey()).trim();
for (String factoryName : StringUtils.commaDelimitedListToStringArray((String) entry.getValue())) {
result.add(factoryClassName, factoryName.trim());
}
}
}
cache.put(classLoader, result);
return result;
}
catch (IOException ex) {
throw new IllegalArgumentException("Unable to load factories from location [" +
FACTORIES_RESOURCE_LOCATION + "]", ex);
}
}
从代码中可以看到，在这个方法中会遍历整个ClassLoader 中所有Jar包下的spring.factories文件，也就是我们可以在自己jar中配置spring.factories文件，不会影响到其他地方的配置，也不回被别人的配置覆盖。
spring.factories的是通过Properties解析得到的，所以我们在写文件中的内容都是按照下面这种方式配置的。
com.xxx.interface=com.xxx.classname
如果一个接口希望配置多个实现类，可以用","分割。
spring-boot包中的spring.factories文件
在Spring Boot 的很多包中都能够找到spring.factories，下面就是spring-boot 包中的spring.factories文件
# PropertySource Loaders org.springframework.boot.env.PropertySourceLoader= org.springframework.boot.env.PropertiesPropertySourceLoader, org.springframework.boot.env.YamlPropertySourceLoader # Run Listeners org.springframework.boot.SpringApplicationRunListener= org.springframework.boot.context.event.EventPublishingRunListener # Error Reporters org.springframework.boot.SpringBootExceptionReporter= org.springframework.boot.diagnostics.FailureAnalyzers # Application Context Initializers org.springframework.context.ApplicationContextInitializer= org.springframework.boot.context.ConfigurationWarningsApplicationContextInitializer, org.springframework.boot.context.ContextIdApplicationContextInitializer, org.springframework.boot.context.config.DelegatingApplicationContextInitializer, org.springframework.boot.web.context.ServerPortInfoApplicationContextInitializer # Application Listeners org.springframework.context.ApplicationListener= org.springframework.boot.ClearCachesApplicationListener, org.springframework.boot.builder.ParentContextCloserApplicationListener, org.springframework.boot.context.FileEncodingApplicationListener, org.springframework.boot.context.config.AnsiOutputApplicationListener, org.springframework.boot.context.config.ConfigFileApplicationListener, org.springframework.boot.context.config.DelegatingApplicationListener, org.springframework.boot.context.logging.ClasspathLoggingApplicationListener, org.springframework.boot.context.logging.LoggingApplicationListener, org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener # Environment Post Processors org.springframework.boot.env.EnvironmentPostProcessor= org.springframework.boot.cloud.CloudFoundryVcapEnvironmentPostProcessor, org.springframework.boot.env.SpringApplicationJsonEnvironmentPostProcessor, org.springframework.boot.env.SystemEnvironmentPropertySourceEnvironmentPostProcessor # Failure Analyzers org.springframework.boot.diagnostics.FailureAnalyzer= org.springframework.boot.diagnostics.analyzer.BeanCurrentlyInCreationFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.BeanNotOfRequiredTypeFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.BindFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.BindValidationFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.UnboundConfigurationPropertyFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.ConnectorStartFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.NoUniqueBeanDefinitionFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.PortInUseFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.ValidationExceptionFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.InvalidConfigurationPropertyNameFailureAnalyzer, org.springframework.boot.diagnostics.analyzer.InvalidConfigurationPropertyValueFailureAnalyzer # FailureAnalysisReporters org.springframework.boot.diagnostics.FailureAnalysisReporter= org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter
在日常工作中，我们可能需要实现一些SDK 或者Sring boot starter 给别人用的时候，我们就可以使用Factories机制，Factories机制可以让SDK或者Stater的使用只需要很少或者不需要进行配置，只需要在服务中引入我们的Jar包就即可。
自动装配
在java spring cloud项目中，我们常常会在子模块中创建公共类库，作为驱动包。那么在另外一个子模块中，需要加载配置文件的时候，往往Spring Boot 自动扫描包的时候，只会扫描自己模块下的类。
1、引入META-INF/spring.factories文件
如何让我们的starter里的@Configuration在使用者的项目里生效呢？
在SpringBoot的启动类中，@SpringBootApplication注解的代码里面有一句@EnableAutoConfiguration
@EnableAutoConfiguration注解加载的是资源目录META-INF文件下的spring.factories的文件。包括导入到项目中的Jar包的META-INF文件夹下的spring.factories文件。spring.factories文件是一个properties文件。
2、@ComponentScan注解
作用是扫描@SpringBootApplication所在的Application类（即spring-boot项目的入口类）所在的包（basepackage）下所有的@component注解（或拓展了@component的注解）标记的bean，并注册到spring容器中。
源码解析
先看看SpringBoot的主配置类：
里面有一个main方法运行了一个run()方法，在run方法中必须要传入一个被@SpringBootApplication注解的类。
@SpringBootApplication
SpringBoot应用标注在某个类上说明这个类是SpringBoot的主配置类，SpringBoot就会运行这个类的main方法来启动SpringBoot项目。
那@SpringBootApplication注解到底是什么呢，点进去看看：
发现@@SpringBootApplication是一个组合注解。
@SpringBootConfiguration
先看看@SpringBootConfiguration注解：
这个注解很简单，表名该类是一个Spring的配置类。
再进去看看@Configuration：
说明Spring的配置类也是Spring的一个组件。
@EnableAutoConfiguration
这个注解是开启自动配置的功能。
先看看@AutoConfigurationPackage注解：
这个注解是自动配置包，主要是使用的@Import来给Spring容器中导入一个组件 ，这里导入的是Registrar.class。
来看下这个Registrar：
就是通过这个方法获取扫描的包路径，可以debug看看：
在这行代码上打了一个断点：
启动项目：
进入断点处：
看看能否获取扫描的包路径：
已经获取到了包路径：
那那个metadata是什么呢：
可以看到是标注在@SpringBootApplication注解上的DemosbApplication，也就是我们的主配置类：
说白了就是将主配置类（即@SpringBootApplication标注的类）的所在包及子包里面所有组件扫描加载到Spring容器。所以包名一定要注意。
现在包扫描路径获取到了，那具体加载哪些组件呢，看看下面这个注解。
@Import({AutoConfigurationImportSelector.class})
@Import注解就是给Spring容器中导入一些组件，这里传入了一个组件的选择器:AutoConfigurationImportSelector。
里面有一个selectImports方法，将所有需要导入的组件以全类名的方式返回；这些组件就会被添加到容器中。
debug运行看看：
会给容器中导入非常多的自动配置类（xxxAutoConfiguration）；就是给容器中导入这个场景需要的所有组件，并配置好这些组件:
有了自动配置类，免去了我们手动编写配置注入功能组件等的工作。
那他是如何获取到这些配置类的呢，看看上面这个方法：
会从META-INF/spring.factories中获取资源，然后通过Properties加载资源：
J2EE的整体整合解决方案和自动配置都在spring-boot-autoconfigure-2.0.3.RELEASE.jar：
比如看看WebMvcAutoConfiguration：
都已经帮我们配置好了，我们不用再单独配置了：
