记一次工作中微服务项目迁移拆分的过程

前序

额，十分遗憾，这次并不是分享BUG了，所以不能让大家看到我出糗的样子了，而且，这次也没有太多技术性的内容，多少会显得有些枯燥乏味。不过呢，可能本次所涉及到的项目迁移拆分方案，在诸位看来也并非完美，所以各位还是有机会批评一波，娱乐一波。

背景

话不多说，我们先来谈谈这次这次项目迁移拆分的背景。

经典模型

我们先来看看目前大多数微服务框架的系统架构，这里以Dubbo为RPC服务基础，并且用传统的电商业务模型（熟知我的观众肯定知道，我向来是保护公司业务代码的，所以这里使用大家广泛熟知的业务模型为例）。

简单讲解下:

1. 这是一件简单的电商业务模型，在微服务业务细分下，分为用户服务、商品服务、交易服务、仓储服务、售后物流服务、财务服务。（要是具体细分以及其他服务的就不在这里多说）
2. 微服务架构采用Dubbo作为服务治理框架，各个服务通过Dubbo进行RPC通信。
3. 各个服务当中涉及到的实体类、工具类、Dubbo接口等放在公共接口服务当中（我也不知道该怎么说，其实就是一个公共的jar包，不能说是一个服务，但现在姑且这么称呼吧），由各自业务服务web工程进行引用，其实就是在maven的pom文件当中引用。

以上可能是最简单的一个模型，当然在业务、架构上各个公司都有自己的方案以及扩展之类的，这就不再考虑之内，但是其实核心还是围绕着这个最原始的模型。

当前现状

那么现在遇到了什么问题？我们再来看看这样一个模型。各自的业务服务web工程都会对这个公共服务进行依赖，这本身也没什么问题，毕竟这里面放的都是一些Dubbo接口等，具体的实现类还是在各自的服务工程当中。但是问题来了，不知道从什么时候开始，这个模型发生了变化，就是所有的实现类都写在了这个公共接口服务里面。
由于这本身就是多模块的maven工程，于是各自的web工程引用自己所需要的那一部分module。于是所有的web工程只是一些不同环境profile下的配置文件。这个就与上面的模型的初衷背道而驰。如图所示:

产生影响

那么这样会有什么问题:

1. 项目结构的问题。所有人的代码都在这个公共接口服务当中，使得结构变得很混乱，对于web工程甚至会引用不属于自己的module，例如商品服务当中引用了财务的实现类，本质上走的是dubbo协议，web工程反而引入了一些多余的jar，甚至还会引起maven的依赖优先的问题，造成事故的风险点。（maven的