Dubbo简单介绍及其和zookeeper的关系

何为Dubbo

​　　Dubbox 是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo ，被国内电商及互联网项目中使用，后期阿里巴巴中止了该项目的维护，当当网便在Dubbo基础上进行优化，并继续维护，为了与原有的Dubbo区分，故将其命名为Dubbox。

​　　Dubbox 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox就是个服务框架，若是没有分布式的需求，实际上是不须要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，而且本质上是个服务调用的东西，说白了就是个远程服务调用的分布式框架。

　　SOA是Service-Oriented Architecture的首字母简称，它是一种支持面向服务的架构样式。从服务、基于服务开发和服务的结果来看，面向服务是一种思考方式。

 

Dubbo能作什么？

最简单直接的说法就是：dubbo自己是一个程序，在开发中做为jar包供咱们使用，dubbo为咱们作的就是根据服务的url去调用服务（基于rpc协议的调用）。

透明化的远程方法调用，就像调用本地方法同样调用远程方法，只需简单配置，没有任何API侵入。      
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，下降成本，减小单点。
服务自动注册与发现，再也不须要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，而且可以平滑添加或删除服务提供者。

 

Dubbo基于RPC（Remote Procedure Call 远程过程调用）协议，服务提供方和服务消费方之间的调用关系：

节点角色说明：

• Provider: 暴露服务的服务提供方。

• Consumer: 调用远程服务的服务消费方。

• Registry: 服务注册与发现的注册中心。

• Monitor: 统计服务的调用次调和调用时间的监控中心。

• Container: 服务运行容器。

调用关系说明：

0. 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者在启动时，向注册中心注册本身提供的服务。

2. 服务消费者在启动时，向注册中心订阅本身所需的服务。

3. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

 

Dubbo 属于 RPC 框架，链接消费者和生产者，注册中心 监控被调用对象的运行状态

Dubbo提供的注册中心有以下几种类型可供选择：

• Multicast注册中心
• Zookeeper注册中心
• Redis注册中心
• Simple注册中心

 

dubbo和zookeeper的关系：

对于注册中心的选择，咱们通常用Zookeeper，那么zookeeper和dubbo的关系是怎么样的

上面这个图若是看不太懂的话，建议看一下 ZooKeeper的数据模型 ，这里简单解释一下：

zookeeper的数据模型跟咱们windows系统下的文件模型类似，都是树形结构的;

　　windows下的文件系统有文件夹和文件两种，文件夹只是路径，文件才是存储体；

　　而zookeeper的数据模型也是树结构的，每一个节点叫作znode，每一个znode既能够存储数据也能够当作路径

 

树形结构的节点都是惟一的，而上面这个图上的绿色圆点都是zookeeper中的一个znode，每一个znode都有本身的路径和本身的值，存储着咱们dubbo注册的service信息，而上面这张图的znode分为4级（root、service、type、url）：

• 一级节点root内存储着dubbo，表明这个znode下的全部znode都是dubbo相关的
• 二级节点service存储着咱们dubbo注册到zk中的service名称，每多注册一个service服务，就会在dubbo这个znode下添加一个新的service节点
• 三级节点type存储着service类型，是提供者仍是消费者
• 四级节点url存储着咱们所注册的服务的具体地址

dubbo就是经过这一层层的节点找到咱们须要调用的url而后进行调用的。

 

zookeeper做为dubbo的注册中心的角色使用

咱们把提供者和消费者经过dubbo注册到zookeeper这个注册中内心，zookeeper中存储的是服务的url的列表

经过消费者调用提供者服务的时候，会根据接口的名称类型经过dubbo到zookeeper中找到对应的服务的url列表，zookeeper返回服务提供者地址列表给消费者

消费者从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用（这个调用就是图1 消费者和提供者的调用关系），若是调用失败，再选另外一台调用