前序
额,十分遗憾,这次并不是分享BUG了,所以不能让大家看到我出糗的样子了,而且,这次也没有太多技术性的内容,多少会显得有些枯燥乏味。不过呢,可能本次所涉及到的项目迁移拆分方案,在诸位看来也并非完美,所以各位还是有机会批评一波,娱乐一波。
背景
话不多说,我们先来谈谈这次这次项目迁移拆分的背景。
经典模型
我们先来看看目前大多数微服务框架的系统架构,这里以Dubbo为RPC服务基础,并且用传统的电商业务模型(熟知我的观众肯定知道,我向来是保护公司业务代码的,所以这里使用大家广泛熟知的业务模型为例)。
简单讲解下:
- 这是一件简单的电商业务模型,在微服务业务细分下,分为用户服务、商品服务、交易服务、仓储服务、售后物流服务、财务服务。(要是具体细分以及其他服务的就不在这里多说)
- 微服务架构采用Dubbo作为服务治理框架,各个服务通过Dubbo进行RPC通信。
- 各个服务当中涉及到的实体类、工具类、Dubbo接口等放在公共接口服务当中(我也不知道该怎么说,其实就是一个公共的jar包,不能说是一个服务,但现在姑且这么称呼吧),由各自业务服务web工程进行引用,其实就是在maven的pom文件当中引用。
以上可能是最简单的一个模型,当然在业务、架构上各个公司都有自己的方案以及扩展之类的,这就不再考虑之内,但是其实核心还是围绕着这个最原始的模型。
当前现状
那么现在遇到了什么问题?我们再来看看这样一个模型。各自的业务服务web工程都会对这个公共服务进行依赖,这本身也没什么问题,毕竟这里面放的都是一些Dubbo接口等,具体的实现类还是在各自的服务工程当中。但是问题来了,不知道从什么时候开始,这个模型发生了变化,就是所有的实现类都写在了这个公共接口服务里面。
由于这本身就是多模块的maven工程,于是各自的web工程引用自己所需要的那一部分module。于是所有的web工程只是一些不同环境profile下的配置文件。这个就与上面的模型的初衷背道而驰。如图所示:
产生影响
那么这样会有什么问题:
- 项目结构的问题。所有人的代码都在这个公共接口服务当中,使得结构变得很混乱,对于web工程甚至会引用不属于自己的module,例如商品服务当中引用了财务的实现类,本质上走的是dubbo协议,web工程反而引入了一些多余的jar,甚至还会引起maven的依赖优先的问题,造成事故的风险点。(maven的