从零到一搭建基础架构(6)-让你的服务组件化
本文为稀土掘金技术社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！
Hello，这里是爱 Coding，爱 Hiphop，爱喝点小酒的 AKA 柏炎。
本篇是手把手搭建基础架构专栏的第六篇，👇🏻是专栏历史文章，依次读取效果更佳。
第一篇：从零到一搭建基础架构(1)-玩转maven依赖版本管理
第二篇：从零到一搭建基础架构(2)-如何构建基础架构模块划分
基础架构Demo：common-frame
你需要先clone common-dependency
然后执行mvn clean install 将 common-dependency包打到你本地仓库
否则你拉下来common-frame工程后会报找不到
<parent> <groupId>com.baiyan</groupId> <artifactId>common-dependency</artifactId> <version>1.0.0-SNAPSHOT</version> </parent>
随着java的技术生态越来越庞大，市面上出现了越来越多的三方组件，提供了开箱即用的功能。
在同一个微服务的体系下（或者说在同一个部门、同一个公司），大家使用的中间件与三方依赖库都比较类似。针对这些中间件与三方库，业务服务在使用的时候多多少少都会做一些业务上的包装与配置。
同样的我们在进行中开发过程中，也会有各种各样的共有配置需要编写。比如在拦截器中记录请求的操作日志，注解，拦截器都是具有通用性的。各个业务服务都可能用到，在使用上除了日志内容不同，请求的解析方式与记录方式不会因为业务服务的不同而不同。
本章就将从公共的三方组件配置与系统内共有配置出发，为大家介绍在如何基础架构中搭建起自己的插拔式组件库。
一、什么叫做插拔式组件
Mysql、Redis、ES等等中间件都是我们日常工作中不可缺少的开发工具。
以Mysql为例，我们最开始在学习java的时候，使用jdbc来访问数据库。增删改查需要建立数据库连接、维护session、处理返回结果、控制游标等等，非常的麻烦。
到了工作中，除去一些开源框架开发或者数据库开发的同学，极少会有同学使用jdbc来操作数据库。我们更多还是使用Mybatis、JPA这种优秀的ORM框架去操作数据库。
理由嘛也很简单，开发者去使用这些组件的时候，本质上还是想操作数据库来进行数据的增删改查。至于你操作数据库还需要先构建连接，维护session池，断开重连等等这种对于我一个业务开发来说我根本不关心。
所以ORM框架就随之诞生了，我们可以使用框架所带给我们的便利，只需要在工程中增加数据库相关的配置，就能非常方便的操作数据库。
在Mybatis的基础之上，国内的baomidou开发团队开发了MyBatis-Plus，我们可以不用再编写xml文件就能够方便的操作数据库进行增删改查。
而在使用Mybatis-Plus的时候，我们还需要增加一些Mybatis-Plus的增强功能，比如分页配置
@Configuration
public class MybatisConfiguration {
@Bean
public MybatisPlusInterceptor mybatisPlusInterceptor() {
MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
return interceptor;
}
}
这样我们就能够直接方便的使用Mybatis-Plus来进行数据库分页查询操作，不用像在使用Mybatis查询分页数据那样，自己写分页的查询类，组装查询结果，计算数据条数还要再写一个count的xml。
技术的进步是因为人的懒惰。
从jdbc直接操作mysql，到mybatis编写xml就可以进行增删改查，最后到使用基于Mybatis二次开发的Mybatis-Plus。我们只需要进行简单的配置，就能够快速使用框架中接口进行开发。
那如果我们进行业务开发前，基础架构对Mybatis-Plus又包装了一层呢？将所有需要编写代码的配置都做了一个starter包呢？
关于starter包概念或者如何制作还不是很清楚的小伙伴可以阅读：手把手教你如何编写springboot中starter
业务研发只要在配置文件中增加一下数据库连接与分页配置，业务服务甚至连配置类都可以不用写了。
在基础架构中对Mybatis-Plus再包装一层，做成starter变成Mybatis-Baiyan-Plus。二次包装再开发，业务应用开箱即用。
哎呀，啥也不说了，就是起飞，就是方便。
有了这个思路，我来回答一下一个小老弟的问题。
分布式锁的工具类、配置这些对于业务应用来说基本上都是通用的，无非就是key的生成规则不同，失效时间不同，可重入规则等不同，其余的配置都是一样的。
那我们是不是可以基于本节的思路，将分布式锁的工具类包装成一个starter包（可插拔式组件），业务应用只要引入starter包的maven就能开箱即用你的工具类与配置，不是很爽吗？
二、插拔式组件还是大的功能模块
研究过common-frame工程的小伙伴有没有点疑问？
为什么我说插拔式的组件，但是并没有把一类组件单独划分一个Maven模块，而是把它们放在了service包中。
这里的插拔式组件其实是一个泛的概念。不是说一种功能的组件才能叫做插拔式组件，组合的也能叫。要看你怎么设计你的基础架构。
我们来看看common-frame的service包中包含了什么？
- minio的配置类与工具类
- mybatis-plus的配置类
- nginx配置类
- service层面在使用POJO时划分的指导demo
- spring的事件总线配置
- spring的bean与环境变量读取工具类配置
上述的配置是我们这个小组、这个部门、这个公司都必须使用到的配置时，我会把这些个工具类与配置都放在同一个包里面，不需要业务服务一个个去引入组件。
如果极致组件化一点的话，minion与mybatis-plus都应该独立做一个starter包来为业务服务提供基础架构能力。但我觉得是没什么必要，我们应该选择一个折中的方案：
- 业务服务所共有的配置放在service包中。但只要是配置，都要加上类似于
@ConditionalOnProperty(value = "spring.minio.enable",havingValue = "true")
这样的开关，防止少数服务确实不需要某些配置。
- 不一定所共有的，我们定义与service统计的maven模块，它仅依赖base模块
这样即让业务服务能够快速的使用基础架构所带来的便利，还能够让业务服务灵活的选择想要使用的组件进行业务开发。
三、总结
本章的核心思想是包装与通用。在service层进行业务开发时，我们对外部的jar的使用需要配置，需要二次开发。对内进行一些操作日志型的工具类进行使用时，具有非常高的通用性。
对于这些具有通用性的配置与工具类，我们将其提取，做成starter。让业务服务只需要引入想要使用的功能的maven就能直接使用这些功能。
而插拔式组件的定位上是一个比较泛的概念，不是非要一类功能就要做一个组件。需要结合当前基础架构服务的业务应用对象是谁？
如果是公司层面的组件，那使用的服务可能是跨部门的，组件需要尽量细化，划分成多个。
如果是小部门或者小组内的组件，组件可以粗话，定义成一个大的以及几个小的即可。
最后用一张图来概括一下业务服务对于插拔式组件的引用的maven。
四、联系我
如果你觉得文章写得不错，点赞评论+关注，么么哒~
微信：baiyan_lou
我的第一本掘金小册《深入浅出DDD》已经在掘金上线，欢迎大家试读~
DDD的微信群我也已经建好了，由于文章内不能放二维码，大家可以加我微信,备注DDD交流，我拉你进群，欢迎交流共同进步。