一个电商项目的Web服务化改造5:面向服务的分层架构设计(有图有真相)

  最近一直在做一个电商项目,需要把原有单系统架构的项目,改造成基于服务的架构,SOA。
    有点挑战,做完了,会有很大进步。

    本篇,以我亲自画的3个图,阐述一下架构设计。 


   一、分层架构-总体图


    1.服务提供方和服务调用方,通过接口交互,调用方并不需要知道怎么实现的。
    2.层次划分
       mapper:Mybatis接口映射,原子数据库操作
       dao:数据访问层(或者换个更合适的名字)调用mapper,组装数据,比如商品详情信息,除了需要商品信息,还需要知道商品的品牌信息
       service:业务逻辑层:订单支付,金额是否足够,是否能够参加这个优惠活动等
       webservice: 由于我们的业务逻辑比较简单,直接把业务层的接口,稍微包装下,就暴露出去了,逻辑上可以说是一个层的。有些大型项目,可能把WebService作为service的上层,而非平级的。
   3.同层之间不能相互调用,上层可以调用1个或多个下层的接口
   4.面向接口编程
      通过接口定义操作,不需要关注实现
 
二、分层架构-类图


   1.以品牌Brand为例,针对外界3套系统,定义了3套WebService接口,FrontBrandService针对前端商城系统、MobileBrandService针对移动端App,BackendBrandService针对后端运营系统。
     每个系统的接口,都是单独定义的,互补影响,前端商城系统调用方,只需要它应该有接口服务。
   2.内部实现类BrandServiceImpl,一次性实现了3个接口,当然也可以定义3个实现类,分别实现。
  

三、系统架构图


1、接口服务,有商品、订单、用户等,每个服务都会针对3套系统,有3个接口实现。
2、接口服务,启动的时候,把服务信息注册到Zookeeper。
3、服务调用方,启动的时候,去Zookeeper查找服务。
4、服务调用方,比如前端商城系统,有自己的Controller和Service。
    Controller响应请求,调用Service,在Service中调用WebService中的1个或多个服务,组装数据。
    也就是说,服务调用方,基本没有业务逻辑,业务逻辑全部在接口提供方统一处理了。
    另外,前端商城系统,虽说有自己的service,但是从实质上来说,这个地方的service和Controller都可以理解成是“展现层”的。
 5.接口提供方,负责业务逻辑和底层实现,其它3个系统,只是响应URL,做下展示罢了。

个人观察
  最近自己画了不少图,感觉画图比较费时间,但是效果会比较好,可以把总体的思路,清晰地展示出来。
  具体到上面3个图,在做培训的时候,部分哥们有一些疑问,费了很大劲,才解释清楚。
  对新人来说,反而更容易理解一些,因为他没有自己固有的思维定势,更容易接受新的架构思路。

  怎么样,哥的架构设计还行吧。。。
  感谢若干大牛对小弟的耐心指点。。。 
  大笑奋斗大笑

转载于:https://www.cnblogs.com/qitian1/p/6462426.html

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页