Spring Boot 对比 Spring MVC 最大的优势就是使用简单,约定大于配置。不会像以前用 Spring MVC 的时候,时不时被 xml 配置文件搞的晕头转向,冷不防还由于 xml 配置上的一点疏忽,致使整个项目莫名其妙的不可用,顿感生活无所依恋,简称生无可恋。html
这要归功于组成了 Spring Boot 的各类各样的 starters,有官方提供的,也有第三方开源出来。能够这么说,基本上你打算用的功能均可以找到,若是没有找到,那就再找一找。java
用 Spring Boot 的功能组件(例如 spring-boot-starter-actuator、 spring-boot-starter-data-redis 等)的步骤很是简单,用著名的把大象放冰箱的方法来归纳的话,有如下三步就能够完成组件功能的使用:git
STEP 1github
在 pom 文件中引入对应的包,例如:web
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
STEP 2redis
在应用配置文件中加入相应的配置,配置都是组件约定好的,须要查看官方文档或者相关说明。有些比较复杂的组件,对应的参数和规则也相应的较多,有点可能多大几十上百了。spring
STEP 3shell
以上两步都正常的状况下,咱们就可使用组件提供的相关接口来开发业务功能了。bash
没错吧,这个过程咱们在平常的开发中不知道已经实践了多少遍。那么 Spring Boot 为何能作到如此简单易用呢,它内部是什么样的工做机制呢,不知道你有没有研究过。app
如下是为了理解 Spring Boot 组件的实现机制而制做的一个 demo starter。理解其中的原理,对咱们往后的工做有什么意义呢?
1. 遇到问题的时候,能够帮助咱们更有头绪的排查问题;
2. 能够帮助咱们正确的阅读源代码,组件的切入口在哪儿,配置属性是什么等等;
以上
如下,开始实现这个简单的 starter,这个 starter 并无什么实际的功能,只是为了作个演示而已。
开始以前,咱们要理解一下 spring boot starter 是什么呢?
实际上 starter 并不会包含多少功能代码,咱们能够把它理解成一个「链接包」(我本身造的概念),按照这个概念来讲:
它首先是一个包,一个集合,它把须要用的其余功能组件囊括进来,放到本身的 pom 文件中。
而后它是一个链接,把它引入的组件和咱们的项目作一个链接,而且在中间帮咱们省去复杂的配置,力图作到使用最简单。
实现一个 starter 有四个要素:
好了,开始实现咱们的 demo
1. 给 starter 起个名字
也就是咱们使用它的时候在 pom 中引用的 artifactId。命名有有规则的,官方规定:
官方的 starter 的命名格式为 spring-boot-starter-{name} ,例如上面提到的 spring-boot-starter-actuator。
非官方的 starter 的命名格式为 {name}-spring-boot-starter,咱们把自定的 starter 命名为 kite-spring-boot-starter,命名在 pom 文件里。
<groupId>kite.springcloud</groupId> <artifactId>kite-spring-boot-starter</artifactId> <packaging>jar</packaging> <version>1.0-SNAPSHOT</version>
2. 引入自动配置包及其它相关依赖包
实现 starter 主要依赖自动配置注解,因此要在 pom 中引入自动配置相关的两个 jar 包
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-configuration-processor</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-autoconfigure</artifactId> </dependency>
除此以外,依赖的其余包固然也要引进来。
3. 建立 spring.factories 文件
在 resource/META-INF 目录下建立名称为 spring.factories 的文件,为何在这里?当 Spring Boot 启动的时候,会在 classpath 下寻找全部名称为 spring.factories 的文件,而后运行里面的配置指定的自动加载类,将指定类(一个或多个)中的相关 bean 初始化。
例如本例中的配置信息是这样的:
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ kite.springcloud.boot.starter.example.KiteAutoConfigure
等号前面是固定的写法,后面就是咱们自定义的自动配置类了,若是有多个的话,用英文逗号分隔开。
4. 编写自动配置类
自动配置类是用来初始化 starter 中的相关 bean 的。能够说是实现 starter 最核心的功能。
@Configuration @ConditionalOnClass(KiteService.class) @EnableConfigurationProperties(KiteProperties.class) @Slf4j public class KiteAutoConfigure { @Autowired private KiteProperties kiteProperties; @Bean @ConditionalOnMissingBean(KiteService.class) @ConditionalOnProperty(prefix = "kite.example",value = "enabled", havingValue = "true") KiteService kiteService(){ return new KiteService(kiteProperties); } }
代码很是简单,放眼望去,最多的就是各类注解。
@Configuration 这个不用解释,表示这是个自动配置类,咱们平时作项目时也会用到,通常是用做读取配置文件的时候。
@ConditionalOnClass(KiteService.class) :
只有在 classpath 中找到 KiteService 类的状况下,才会解析此自动配置类,不然不解析。
@EnableConfigurationProperties(KiteProperties.class):
启用配置类。
@Bean:实例化一个 bean 。
@ConditionalOnMissingBean(KiteService.class):
与 @Bean 配合使用,只有在当前上下文中不存在某个 bean 的状况下才会执行所注解的代码块,也就是当前上下文尚未 KiteService 的 bean 实例的状况下,才会执行 kiteService() 方法,从而实例化一个 bean 实例出来。
@ConditionalOnProperty:
当应用配置文件中有相关的配置才会执行其所注解的代码块。
这个类的总体含义就是: 当 classpath 中存在 KiteService 类时解析此配置类,什么状况下才会在 classpath 中存在呢,就是项目引用了相关的 jar 包。而且在上下文中没有 KiteService 的 bean 实例的状况下,new 一个实例出来,而且将应用配置中的相关配置值传入。
5. 实现属性配置类
@Data @ConfigurationProperties("kite.example") public class KiteProperties { private String host; private int port; }
配置类很简单,只有两个属性,一个 host ,一个 port 。配置参数以 kite.example 做为前缀。稍后咱们在使用这个 starter 的时候会看到如何声明配置属性。
6. 实现相关功能类
也就是前面一直提到的 KiteService,其实严格来说,这个业务功能类不该该放在 starter 中,应该放在单独的 jar 包里,可是此处 demo 很是简单,也就在这里写了。
@Slf4j public class KiteService { private String host; private int port; public KiteService(KiteProperties kiteProperties){ this.host = kiteProperties.getHost(); this.port = kiteProperties.getPort(); } public void print(){ log.info(this.host + ":" +this.port); } }
一个构造函数和一个 print 方法。
7. 打包
经过 maven 命令将这个 starter 安装到本地 maven 仓库
mvn install
也能够经过 mvn package deploy
发布到你的私服
或者发布到中央仓库。
上面已经完成了 starter 的开发,并安装到了本地仓库,而后就是在咱们的项目中使用它了。
1. 建立项目,在 pom 中引用
<dependency> <groupId>kite.springcloud</groupId> <artifactId>kite-spring-boot-starter</artifactId> <version>1.0-SNAPSHOT</version> </dependency>
2. 应用配置项
建立 application.yml ,配置以下:
server: port: 3801 kite: example: enabled: true # 开启才生效 host: 127.0.0.1 port: 3801
3. 调用 KiteService 的服务方法
@RestController @RequestMapping(value = "use") public class UseController { @Autowired private KiteService kiteService; @GetMapping(value = "print") public void print(){ kiteService.print(); } }
4. 启动服务,并访问接口
访问 /use/print 接口,会发如今日志中打印出了配置信息
2019-05-24 16:45:04.234 INFO 36687 --- [nio-3801-exec-1] k.s.boot.starter.example.KiteService : 127.0.0.1:3801
顺着上面的思路,咱们来看一下官方的 starters 的结构。先来把 Spring Boot 从 github 上 clone 一份下来。用 idea 打开,能够看到项目结构以下
Spring-boot-starters 中就是官方提供的主要 starters,好比 jdbc、redis、security、web 等等。
咱们拿 spring-boot-starter-data-redis 这个 starter 做为例子,来讲一说官方是怎么组织项目结构的,以及阅读源码的顺序应该是怎样的。
1. 展开 Spring-boot-staters 下的 redis starter,咱们看到目录结构以下
其中并无 Java 代码,只有一个 spring.provides 文件,里面的内容以下:
provides: spring-data-redis,lettuce-core
意思就是说,本项目依赖 spring-data-redis 和 lettuce-core 这两个包,而且在 pom 文件中引用了。其目的就是告知使用者在引用此包的时候,没必要再引用 provides 中的依赖包了。
2. 而后就是自动注解了,全部 stater 的自动注解类、属性配置类都放到了 spring-boot-autoconfigure 这个项目下
看到熟悉的 spring.factories 没有,前面咱们本身实现过。这个内容比较多,咱们只看 redis 相关的
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,\ org.springframework.boot.autoconfigure.data.redis.RedisReactiveAutoConfiguration,\ org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration
包含三个自动配置文件,而后顺着配置,咱们找到所在 package
而后就能够开始阅读代码了。其余的 starter 也是一样的结构。
若是你以为写的还能够的话,请点个「推荐」吧
欢迎关注,不按期更新本系列和其余文章
古时的风筝
,进入公众号能够加入交流群
参考内容: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-developing-auto-configuration.html#boot-features-custom-starter