Spring Boot 中的 starter 到底是什么 ?

Spring Boot 中的 starter 到底是什么 ?

面试官：好久没见，甚是想念。今天来聊聊SpringBoot的自动配置吧？

候选者：嗯，SpringBoot的自动配置我觉得是SpringBoot很重要的“特性”了。众所周知，SpringBoot有着“约定大于配置”的理念，这一理念一定程度上可以用“SpringBoot自动配置”来解释。

候选者：SpringBoot自动配置的原理理解起来挺简单的，我们在使用SpringBoot的时候，肯定会依赖于autoconfigure这么一个包

候选者：autoconfigure这个包里会有一个spring.factories文件，该文件定义了100+个入口的配置类。比如我们经常使用的redis、kafka等等这样常见的中间件都预置了配置类

候选者：当我们在启动SpringBoot项目的时候，内部就会加载这个spring.factories文件，进而去加载“有需要”的配置类。那我们在使用相关组件的时候，就会非常的方便（因为配置类已经初始化了一大部分配置信息）。

候选者：一般我们只要在application配置文件写上对应的配置，就能通过各种template类直接操作对应的组件啦。

面试官：那是所有的配置类都会加载吗？这个“有需要”的配置类你是怎么理解的？

候选者：不是所有的配置类都会加载的，假设我们没有引入redis-starter的包，那Redis的配置类就不会被加载。具体Spring在实现的时候就是使用**@ConditionalXXX**进行判断的。比如Redis的配置类就会有@ConditionalOnClass({RedisOperations.class})的配置，说明当前环境下如果有RedisOperations.class这个字节码，才会去加载Redis的配置类

面试官：哦，这样啊，那了解了。那你知不知道Redis的配置类其实会有初始化RedisTemplate对象的操作，那假设我们没有引入redis-starter包，那他是怎么通过编译的？（当然了，其他的配置类也是有可能有一样的状况）

候选者：嗯，这个我看源码的时候我也发现了。其实就是在autoconfigure包里会定义到相关的依赖，但只是标记为optional并且只在编译环境有效。那这样是能通过编译的，只是不会将其依赖传入到我们的应用工程里。

候选者：这块还是花了我很多时间的，我最后在GitHub 的SpringBoot源码里找到的。

面试官：嗯啊，有点东西的哟。既然都聊到这块了，要不顺便聊聊你对SpringBoot starter的理解？

候选者：嗯，starter这东西就是为了方便调用方去使用相关的组件的嘛，Spring框架也给我们实现了很多好用的starter。

候选者：比如以前我们要用Mybatis框架，可能会引入各种的包才能使用。而starter就是做了一层封装，把相关要用到的jar都给包起来了，并且也写好了对应的版本。这我们使用的时候就不需要引入一堆jar包且管理版本类似的问题了。

候选者：现在很多开源的组件都会提供对应的springboot-starter包给我们去用，要做一个starter包并不难。参照Spring内置的实现就好了：1、在工程里引入 starter 打包相关的依赖。2、在我们工程内建spring.factories文件，编写我们配置类的全限类名。

面试官：嗯，大致都了解了，可以的。最后聊下你是怎么看这块源码的？

候选者：源码具体大概就不记得了，思路倒是还有的。我先从启动类开始，会有个@SpringBootApplication，后面会定位到一个自动配置的注解@EnableAutoConfiguration，那最后就能看到注解内部会去META-INF/spring.factories加载配置类

候选者：这块源码并不难，这个过程也了解到了原来maven有option和scope这俩标签，但确实是SpringBoot比较重要的概念吧。

面试官：好嘞，今天到这就结束了吧。

题外：自动配置这个问题确实被问到过几次。说实在的，对于Spring类、注解的信息我真的记不住。感觉能答出这个流程思路，也就够用了（如果面试官确实是要细究某个类名，那这种公司不去也罢）

约定大于配置：SpringBoot给我们内置了很多配置类，这些配置类也初始化了很多配置（默认值）。当我们要使用的时候，只需要覆盖这些配置项就完事了。即便我们不写，大多数情况下都不需要由我们显示配置出来，但相关组件就能正常访问了。

我推荐一个拥有从零开始的文档的Java开源项目，既能用于毕业设计，又可以用在面试。已经有不少的同学通过这个项目拿到了大厂的offer啦（美团/vivo/阿里等等）

该项目业务极容易理解，代码结构是比较清晰的，最可怕的是几乎每个方法和每个类都带有中文注释，并且代码完全通过阿里开发插件检查。

拥有非常全的文档，作者从零搭建的过程都有详细地记录，项目里使用了蛮多的可靠和稳定的中间件的。在使用每一个技术栈之前作者都讲述了为什么要使用，以及它的业务背景。我看过，他所说的场景是完全贴合线上环境的。

我感觉这个项目就是奔着真实互联网线上项目去设计和实现的，将项目克隆下来把中间件换成目前公司在用的，配合自身的需求完善下基础建设，它就能在线上运行了。

我跟着README文档的部署使用姿势很快就能跑起来，最少只需要依赖MySQL和Redis。作者还搞了个前端功能界面，这就让系统变得更好理解了。而且，在GitHub或者Gitee所提的Issue几乎都会有回复，看出来也非常乐于合并开发者们的pull request，会让人参与感贼强。

我相信在校、工作一年左右或常年做内网CRUD后台的同学去看看肯定会有所启发，作者也会经常在群里回答该项目相关的问题和代码设计思路。

项目里会应用到各种设计模式（我稍微看了下，应该有7~8种吧），用到了各种的好用的工具组件，动态线程池、日志切面组件之类，都是主流的技术栈...目前这个项目GitHub和Gitee加起来已经 11K+ stars了！

项目Gitee链接：

项目GitHub链接：

项目文档&视频：

核心功能：统一的接口发送各种类型消息，对消息生命周期全链路追踪。

意义：只要公司内部有发送消息的需求，都应该要有类似消息推送平台的项目。消息推送平台对各类消息进行统一发送处理，这有利于对功能的收拢，以及提高业务需求开发的效率。

项目有预览地址，可自行体验：http://117.50.186.19:3000/

1、创建需要发送的渠道账号

2、创建消息模板

3、测试发送消息是否正常

4、查看消息下发情况

5、亦可在新建模板时选择定时任务，通过上传csv文件和指定cron表达式实现下发消息

了解工程模块的职责，这对看项目代码的时候会有个比较清晰的认识：

项目Gitee链接：

项目GitHub链接：

项目文档：