Zookeeper作为Dubbo服务治理中心

前言

前几天被人问到这样的一个问题：当我们使用Zookeeper作为Dubbo的注册中心时，我们如果启动新的服务提供者怎么被其他节点检测到，我们都知道节点的注册信息都会放在一个服务清单里面，所以这个问题可以理解为Zookeeper是怎么样创建并维护这个服务清单的？

分布式可参考我的博客：溪源的Java笔记—分布式

微服务可参考我的博客：溪源的Java笔记—微服务

正文

Zookeeper作为Dubbo服务治理中心

首先我们要知道Zookeeper提供了一给类似于Linux文件系统的树状结构（可认为是轻量级的内存文件系统，但是适合寸少量信息，如元数据），同时提供了对于每个节点的监控与通知机制；
Zookeeper作为注册中心就是基于这个轻量级的文件系统实现；

我们假设服务提供者接口是： com.bob.dubbo.service.CityDubboService，那么Zookeeper就会创建如下路径，/dubbo/com.bob.dubbo.service.CityDubboService/providers/providerURL：

第一层节点：根结点默认为dubbo
第二层节点：服务节点全路径com.bob.dubbo.service.CityDubboService
第三层节点：服务目录，包括providers(提供者目录)，consumers(消费者目录)，configurators(配置目录)，routers(路由目录)
第四次节点（临时）：providerURL具体服务节点，节点名为具体的 URL 字符串：如dubbo://IP:12345/com.bob.dubbo.service.CityDubboService?xx=xx

Dubbo RPC 基于Zookeeper的服务注册、发现过程如下：

服务提供者启动时，会将其服务名称，IP地址注册到配置中心。
服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的IP地址列表，并缓存到本地，以供后续使用。当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从IP列表中取一个服务提供者的服务器调用服务。（所以注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯）
当服务提供者的某台服务器宕机或下线时，相应的IP会从服务提供者IP列表中移除。同时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。（服务提供者无状态，任一台宕机后，不影响使用,会切换其它正常的节点）
当某个服务的所有服务器都下线了，那么这个服务也就下线了。
同样，当服务提供者的某台服务器上线时，注册中心会将新的服务IP地址列表发送给服务消费者机器，缓存在消费者本机。
服务提供方可以根据服务消费者的数量来作为服务下线的依据。

Zookeeper作为服务治理中心的劣势：

当注册中心的服务规模超过一定数量的时候，zk性能上不支持很高的tps和TCP长连接；
Zookeeper采用的CP模式，它为保证数据的一致性放弃了可用性，比如3个机房，5个zk节点（2、2、1），当3号机房出现了网络分区，这个时候各个分区就会开始选举Leader,这个时候调用以前的节点是可以的，但是无法调用新的节点，并且由于服务清单无法及时更新，可能会调用到不存在的服务。