一个电商项目的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个图，在做培训的时候，部分哥们有一些疑问，费了很大劲，才解释清楚。
对新人来说，反而更容易理解一些，因为他没有自己固有的思维定势，更容易接受新的架构思路。

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