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,这个时候调用以前的节点是可以的，但是无法调用新的节点，并且由于服务清单无法及时更新，可能会调用到不存在的服务。
