Dubbo和Zookeeper的关系

大部分内容来自网上

Dubbo建议使用Zookeeper作为服务的注册中心。

节点角色说明：

Provider：暴露服务的服务提供方；
Consumer：调用远程服务的服务消费方；
Register：服务注册与发现的注册中心；
Monitor：统计服务调用次数和调用时间的监控中心；
Constainer：服务运行容器。
调用关系说明：

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

首先我们应该清楚Zookeeper是什么？作用？

zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。当然也可以 通过硬编码的方式把这种对应关系在调用方业务代码中实现，但是如果提供服务的机器挂掉调用者无法知晓，如果不更改代码会继续请求挂掉的机器提供服务。 zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。至于支持高并发，简单来说就是横向扩展，在不更改代码 的情况通过添加机器来提高运算能力。通过添加新的机器向zookeeper注册服务，服务的提供者多了能服务的客户就多了。

dubbo是什么？

它是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。
注意这里的dubbo只是一个框架，至于你架子上放什么是完全取决于你的，就像一个汽车骨架，你需要配你的轮子引擎。这个框架中要完成调度必须要有一个分布式的注册中心，储存所有服务的元数据，你可以用zk，也可以用别的，只是大家都用zk。

zookeeper和dubbo的关系

简单来说打个比方：dubbo就是动物园的动物，zookeeper是动物园。如果游客想看动物的话那么就去动物园看。比如你要看老虎，那么动物园有你才能看到。换句话说我们把很多不同的dubbo（动物）放到zookeeper（动物园中）提供给我们游客进行观赏。

Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。

引入了ZooKeeper作为存储媒介，也就把ZooKeeper的特性引进来。首先是负载均衡，单注册中心的承载能力是有限的，在流量达到一定程度的时 候就需要分流，负载均衡就是为了分流而存在的，一个ZooKeeper群配合相应的Web应用就可以很容易达到负载均衡；资源同步，单单有负载均衡还不 够，节点之间的数据和资源需要同步，ZooKeeper集群就天然具备有这样的功能；命名服务，将树状结构用于维护全局的服务地址列表，服务提供者在启动 的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址，这个操作就完成了服务的发布。 其他特性还有Mast选举，分布式锁等。

点下广告再走呗