zoukankan      html  css  js  c++  java
  • 【原】从零开始改造淘淘商城(引入dubbo解决项目耦合)02

    前言:

      关于为什么要引入dubbo框架,而不是用spring cloud或者是motan呢,主要是笔者现在公司用的就是dubbo,并且第一次接触到微服务的概念是来源于dubbo,再加上最近dubbo频繁的更新,所以就有采用dubbo改造的想法。建议没看过这个教程的园友可以先看看原来的教程,因为现在所改造的是基于原来的教程源码上重构的版本。

    •      首先看下改造前的一个版本如下(前台主站):

         

     

       通过上图可知portal不负责db操作,而是通过调用rest项目完成数据更新或查询;笔者现在的公司项目也有很多这种调用方式,主要原因是因为调用方是一个非常古老的项目,系所采用的架构是ssh,且项目比较庞大,耦合度很高,并且大量的业务逻辑代码挤压在一起,短时间内无法重构成微服务,所以目前用的也是httpclient方式去调用rest服务。这种方式有几个不好的地方如下:

    1. 后续加了一个新的服务调用地址,需要在对应的配置文件里配置地址,大量的配置文件出现会导致项目难以管理,维护成本变高。
    2. http的3次握手以及传输过程中的网络开销等等。
    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

    • 重构后项目结构如下:

  • 相关阅读:
    趣题:寻找出现了奇数次的数
    zstu2016校赛圣杯战争
    HDU 5183 Negative and Positive (NP) ——(后缀和+手写hash表)
    HDU 5673 Robot ——(卡特兰数)
    HDU 3775 Chain Code ——(Pick定理)
    2016 ICPC北京站现场赛总结(再度流水账)
    2014苏州大学新生赛第二场(12.10)题目解析
    【Jump Game II 】cpp
    【Jump Game】cpp
    【 Sqrt(x) 】cpp
  • 原文地址:https://www.cnblogs.com/zdd-java/p/7900848.html
Copyright © 2011-2022 走看看