1 Introduction
With the growing bloated Spring, in order to simplify the configuration, out of the box, rapid integration, the Boot Spring turned out. Java has become the most fiery of the framework. We usually develop web applications with Spring Boot. Spring mvc default tomcat servlet container, because the Spring mvc components integrated spring-boot-starter-tomcat. But now undertow servlet container performance is very good. We can rule out tomcat in the following ways:
Then a direct replacement for the undertow:
No need to change the code. This is the advantage of the latter component of: 1 pluggable. 2. Can be customized. 3. Integrated demand. Why can achieve rapid adaptation? We imagine such a scenario: If there is a screw broken wheels on your car, you want to buy a screw to own equipment. You go to the store as long as you report the car's location and brand owners will be able to know exactly what kind of screws you use. This is the standard benefits that have been developed. Without standards, it's easy to buy is not supporting screws, you have to keep the trial and error. This is obviously not what you want. If such a standard subtle, then we in communication even more convenient. Sometimes your girlfriend a look you know she wants to do. So there is a Spring Boot "agreement is greater than the configured" rule, so to reduce configuration, reduce complexity between program components. So you are developing a Spring Boot Starter custom, we also want to consider how your starter more than convenience.
2. Spring Boot some of the conventions
Design of a component must have standards and rules. Spring Boot Starter is no exception. Let's look at some of the usual suspects.
2.1 naming style
If you have a baby soon, before birth, the more anxious you must be a name. Name the origin identifies you and your loved one, will not play next door surname Wang certainly would provoke a strange look. In the maven, groupId represents surname, artifactId represents the name. Spring Boot is also a suggestion of naming. groupId do not use the official org.springframework.boot
and use your own unique. For artifactId named, Spring Boot official suggested naming format follows the unofficial Starter xxxx-spring-boot-starter, for example mybatis-spring-boot-starter. The official starter will follow the spring-boot-starter-xxxx, such as spring-boot-starter-undertow mentioned above. Many of the open source starter ignores this convention, was not very "professional."
3. Customize a Starter
Next, we build a custom third-party SMS starter, designated sms-spring-boot-starter. There are some details to be while writing to introduce. Here is omitted a template samples and the test module:
Based on the above we have established the following items:
3.1 sms-spring-boot
sms-spring-boot is important to build a project dependency management. So it is necessary to introduce BOM. The starter key management of all the modules module, and all depend on the starter even sms-spring-boot-autoconfigure by sms-spring-boot management.
3.2 sms-spring-boot-autoconfigure
This module is used to define the configuration parameters, and the function of automatic configuration of external exposure (typically abstract interface Spring Bean).
3.2.1 Configuration Parameters
一般配置参数都是在Spring Boot 的application.yml中。我们会定义一个前缀标识来作为名称空间隔离各个组件的参数。对应的组件会定义一个XXXXProperties 来自动装配这些参数。自动装配的机制基于@ConfigurationProperties注解，请注意一定要显式声明你配置的前缀标识（prefix）。我们的sms-spring-boot会作如下配置：
以上以阿里云的短信功能为例作配置，在将来使用时只需要在application.yml中加入上面对应SmsProperties的配置：
如果你集成了Spring Boot 校验库 你也可以对SmsProperties进行校验。在配置application.yml时细心的java开发者会发现参数配置都有像下面一样的参数描述:
就像java中的注释一样方便我们理解该配置的作用，其实这个就是java注释生成的。你需要依赖
然后就该依赖会对SmsProperties 成员属性的注释进行提取生成一个spring-configuration-metadata.json文件，这就是配置描述的元数据文件。Spring Boot官方也对注释进行了一些规则约束：
- 不要以“The”或“A”开头描述。
- 对于boolean类型，请使用“Whether" 或“Enable”开始描述。
- 对于基于集合的类型，请使用“Comma-separated list”
- 如果默认时间单位不等同于毫秒，则使用java.time.Duration而不是long描述默认单位，例如“如果未指定持续时间后缀，则将使用秒”。
- 除非必须在运行时确定，否则不要在描述中提供默认值。
补充我个人建议描述尽量使用英文描述。
3.2.2 配置自动暴露功能接口
拿到配置后，接下来就是根据配置来初始化我们的功能接口，我们会抽象一个短信发送接口SmsSender，根据短信提供方的SDK来进行功能设计。请注意autoconfigure模块的依赖几乎都是不可传递的。也就是依赖坐标配置optional为true 。
功能接口实现完后我们会编写一个自动配置类 SmsAutoConfiguration 。除了@Configuration注解外，@ConfigurationProperties会帮助我们将我们的配置类SmsProperties加载进来。然后将我们需要暴露的功能接口声明为Spring Bean 暴露给Spring Boot应用 。有时候我们还可以通过一些条件来控制SmsAutoConfiguration或者SmsSender ，比如根据某个条件是否加载或加载不同的SmsSender。有时间你可以看看redis-starter就能很明显感觉到，它会根据luttuce、redisson、jedis 的变化实例化不同的客户端链接。实现方式是使用了@Conditional系列注解，有时间可以学习一下该系列的注解。好了我们的SmsAutoConfiguration声明如下：
3.2.3 主动生效和被动生效
starter集成入应用有两种方式。我们从应用视角来看有两种：
- 一种是主动生效，在starter组件集成入Spring Boot应用时需要你主动声明启用该starter才生效，即使你配置完全。这里会用到@Import注解，将该注解标记到你自定义的@Enable注解上：
我们将该注解标记入Spring Boot应用就可以使用短信功能了。 - 另一种被动生效，在starter组件集成入Spring Boot应用时就已经被应用捕捉到。这里会用到类似java的SPI机制。在autoconfigure资源包下新建META-INF/spring.factories写入SmsAutoConfiguration全限定名。
多个配置类逗号隔开，换行使用反斜杠。
3.3 sms-spring-boot-starter
该模块是一个空jar。它唯一目的是提供必要的依赖项来使用starter。你可以认为它就是集成该starter功能的唯一入口。不要对添加启动器的项目做出假设。如果您自动配置的依赖库通常需要其他启动器，请同时提及它们。如果可选依赖项的数量很高，则提供一组适当的默认依赖项可能很难，因为您应该避免包含对典型库的使用不必要的依赖项。换句话说，您不应该包含可选的依赖项。
无论哪种方式，您的starter必须直接或间接引用核心Spring Boot启动器（spring-boot-starter）（如果您的启动器依赖于另一个启动器，则无需添加它）。如果只使用自定义启动器创建项目，则Spring Boot的核心功能将通过核心启动器的存在来实现。
我们的sms-spring-boot-starter仅仅是以下的pom：
到此为止，我们的整个短信Starter就开发完成了。
4.总结
自定义starter对于我们项目组件化、模块化是有很大帮助的。同时也是Spring Boot一大特色。相信通过小胖的介绍你已经蠢蠢欲试了，那么就赶紧开始写一个吧。如果觉得对你有用可以点个赞关注一下。