之前在因公司产品项目做微服务拆分时使用了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他们关系的理解,如有不正确的希望指正。