Java-Dubbo

转载：https://blog.csdn.net/u012453843/article/details/65937993

taotao商城是基于soa的架构，表现层和服务层是不同的工程。所以要实现商品列表查询需要两个系统之间进行通信。

SOA架构：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

 如何实现远程通信？

       1.WebService：效率不高，基于soap协议。在项目中不推荐使用。

       2.使用restful形式的服务：http+json。很多项目中应用。但是有个缺点是，如果服务太多，服务之间的调用关系就非常混乱，需要治疗服务。

       3.使用dubbo。使用 rpc协议 进行远程调用，直接使用socket通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。但是dubbo也有个比较大的缺点，那就是使用它的工程必须都是用java开发的才行，如果一个用的java，另一个用的PHP，就无法使用dubbo。
　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。Dubbo架构发展路线图如下。

　　

         从上图可以看到，发展经历了四个阶段：

　　第一阶段：单一应用架构

      当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。其中1~10的意思是，当一个tomcat服务无法满足要求时，我们可以增加部署tomcat的数量并用反向代理来做负载均衡。由于不同的tomcat之间session要共享，方法就是要定时向其它节点进行广播，其它tomcat发现发现与之不同时便会进行同步，当节点数量较多时，广播将会占用大部分带宽，以至于真正的通信所用的带宽严重不足。因此该架构只能用于节点数小于10的情况。

　　第二阶段：垂直应用架构

       当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。举个例子，比如把一个大的项目拆分成订单系统、会员系统、前台系统、后台系统、搜索系统，每个系统自成一家，服务层和web层都在一起，哪个系统压力大，就给那个系统增加节点以提升性能。此时用于加速前端开发的Web框架(MVC)是关键。

　　第三阶段：分布式服务架构

       当垂直应用越来越多，应用之间交互不可避免，这时代码将非常臃肿（因为同一套代码逻辑可能会被写多遍）。这时将核心业务抽离出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能够更快速的响应市场需求。此时用于提高业务复用及整合的分布式服务框架(RPC)是关键。

　　第四阶段：流动计算架构

       当服务越来越多，容量的评估、小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时用于提高机器利用率的资源调度和治理中心(SOA)是关键。