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-bootstarter的格式,如
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-bootstarter-web的Maven依赖),Spring Boot就会自动检查项目依赖并启动Tomcat服务,如下代码所示:
Spring非官方Starter
原理上基本与官方Starter一致,需要在已经实现的artifactId上再封装一层,这一层只负责包含具体的实现类和配置类,而这个Starter的pom.xml文件相当于一个Facade门面,代码如下:
进入pom.xml文件,可以发现自包含的依赖关系,代码如下:
在 这 个 pom.xml 文 件 中 , 我 们 发 现 了 mybatis-spring-bootautoconfigure 自 动 配 置 类 , 通 过 它 我 们 可 以 完 成 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-bootstarter-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、Commonslogging等,
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.<id>.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-startersecurity组件的定制化改造。通过前面的Spring Security的源码分析,我们知道主要的方式就是继承WebSecurityConfigurerAdapter,这 样 做 的 好 处 在 于 , 我 们 依 然 可 以 使 用 spring-boot-startersecurity默认的一些行为,只需要对必要的行为进行调整,比如:
● 配置多个AuthenticationManager实例。
● 对HttpSecurity定义的默认资源访问规则进行重新定义。
● 对提供的默认WebSecurity行为进行调整。
为 了 能 够 让 这 些 调 整 生 效 , 我 们 定 义 的
WebSecurityConfigurerAdapter实现类一般在顺序上需要先于springboot-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 包 中 读 取 METAINF/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,详细逻辑这里就不赘述了。
本文给大家讲解的内容是SpringBootStarter技术:常用开箱即用Starter、生产就绪与环境配置、实现自定义Starter
觉得文章不错的朋友可以转发此文关注小编;
感谢大家的支持!
本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。