之前在因公司产品项目做微服务拆分时使用了dubbo和zokeeper但感觉对他们的认知还是不太清楚。所以最近重新复习看了一下。用通俗的方式些事一下（如有错误请指正）
zokeeper （注册中心）主要功能是服务注册与发现的注册中心。是用于分布式中一致性处理的框架（可以把注册中心比喻成一个信息网站，像58同城），以下为zokeeper主要工作：
- 数据发布订阅，即注册中心。 （如发布租房信息、查看租房信息）
- 负载均衡
- 命名服务。zookeeper的节点结构天然支持命名服务，即把信息集中存储，并以树状管理，方便统一查阅。
- 分布式协调通知。协调通知实际上与发布订阅类似，由于引入的第三方的zookeeper，实际上对很多种协调通知做了解耦。
- 集群管理与master选举。通过上面的第二点特性，可以轻易得知集群机器存活状况，从而轻松管理集群；通过上面第一点特性，可以做出master争抢。
- 分布式锁。实际上就是第一点特性的应用。
- 分布式队列。实际上就是第三点特性的应用。
- 分布式的并发等待。类似于多线程的join问题，主任务的执行依赖于其他子任务全部执行完毕，在单机多线程里可以用join，但是分布式环境下如何实现呢。利用zookeeper，可以创建一个主任务节点，旗下子任务一旦执行完毕，则在主任务节点下挂一个子任务节点，等节点数量足够，则认为主任务可以开始执行。
dubbo （远程服务调用的分布式框架）主要实现应用与zokeeper等注册中心链接调用的工具（类jdbc工具类），dubbo为你实现了低层中的注册、订阅、调用等功能，让使用者专注于业务。（可以比喻为信息的用户，发布租房信息《提供服务》，查看租房信息《服务消费者》）
以下为dubbo的主要工作：
0 服务容器负责启动，加载，运行服务提供者。
1. 服务提供者（生产者）在启动时，向注册中心注册自己提供的服务。（发布自己的租房信息）
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。（找租房信息）
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。（信息网站提供租房的地址详情）
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。（到租房地实际看房）
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（记录看房等监控信息）
这么理解的话比较简单，把zokeeper理解为信息网站、dubbo理解为信息发布者和消费者 ，那么就可以理解他们的关系。
以上是我对dubbo与zokeeper他们关系的理解，如有不正确的希望指正。
