由于商城是基于 soa 的架构，表现层和服务层是不同的工程。所以要实现商品列表查询需要两个系统之间进行通信。
如何实现远程通信？
1. WebService ：效率不高，基于 soap 协议。在项目中不推荐使用。
2. 使用 restful 形式的服务： http+json 。很多项目中应用。但是有个缺点是，如果服务太多，服务之间的调用关系就非常混乱，需要治疗服务。
3. 使用 dubbo 。使用 rpc 协议进行远程调用，直接使用 socket 通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。但是 dubbo 也有个比较大的缺点，那就是使用它的工程必须都是用 java 开发的才行，如果一个用的java，另一个用的PHP，就无法使用dubbo。
什么是dubbo？
随着网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。Dubbo架构发展路线图如下。
从上图可以看到，发展经历了四个阶段：
1. 单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架 （ORM） 关键。其中1~10的意思是，当一个tomcat服务无法满足要求时，我们可以增加部署tomcat的数量并用反向代理来做负载均衡。由于不同的tomcat之间session要共享，方法就是要定时向其它节点进行广播，其它tomcat发现发现与之不同时便会进行同步，当节点数量较多时，广播将会占用大部分带宽，以至于真正的通信所用的带宽严重不足。因此该架构只能用于节点数小于10的情况。
2. 垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。举个例子，比如把一个大的项目拆分成订单系统、会员系统、前台系统、后台系统、搜索系统，每个系统自成一家，服务层和web层都在一起，哪个系统压力大，就给那个系统增加节点以提升性能。此时用于加速前端开发的Web框架(MVC)是关键。
3. 分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，这时代码将非常臃肿（因为同一套代码逻辑可能会被写多遍）。这时将核心业务抽离出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能够更快速的响应市场需求。此时用于提高业务复用及整合的分布式服务框架(RPC)是关键。
4. 流动计算架构
当服务越来越多，容量的评估、小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心(SOA)是关键。
下面我们来看下 Dobbo 的架构：
第0步是服务提供者的发布， provider 的发布需要用到容器，我们的 spring 便是专门用来做容器的，因此服务提供者的发布需要用到 spring 。
第1步是进行注册，就是说服务提供者在发布之后，要在dubbo的注册管理中心进行注册，扮演Registry（注册中心的最好是zookeeper，其次可以选择redis），这样注册中心便知道有哪些服务可供消费者使用了。
第2步是消费者要调用服务，但是它是不知道有哪些服务可供调用的，因此它需要先到注册中心进行询问，查询一下是否有自己想要调用的服务。
第3步注册中心查找之后发现有匹配的服务可供调用，便会向消费者返回可供调用的服务的IP和端口号。
第4步消费者拿到IP和端口号之后，便不再需要经过注册中心，直接就可以访问服务了（这就是第4步）
第5步是指dobbo想要监测都是哪些消费者调用了哪些服务，调用了多少次，这样便于管理。
上图的节点角色说明：
1. Provider：暴露服务的服务提供方。
2. Consumer：调用远程服务的服务消费方。
3. Registry：服务注册与发现的注册中心。
4. Monitor：统计服务的调用次数和调用时间的监控中心。
5. Container：服务运行容器。
调用关系说明：
0.服务容器负责启动、加载，运行服务提供者。
1.服务提供者在启动时，向注册中心注册自己提供的服务。
2.服务消费者在启动时，向注册中心订阅自己所需的服务。
3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5.服务消费者和服务提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。