前言：
关于为什么要引入dubbo框架，而不是用spring cloud或者是motan呢，主要是笔者现在公司用的就是dubbo,并且第一次接触到微服务的概念是来源于dubbo，再加上最近dubbo频繁的更新，所以就有采用dubbo改造的想法。建议没看过这个教程的园友可以先看看原来的教程,因为现在所改造的是基于原来的教程源码上重构的版本。
-
首先看下改造前的一个版本如下（前台主站）：
通过上图可知portal不负责db操作,而是通过调用rest项目完成数据更新或查询;笔者现在的公司项目也有很多这种调用方式,主要原因是因为调用方是一个非常古老的项目，系所采用的架构是ssh,且项目比较庞大,耦合度很高,并且大量的业务逻辑代码挤压在一起,短时间内无法重构成微服务,所以目前用的也是httpclient方式去调用rest服务。这种方式有几个不好的地方如下：
- 后续加了一个新的服务调用地址,需要在对应的配置文件里配置地址,大量的配置文件出现会导致项目难以管理,维护成本变高。
- http的3次握手以及传输过程中的网络开销等等。
- 由于是在service层发起http请求,Controller直接调用工程里的service,如果某天service下面的ItemService需要部署更新,由于这些代码都是在放在同一个项目不同包的下面,是一个整体,必然会导致淘淘商城里面的OrderService,SerachService,CartService等不需要维护的也不能正常提供服务。
-
解决办法：
- 统一服务接口层,服务接口层只负责对外提供服务,调用方只负责调用的服务接口; 假如某天服务提供者需要部署更新,那么只需要部署对应的服务, 比如订单服务,更新的的只是订单服务,不会影响其他服务的提供,同理调用方也不会因为订单服务要维护导致调用方也跟着受影响,顶多就是当前更新的这个服务用不了而已,简单来说就是减少颗粒度范围。
-
重构思路：
将每个项目中的service接口层提取出来,放到taotao-service-api里,然后将taotao-manager-service做成服务提供者,实现taotao-service-api所有的接口,也就是dubbo里面的Provider;将rest、portal项目作为dubbo里面的Consumer角色,引用taotao-service-api。
-
重构后项目结构如下：
