SpringBootStarter技术：生产就绪与环境配置、实现自定义Starter

Spring Boot Starter技术

Spring Boot Starter概述

Spring Boot能够迅速地在微服务开发领域流行起来，并影响众多Spring和Java开发社区开发人员，可以说主要原因有两个。

• 一 是 Spring 的 约 定 优 于 配 置 的 特 性 （ Convention OverConfiguration），这个特性的关键实现机制就是自动装配机制。同时这一特性很好地遵循了简约开发原则，它不仅减少了软件开发人员的开发工作量和需要做的决定数量，获得简单易用的收益，而且方便扩展又不失灵活性。从Spring到Spring Boot，从Ant到Maven，本质上都践行了约定优于配置的原则。
• 二是Spring Boot基于“Spring Boot Starter技术”，即开箱即用的自动配置模块。在传统Spring应用系统中，我们需要完成众多的烦琐配置和多个jar包的手动引入及代码的初始化工作，才能将所需要的模块引入工程中。而Spring BootStarter的出现，简化了我们的配置，更重要的是将我们带入一种“可插拔”的编程模式。我们只需要在Maven中引入对应的现成Starter依赖，在代码中添加必要的注解，就可以获得开箱即用的对应功能。同时，我们可以结合Spring Boot的自动配置机制，实现自定义Starter组件，从而成为一个自包含的组件和模块，供第三方使用。

从Starter的命名方式我们可以区分出两类Starter。

• Spring 官 方 Starter ： 命 名 应 遵 循 spring-boot-starter-{name} 的 格 式 ， 如 spring-boot-starter-web 作 为 SpringBoot Web模块的官方artifactId。
• Spring 非 官 方 Starter ： 命 名 应 遵 循 {name}-spring-boot�starter的格式，如
  mybatis-spring-boot-starter。本章中介绍的自定义Starter属于后者。

Spring官方Starter

对于Spring官方Starter，只需在pom.xml配置文件中增加对于Starter的依赖，这个Starter就能够通过代码配置上下文发现并将所需要jar包进行关联，在自动配置类中可以通过@ConditionalOnClass来决定是否实例化（ConditionalOnClass是指在classpath发现需要的依赖的类时实例化）。

所有的Starter其实都是要通过代码配置被上下文发现的，可以在

spring-boot-autoconfigure-xxx.jar源码包中查看，例如下图所示，我们可以看到Spring Boot自带的Starter实现。

对 于 Spring Boot 内 置 Web 容 器 来 说 ， 只 要 通 过@ConditionalOnClass 发 现 了 Tomcat 这 个 类 （ 配 置 了 spring-boot�starter-web的Maven依赖），Spring Boot就会自动检查项目依赖并启动Tomcat服务，如下代码所示：

Spring非官方Starter

原理上基本与官方Starter一致，需要在已经实现的artifactId上再封装一层，这一层只负责包含具体的实现类和配置类，而这个Starter的pom.xml文件相当于一个Facade门面，代码如下：

进入pom.xml文件，可以发现自包含的依赖关系，代码如下：

SpringBootStarter技术：生产就绪与环境配置、实现自定义Starter

在 这 个 pom.xml 文 件 中 ， 我 们 发 现 了 mybatis-spring-boot�autoconfigure 自 动 配 置 类 ， 通 过 它 我 们 可 以 完 成 MyBatis 配 置JavaConfig的自动配置工作和MyBatis实例化配置。它的配置类代码如下：

通过MybatisAutoConfiguration自动化配置类，就实现了MyBatis的配置在启动时被Spring Boot程序加载到Spring Boot的Factory工厂并实例化为Bean。

Spring Boot常用开箱即用Starter

开箱即用的Starter组件也遵循Spring约定优于配置的理念，针对企业日常应用开发场景，通过引入这些现成的Starter可以简化开发流程。

spring-boot-starter-web快速开发

除了开发少数的独立应用，大部分情况下，我们都使用SpringMVC组件开发企业Web应用，为了帮助我们快速搭建并开发一个Web项目，Spring Boot提供了spring-boot-starter-web自动配置模块，只要将spring-boot-starter-web加入项目的Maven依赖即可：

在我们的工程中加入上面的Starter依赖后，就得到了一个可直接执行的Web应用环境，在当前项目下运行mvn spring-boot：run，可以直接启动一个使用了嵌入式Tomcat服务请求的Web应用服务。目前我们还没有提供任何Web请求的Controller，所以访问任何路径都会返回一个Spring Boot默认提供的错误页面，我们可以在当前项目下新建一个服务根路径作为Web请求的Controller实现，如下代码所示：

spring-boot-starter-jdbc与数据访问

为了使Spring Boot成为我们自动配置数据访问的基础设施，我们需要直接或者间接地依赖spring-jdbc，当spring-jdbc位于SpringBoot应用的classpath路径时，会触发数据访问相关的自动配置行为。

最简单的做法就是把spring-boot-starter-jdbc添到应用的依赖文件中。默认情况下，如果我们没有配置任何DataSource，那么SpringBoot会为我们自动配置一个基于嵌入式数据库的DataSource，这种自动配置行为其实很适合于测试场景，但对实际的开发帮助不大，基本上我们会自己配置一个DataSource实例。下面我们将spring-boot�starter-jdbc加入项目的Maven依赖：

如果我们的工程只依赖一个数据库，那么使用DataSource自动配置模块提供的参数是最方便的。在本书的7.1.4节中，我们会对“使用spring-boot-starter-jdbc访问MySQL”进行详细讲解。

spring-boot-starter-aop及其使用场景

在Java语言中，AOP（Aspect Oriented Programming，面向切面编程）通过提供另一种思考程序结构的方式来补充OOP（ObjectOriented Programming，面向对象编程）。OOP中模块化的关键单元是类。而在AOP中，模块化单元由“切面”组成。通过预编译方式和运行期动态代理实现程序功能的统一维护。AOP是Spring框架的一个重要特色，它可对既有程序定义一个切入点（Pointcut），然后在切入点前后切入不同的执行任务。常见使用场景有：打开/关闭数据库连接、打开/关闭事务、记录日志等。基于AOP不会破坏原来的程序逻辑，因此它可以很好地对业务逻辑的各个部分进行抽离，从而使得业务逻辑各个部分的耦合度降低，提高程序的复用性，同时提高开发效率。

Spring Boot对AOP提供了Starter组件支持，Maven依赖如下：

spring-boot-starter-aop主要由两部分组成：

• org.springframework.boot.autoconfigure.aop.AopAutoConfiguration：提供配置类。
• 通知：配置类中涉及的通知类型有前置通知、后置最终通知、后置返回通知、后置异常通知和环绕通知。

下面是一个实现了Web Controller调用的日志切面打印Web请求参数及相应结果的实例。

注解解释如下：

• 使用@Aspect注解将一个Java类定义为切面类。
• 使用@Pointcut定义一个切入点完成切面功能，根据对应参数执行不同的逻辑：

○ 任意公共方法的执行：

○ 任何一个以“set”开始的方法的执行：

○ AccountService接口的任意方法的执行：

○ 定义在service包里的任意方法的执行：

○ 定义在service包和所有子包里的任意类的任意方法的执行：

○ 定义在pointcutexp包和所有子包里的JoinPointObjP2类的任意方法的执行：

注意：根据需要，可在切入点的不同位置切入内容。

• 使用@Before在切入点开始处切入内容。
• 使用@After在切入点结尾处切入内容。
• 使用@AfterReturning在切入点return内容之后切入内容。
• 使用@Around在入点前后切入内容，并自己控制何时执行切入点自身的内容。
• 使用@AfterThrowing处理当切入内容部分抛出异常之后的逻辑。

spring-boot-starter-logging日志功能

常见的日志系统大致有Java.util.logging、Log4J、Commons�logging等，

spring-boot-starter-logging是Spring Boot为日志功能提供的一种默认实现。Maven依赖如下：

Spring Boot能够使用Logback、Log4J2、java util logging作为日志记录工具，默认使用Logback。日志默认输出到控制台，也能输出到文件中。如果想改变Spring Boot提供的应用日志设定，可以：

• 遵 循 Logback 的 约 定 ， 在 classpath 中 使 用 自 己 定 制 的logback.XML配置文件。
• 在文件系统的任意一个位置提供自己的logback.xml配置文件，然后通过logging.config配置项指向这个配置文件，再引用它。

spring-boot-starter-security与应用安全

spring-boot-starter-security主要面向的是Web应用开发，对应的Maven依赖如下：

spring-boot-starter-security默认会提供一个基于HTTP Basic认证的安全防护策略，默认用户为user，访问密码则在当前Web应用启动的时候打印到控制台。要想定制，则在配置文件中进行配置。

Spring Boot生产就绪与环境配置

Spring Boot自带的spring-boot-actuator模块提供的生产就绪（production-ready）特性与运行状况指标检查功能，可以帮助你深入掌握运行中的Spring Boot应用程序，一探Spring Boot程序的内部信息。

Actuator

Actuator指用于移动或控制某物的机械装置的制造业术语，Actuator可以从一个小的变化产生大量的运动。

要将Actuator添加到基于Maven的项目中开启Spring Boot的生产就绪特性，请加载以下依赖项：

spring-boot-actuator 自 动 配 置 模 块 默 认 为 我 们 提 供 了 很 多Endpoint，根据Spring的官方定义，Endpoint的解释如下。

Endpoint

Endpoint是执行器端点，可用于监控应用及与应用进行交互，Spring Boot包含很多内置的端点，你也可以自己添加。例如，health端点提供了应用的基本健康信息。

Endpoint分成两类：原生端点和自定义端点。自定义端点主要是指扩展性端点，用户可以根据自己的实际应用，定义一些自己比较关心的指标，在运行期进行监控。如下表所示是Endpoint使用ID标识的方式定义的可用监控对象（原生端点）。

如果你的应用是一个Web应用（Spring MVC、Spring WebFlux或Jersey），你还可以使用如下表所示的Endpoint。

Actuator的原生API有很多，大体上可以细分为以下三类。

• 应用配置类：应用配置、环境变量、自动化配置等。

• 度量指标类：运行时监控到的指标，如内存、线程池、HTTP统计信息等。

• 操作控制类：如关闭应用等操作类。

启用/禁止端点规则

• 默认情况下，除shutdown外的所有端点均已启用。要启用单个端点，可使用management.endpoint..enabled属性。以下示例启用shutdown端点：

• 可以通过
  management.endpoints.enabled-by-default来修改端点的默认配置，以下示例启用info端点并禁用所有其他端点：

• 禁用的端点将从应用程序上下文中完全被删除。如果只想更改端点公开（对外暴露）特性，可使用include和exclude属性，详情见下表。

说明：include属性列出了公开的端点的ID，exclude属性列出了不应该公开的端点的ID。exclude属性优先于include属性，意思是指同一端点ID同时出现在include属性表和exclude属性表时，exclude属性优先于include属性，即此端点不被暴露。

Endpoint的两种主要访问方式

要实现端点的访问，Spring Boot为我们提供了两种方式。

• 基于JMX的监控

Java管理扩展（JMX）提供了一种监视和管理应用程序的标准机制 ， 默 认 情 况 下 ， Spring Boot 将 管 理 端 点 公 开 为org.springframework.boot 域 中 的 JMX Mbean 。 Actuator 通 过

EndpointMBean-ExportAutoConfiguration将所有Endpoint实例以JMXMbean形式对外监控暴露，并默认注册在org.springframework.boot域下，可以使用Jconsole命令启动Java管理及监控控制台查看端点信息。

也可以使用使用Jolokia（基于JSR-160规范实现的MBean服务）通过HTTP实现JMX远程管理。Jolokia是一个JMX-HTTP桥，它提供了一种访 问 JMX Beans 的 替 代 方 法 。 想 要 使 用 Jolokia ， 只 需 添 加org.jolokia：jolokia-core的依赖。例如，使用Maven添加以下配置，然后在HTTP管理服务器上可以通过/jolokia访问Jolokia。

另外，如果想要禁用JMX端点，可以使用下面的配置方式：

• 基于HTTP的监控

如果你正在开发一个Web应用程序，Actuator会自动配置通过HTTP公开的所有已启用的端点，并通过以“management.”为前缀的配置项对端点进行开放。因为HTTP是标准的协议，对于跨语言、跨平台访问有天然的优势，使用HTTP的方式暴露端点信息有利于与其他监控平台和系统进行对接。

Spring Boot执行器自动将所有启用的端点通过HTTP暴露出去。默认约定使用端点的ID作为URL路径，例如，health暴露为/health。如果不想通过HTTP暴露端点，可以将管理端口设置如下：

保护HTTP端点

在配置文件中设置

management.security.enabled：false，这样所有的用户都可以用Actuator。但是这样的方式可能会暴露服务的敏感信息，并且在默认情况下，Actuator端点暴露在服务于常规HTTP的同一个端口上。如果你的应用程序是公开部署的，你可能希望添加Spring Security来进行用户身份验证。当添加Spring Security时，默认的“basic”身份验证将被启用。

使用HTTP暴露端点的方式与使用任何敏感网址一样，如果你希望为HTTP端点配置自定义安全性，比方说只允许具有特定角色的用户访问它们，Spring Boot提供了一些方便的RequestMatcher对象，可以与Spring Security结合使用，具体方式如下。

1.引入Security的Maven依赖

2.在配置文件中修改application.yml

3.定制Spring Security

我们可以在Security中赋予用户不同的权限，Actuator使用这种权限管理来控制用户的行为。Security可以拦截特定的请求：

Actuator的版本差异

注意：Spring Boot 2.0以后对Actuator做了很大的改动，主要变化如下：

• 2.X比1.X多了一个根路径：/actuator。
• 2.X的属性发生了变化，如下表所示。

● 部分端点路径发生了变更：

自定义健康检查器

在介绍自定义健康检查器前，我们先看一下Spring Boot定义的一套健康检查框架，后面我们根据整个框架定制一个健康检查器。对于健康检查器来说，最重要的接口就是HealthIndicator，代码如下：

抽象类AbstractHealthIndicator是健康检查类的骨架，实现了health方法，同时声明了doHealthCheck方法。Spring Boot的健康信息都从ApplicationContext中加载各种HealthIndicator实现，主要实现流程如下：

• 实例化Health$Builder。
• 调用抽象方法doHealthCheck进行状态的检查，出现异常则状态变为Status.DOWN。
• 下面是HealthCheck类的具体业务实现类示例：

你可以通过

management.health.defaults.enabled配置项将健康检查项全部禁用，也可以通过management.health.xxxx.enabled将其中任意一个禁用。如果我们需要提供自定义的健康检查信息状态，可以 通 过 HealthIndicator 的 接 口 来 实 现 ， 并 将 该 实 现 类 注 册 为JavaBean。你需要实现其中的health方法，并返回自定义的健康状态响应信息，该响应信息应该包括一个状态码和要展示的详细信息。例如，下面就是一个自定义的HealthIndicator的实现类：

Spring Boot安全管理

Spring Security是一款基于Spring的安全框架，主要包含认证和鉴权两大安全模块。Spring Security能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC（控制反转）、DI（依赖注入）和AOP（面向切面编程）。Spring Security本身比较复杂，其中包含众多子项目，如Spring Security OAuth、SpringSecurity JWT、Spring Security CAS等，本节将对Spring Security的核心模块及架构原理进行介绍。

Spring Security核心模块

权限系统一般包含两大核心模块：Authentication（认证）和Authorization（鉴权）。

• Authentication模块负责验证用户身份的合法性，生成认证令牌，并保存到服务端会话中（如TLS）。
• Authorization模块负责从服务端会话中获取用户身份信息，与访问的资源进行权限比对。

官方给出的Spring Security的核心架构如下图所示。

核心架构解读如下。

• Authentication Manager：负责认证管理，解析用户登录信息（封装在Authentication模块中），读取用户、角色、权限信息并进行认证，认证结果被回填到Authentication，保存在Security Context中。
• AccessDecision Manager：负责投票表决，通过投票器的结果实现一票通过（默认）、多票通过、一票否决策略。
• Security Interceptor：负责权限拦截，包括Web URL拦截和方法调用拦截。通过Config Attributes获取资源的描述信息，借助AccessDecision Manager进行鉴权拦截。
• Security Context：安全上下文，保存认证结果。提供了全局上下文、线程继承上下文、线程独立上下文（默认）三种策略。
• Authentication：认证信息，保存用户的身份标识、权限列表、证书、认证通过标记等信息。
• Secured Resource：被安全管控的资源，如Web URL、用户、角色、自定义领域对象等。
• Config Attributes：资源属性配置，描述安全管控资源的信息，为Security Interceptor提供拦截逻辑的输入。

Spring Boot进行集成，需要引入Maven依赖：

在 Spring Security 的 框 架 设 计 中 ， 关 键 是

AbstractSecurityInterceptor类，它是一个抽象类，安全认证流程的具体实现逻辑都贯穿在AbstractSecurityInterceptor类中，可以把AbstractSecurityInterceptor当成为一个模板类，它的实际执行流程都 由 具 体 子 类 所 实 现 ， 每 种 受 保 护 资 源 或 者 对 象 都 由AbstractSecurityInterceptor的实现类拦截实现。Spring Security提供了两个具体实现类，Method-SecurityInterceptor用于受保护的方法，FilterSecurityInterceptor用于受保护的Web请求：

public class FilterSecurityInterceptor extends AbstractSecurityInterceptor implements Filter{...}

public class MethodSecurityInterceptor extends

AbstractSecurityInterceptor

implements

Method�

Interceptor{...}

上述两个继承

AbstractSecurityInterceptor的实现类具有一致的执行逻辑：

（1）将正在请求调用的受保护对象传递给beforeInvocation方法进行权限鉴定。

（2）如果权限鉴定失败，则直接抛出异常。

（3）如果鉴定成功，则将尝试调用受保护对象，调用完成后，不管是成功调用，还是抛出异常，都将执行finallyInvocation方法。

（ 4 ） 如 果 在 调 用 受 保 护 对 象 后 没 有 抛 出 异 常 ， 则 调 用afterInvocation方法。

Spring Security核心源码

Spring Security默认使用的过滤器是FilterSecurityInterceptor，它的认证及鉴权流程和主要源码如下：

从 源 码 来 看 ， AuthenticationManager 负 责 制 定 规 则 ，

AbstractSecurityInterceptor负责执行。并且，Spring Security的Web安全方案基于Java的Servlet规范进行构建，所以如果你的开发框架是脱离Servlet规范实现的Web框架，则无法使用Spring Security提供的默认Web安全方案。在Servlet规范中，实现关卡功能的特性就是Filter组件，Spring框架使用将GenericFilterBean注入Spring容器的方式来让Filter可以享受依赖注入的好处。

WebSecurity 会 初 始 化 FilterChainProxy ， 它 通 过 扩 展GenericFilterBean 间 接 实 现 了 Filter 接 口 ， 同 时 持 有 一 组SecurityFilterChain，真正执行防护任务的SecurityFilterChain中定义的一系列Filter的代码如下：

Spring Security为SecurityFilterChain中的Filter设定了优先级顺序。下面的代码是Security的Filter实现逻辑。

虽然Filter很多，但可以简单划分为几类，除个别Filter在每个SecurityFilterChain中都有，其他可以根据需要选用：

• 信道与状态管理类，比如ChannelProcessingFilter用于处理HTTP或者HTTPS之间的切换，而
  SecurityContextPersistenceFilter用于重建或者销毁必要的SecurityContext状态。
• 常见Web安全防护类，比如CsrfFilter。
• 认 证 和 授 权 类 ， 比 如 BasicAuthenticationFilter 、CasAuthenticationFilter等。

HttpSecurity

Spring通过HttpSecurity完成定制化Filter的加载，拦截顺序及Filter的初始化存在于

WebSecurityConfigurerAdapter的初始化方法init中，通过getHttp方法可以获得HttpSecurity的对象。下面是WebSecurityConfigurerAdapter的初始化方法：

这个方法先构建HttpSecurity对象，然后通过WebSecurity对象的

addSecurityFilterChainBuilder方法添加到securityFilterChainBuilders的List中，最后完成组件过滤器链。我们可以通过返回的HttpSecurity对象重写addFilter方法，加入定制化的Filter对象。

定制实现

spring-boot-starter-security

我们可以通过给出一个继承了

WebSecurityConfigurerAdapter的JavaConfig配置类的行为，进行更深一级的对spring-boot-starter�security组件的定制化改造。通过前面的Spring Security的源码分析，我们知道主要的方式就是继承WebSecurityConfigurerAdapter，这 样 做 的 好 处 在 于 ， 我 们 依 然 可 以 使 用 spring-boot-starter�security默认的一些行为，只需要对必要的行为进行调整，比如：

• 配置多个AuthenticationManager实例。
• 对HttpSecurity定义的默认资源访问规则进行重新定义。
• 对提供的默认WebSecurity行为进行调整。

为 了 能 够 让 这 些 调 整 生 效 ， 我 们 定 义 的

WebSecurityConfigurerAdapter实现类一般在顺序上需要先于spring�boot-starter-security默认提供的配置，所以一般需要配合@Order注解进行标注，代码如下：

总之，

WebSecurityConfigurerAdapter是Spring Security框架为我们预先设定的一个安全框架，它允许我们对Web安全相关的功能进行定制化开发，但是在某些场景下我们还是会感觉不方便，此时我们可以直接实现并注册一个标注了@EnableWebSecurity的JavaConfig配置类到IoC容器，从而实现一种“颠覆性”的定制，示例代码如下：

Spring Boot实现自定义Starter

下面我们通过介绍在一个微服务网关项目（Sia-Gateway已在GitHub开源）中自定义Starter，了解自定义Starter的关键步骤，以及实现一个自定义注解的完整步骤，如下图所示。

使用到的关键注解和功能的对应关系如下。

• @Configuration与@Bean的作用：基于Java代码的Bean配置。
• @Conditional的作用：设置自动配置条件依赖。
• @EnableConfigurationProperties与@ConfigurationProperties的作用：读取配置文件并将其转换为Bean。
• @EnableAutoConfiguration 、 @AutoConfigurationPackage 与@Import的作用：Bean的发现与加载。

准备工作

在开始实现自定义Starter之前，我们需要手动创建两个工程。前文中已有介绍，第一个工程更像一个门面（Facade）工程，也可以通过引入第一个自定义的Starter工程验证自定义Starter的功能；第二个工程则是实现自定义Starter的实际业务功能部分，完成自动化配置定义、发现配置及实现特定的业务功能。

• sag-spring-boot-starter(pom.xml)

• sag-spring-boot-starter-autoconfigurer(pom.xml)

基于Java代码的Bean配置

下面是自定义Starter的详细配置加载过程，首先使用自动配置AutoConfiguration初始化Bean对象实例，代码如下：

从上面的代码中可以看到@Configuration、@Bean，这两个注解一起使用可以创建一个基于Java代码的配置类，它可以用来替代加载相应XML配置文件的过程。@Configuration注解的类可以看作让Spring容器管理的Bean实例的工厂。@Bean注解代表准备注册到Spring容器的对象实例，也就是一个带有@Bean的注解方法将返回的对象，该对象应该被注册到Spring容器中。自动配置类SagProxyAutoConfiguration的作用是自动生成微服务网关需要的Bean实例ThirdPartyComponent，并将这个Bean实例交给Spring容器管理，从而完成Bean的自动注册。

自动配置条件依赖

从SagProxyAutoConfiguration类中使用的注解可以看出，要完成自动配置是有依赖条件的，即@ConditionalOnBean （

SagProxyMarkerConfiguration.Marker.class）。

根据条件（ConditionalOnBean），要完成SagProxy的自动化配置 ， 我 们 需 要 在 类 路 径 中 判 断 声 明 类SagProxyMarkerConfiguration.mark.class，当这个Bean存在时才会完成Bean的自动注册。

Bean参数的获取至此我们已经知道了Bean的配置过程，但是还没有看到SpringBoot是如何读取YAML或者Properites配置文件的属性来创建数据源的，在SagProxyAutoConfiguration类里使用了@EnableConfigurationProperties注解：

SagProxyProperties中封装了Proxy配置的各个属性，并且使用Spring自带的注解ConfigurationProperties指定了配置文件的前缀为“sag”，相关配置代码如下：

通过以上分析我们可以得知：@ConfigurationProperties注解的作 用 是 把 YAML 或 者 Properties 配 置 文 件 转 化 为 Bean 对 象 ，@EnableConfigurationProperties注解的作用是使@ConfigurationProperties 注 解 生 效 ， 如 果 只 配 置@ConfigurationProperties注解，在Spring容器中获取不到YAML或者Properties配置文件转化的Bean。

Bean的发现

Spring Boot默认扫描启动类所在的包下的主类与子类的所有组件，但并没有包括依赖包中的类，那么依赖包中的Bean是如何被发现和加载的？这还要从启动类中的@SpringBootApplication注解说起，源码如下：

• @Configuration：其作用前面我们已经讲过了，被注解的类将成为一个Bean配置类。
• @EnableAutoConfiguration ： 其 功 能 很 重 要 ， 可 以 借 助@Import的支持，收集和注册依赖包中相关的Bean定义。
• @ComponentScan：其作用就是自动扫描并加载符合条件的组件，比如@Component和@Repository等，最终将这些Bean定义加载到Spring容器中。

@EnableAutoConfiguration注解引入了@AutoConfigurationPackage 和 @Import 这 两 个 注 解 。

@AutoConfigurationPackage的作用就是对自动配置package进行自动管理，而注解@Import主要完成需要自动配置的包的导入，源码如下：

要搜集并注册到Spring容器的那些Bean来自哪里呢？如下代码所示：

Registrar类的作用是扫描主配置类的同级目录及子包，并将相应的组件导入Spring Boot创建管理容器中，源码如下：

如 果 进 入

AutoConfigurationImportSelector 类 ， 可 以 发 现SpringFactoriesLoader 的 loadFactoryNames 方 法 会 调 用loadSpringFactories 从 所 有 的 jar 包 中 读 取 META�INF/spring.factories文件信息。

下 面 是 spring-boot-autoconfigure 这 个 jar 包 中 的spring.factories 文 件 的 部 分 内 容 ， 其 中 有 一 个 Key 为

org.springframework.boot.autoconfigure.EnableAutoConfiguration的值定义了需要自动配置的Bean，通过读取这个配置可以获取一组@Configuration类。

每个xxxAutoConfiguration都是一个基于Java的Bean配置类。不是 所 有 的 xxxAutoConfiguration 都 会 被 加 载 ， 会 根 据xxxAutoConfiguration上@ConditionalOnClass等条件判断是否加载；

最后，通过反射机制将spring.factories中@Configuration类实例化为对应的Java实例。至此，我们已经知道Spring Boot是通过怎样的机制发现准备自动配置的Bean的，接下来就要考虑怎样将这些Bean加载到Spring容器。

Bean的加载

如果要将一个普通类交给Spring容器管理，Spring Boot通常使用下面两种方式实现Bean的加载。大多数情况下我们会使用第一种方式，而对于自定义Starter，显然我们使用了第二种方式。

• 方式一：在配置类（@Configuration）中增加方法级别注解（ @Bean ） 或 者 使 用 类 级 别 注 解 ， 使 用 @Controller 、@Service、@Repository、@Component注解标注该类的方式注入Bean，然后确保@ComponentScan自动扫描路径包含上述注解类。
  
• 方 式 二 ： 从 Spring Boot 的 自 动 化 配 置 过 程 可 以 发 现 ，@EnableAutoConfiguratio注解中使用了@Import （ {
  AutoConfigurationImportSelector.class} ） 注解。
  

而@Import注解中的类

AutoConfigurationImportSelector实现了DeferredImportSelector 等 一 系 列 接 口 ， 该 接 口 是ImportSelector 的 子 接 口 ， 通 常 我 们 可 以 直 接 实 现ImportSelector接口并实现selectImports方法。当我们通过@Import注解向实现了ImportSelector接口的选择器添加相应的 自 动 化 配 置 注 解 ， 并 在 启 动 类 中 使 用 该 注 解 时 ，selectImports方法将会交给容器调用，从而实现Bean的自动化加载，Spring Boot正是通过这种机制来将Bean注入容器的。此外，还可以通过BeanDefinitionRegistry动态注入Bean，详细逻辑这里就不赘述了。