前言
在上一篇文章浅析springboot自动配置原理中，我们已经清楚知道关于springboot自动配置的实现原理，但是上一篇并没有花笔墨去讲解如何实现自定义的starter，原因有两个，第一个是本来代码已经贴太多了，强迫症的我不愿意再加那么多实现细节的代码，第二个是因为我觉得比较简单，各位看官自行google吧。这一篇，咱们来好好讨论自定义springboot-starter的应用场景。
应用场景
场景一：简化多服务公用框架集成。众所周知，springboot或者其他第三方所提供的starter，都是做框架集成，通过简化配置，提高开发效率，所以我们自定义starter的第一个应用场景也是基于这个思路。那我们日常开发工作中，有哪些框架是多个服务共用的，并且springboot或者其他第三方暂未提供，或者嫌弃第三方写的太烂，想自己重新实现的，都可以通过编写自定义starter来简化工作。我们公司采用微服务架构，每个服务都会使用swagger来生成在线接口文档。未封装swagger-starter之前，那么在每个服务里边，都需要增加swagger的配置类。而封装swagger-starter之后，可以省去这一步的操作，还可以通过增加自定义配置来实现一些自定义的功能。比如我们公司安全部门要求生产环境不能对外开放swagger接口文档地址，那么我们就可以添加一个enabled的参数来代表swagger是否启用，默认启用，在生产环境的配置中将enabled设为false即可达到这个目的。类似的额外功能还有很多，比如增加请求头等等，其他的读者自行发掘。
上面提到的是业务无关性的starter应用场景，那么我们抛出一个问题，是否有业务相关且多个业务场景或者多个服务会使用的应用场景？根据这个问题的描述，我们至少可以列出以下几个业务相关场景。
场景二：服务间调用的鉴权。我们公司服务之间互相调用需要进行鉴权（还是安全部门的要求），由于服务间是通过feign来实现相互调用，所以无法通过网关来进行统一鉴权。实现方案是通过新增feign拦截器，在源头服务发起调用之前增加鉴权参数，请求到达目标服务后通过鉴权参数进行鉴权。这两步操作很明显是每个服务都需要的，那么这种情况下，我们就可以把这两步操作封装成starter，达到简化开发的目的。同时，我们还可以通过增加配置，实现更细粒度的调用权限控制，比如订单服务只能调用库存服务的查询商品库存接口，而无法调用更新商品库存的接口。
场景三：邮件，短信，验证码功能。这些功能，在某些公司可能会放在common包里，但是这样其实会导致common包的臃肿，因为并不是所有服务都会使用到。有些公司（还是我们公司）可能对邮件服务器的访问有严格权限控制的，而且权限开通流程比较繁复的，那么会考虑做成服务，部署在已经具有访问权限的主机上，减去重复申请权限工作。如果除去这些限制，那么将这些功能封装成starter还是挺不错的，可以避免common包的臃肿。
场景四：大爱无疆场景。看到这个场景，大家是不是很懵逼，哈哈哈。是这样的，我们小组有位同事特别贴心，不仅编写接口，还提供调用接口的feignclient-starter给需要调用该接口的同事，starter还包含了相关请求类以及响应类。这已经不是可以通过有没有必要来理性分析的场景了，虽然我觉得不是很必要，但是我是很支持他这样做的，特别是给我提供接口的时候，哈哈哈。
总结
其实需不需要封装starter，最终还是根据技术架构而定，这里只是对我遇到的一些场景做一些描述，读者如果有别的场景，非常欢迎留言。
