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. 服务容器负责启动，加载，运行服务提供者。

服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者在启动时，向注册中心订阅自己所需的服务。

注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

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 消费者和提供者的调用关系），如果调用失败，再选另一台调用