maven 按业务拆分模块_蚁柜微服务拆分实践

蚁柜微服务拆分实践

一、 前言

蚁柜最初是一个为社区提供快递柜和存取快递服务的软硬件结合的项目，在迭代过程中根据实际用户需求以及业务拓展，逐步新增了暂存物品、物品借还等业务以及人脸识别、语音识别等技术，后续也将增加零售、食品保鲜等业务服务。

从2019年9月项目立项时，整个研发团队只有4人，其中后端只有1人，一直到2020年3月项目第一版上线后才开始对外招聘，到目前为止研发团队已经有17人了，其中后端4人，后续也在持续招聘中。

项目立项后，在考虑到后续功能的扩展以及目前流行的服务架构后，决定选择SpringCloud作为后端主要的开发框架。在一开始后端只有一个人的时候，为了方便和快速完成功能的开发，每个服务的划分粒度比较大，部分不相关的业务被放在了一起。当项目越来越大，发布的时候可能会导致服务相互干扰，而当团队也越来越大的时候，也会影响团队间的协作开发。于此我们便开启了服务拆分之旅。

二、 快乐的烦恼-研发团队快速扩张

一方面项目的基本框架已经搭建完成，虽然已经实现了基本的业务功能，但仍然缺少很多影响用户体验的功能，需要更多的开发人员来加快迭代的速度，另一方面在项目的第一个版本发版之后，也正好是新冠疫情好转，全国复工不久，我们开始了研发团队的招聘工作。

研发团队开始扩张后，因为是初建的团队，加上开发流程规范还没有落地，导致开发初期团队协作的效率非常低。代码管理上虽然一开始就使用了git，但分支管理上没有做到很好的统一，发布流程也过于简单，没有有效的失败回滚方案。

而且服务端随着开发人员的增多，加上单个服务的业务复杂混乱，无法为每个人分配可以独立负责的业务模块，发布时也互相影响，因此决定进行服务拆分，使各服务尽量只处理一类业务，方便独立发布部署和员工责任分配。

三、 达摩克利斯之剑-微服务拆分

1.服务拆分的依据和准则

行业内拆分服务的依据主要是基于横向和纵向两个原则