dubbo 和 zokeeper 是分别用来作什么的?他们的关系究竟是怎么样的？

以前在因公司产品项目作微服务拆分时使用了dubbo和zokeeper但感受对他们的认知仍是不太清楚。因此最近从新复习看了一下。用通俗的方式些事一下（若有错误请指正）

zokeeper （注册中心）主要功能是服务注册与发现的注册中心。是用于分布式中一致性处理的框架（能够把注册中心比喻成一个信息网站，像58同城），如下为zokeeper主要工做：

1. 数据发布订阅，即注册中心。 （如发布租房信息、查看租房信息）

2. 负载均衡

3. 命名服务。zookeeper的节点结构自然支持命名服务，即把信息集中存储，并以树状管理，方便统一查阅。

4. 分布式协调通知。协调通知实际上与发布订阅相似，因为引入的第三方的zookeeper，实际上对不少种协调通知作了解耦。

5. 集群管理与master选举。经过上面的第二点特性，能够轻易得知集群机器存活情况，从而轻松管理集群；经过上面第一点特性，能够作出master争抢。

6. 分布式锁。实际上就是第一点特性的应用。

7. 分布式队列。实际上就是第三点特性的应用。

8. 分布式的并发等待。相似于多线程的join问题，主任务的执行依赖于其余子任务所有执行完毕，在单机多线程里能够用join，可是分布式环境下如何实现呢。利用zookeeper，能够建立一个主任务节点，旗下子任务一旦执行完毕，则在主任务节点下挂一个子任务节点，等节点数量足够，则认为主任务能够开始执行。

 

dubbo （远程服务调用的分布式框架）主要实现应用与zokeeper等注册中心连接调用的工具（类jdbc工具类），dubbo为你实现了低层中的注册、订阅、调用等功能，让使用者专一于业务。（能够比喻为信息的用户，发布租房信息《提供服务》，查看租房信息《服务消费者》）

如下为dubbo的主要工做：

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

1. 服务提供者（生产者）在启动时，向注册中心注册本身提供的服务。（发布本身的租房信息）

2. 服务消费者在启动时，向注册中心订阅本身所需的服务。（找租房信息）

3. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。（信息网站提供租房的地址详情）

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

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（记录看房等监控信息）

 

 

这么理解的话比较简单，把zokeeper理解为信息网站、dubbo理解为信息发布者和消费者 ，那么就能够理解他们的关系。

 

以上是我对dubbo与zokeeper他们关系的理解，若有不正确的但愿指正。