Dubbo 今天终于讲明白了

Dubbo是什么？

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行。

• 单一应用架构

• 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

• 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

• 垂直应用架构

• 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

• 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

• 分布式服务架构

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

• 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

• 流动计算架构

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

• 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

Dubbo就是资源调度和治理中心的管理工具。

Dubbo的架构

• 节点角色说明：

Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。

- 调用关系说明：

• 服务容器负责启动，加载，运行服务提供者。
• 服务提供者在启动时，向注册中心注册自己提供的服务。
• 服务消费者在启动时，向注册中心订阅自己所需的服务。
• 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
• 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
• 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

项目中实际中发布服务，以及调用方调用服务过程

发布服务：

<!-- 使用dubbo发布服务
	    1.定义服务发布方的应用名称
	    2.提供注册中心zookeeper的地址，与端口
	    3.用dubbo协议在20880端口暴露服务
	    4.声明需要暴露的服务接口
	-->
	<dubbo:application name="oa-manager"/>
	<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"/>
	<dubbo:protocol name="dubbo" port="20880"/>
	<dubbo:service interface="com.zrj.service.TbItemService" ref="tbItemServiceImpl" timeout="300000"/>

这里的  ref="tbItemServiceImpl"  这个没有在上面定义
<bean id="tbItemServiceImpl" class="com.zrj.TbItemServiceImpl" />
是因为服务层有@service  注解，默认是类的全称，首字母小写，并交由spring容器管理，所以这里能直接，引用 tbItemServiceImpl，直接从spring容器中取出来。

调用服务：

<!--引用dubbo服务
	  1.提供消费服务方的应用名称
	  2.指明注册中心zookeeper的地址
	  3.引用服务
	-->
	<dubbo:application name="taotao-manager-web"/>
	<dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"/>
	<dubbo:reference interface="com.taotao.service.TbItemService" id="tbItemService"/>

这样就能通过
@Autowired
private TbItemService tbItemService; 来调用服务。