本节介绍

前面我们介绍了Dubbo的基本使用，并且是使用的zookeeper作为其注册中心，但是Dubbo在注册中心存储的内容到底是什么呢？是什么样的结构呢？是持久化节点还是临时节点呢？带着这些疑问，我们对Dubbo在zookeeper中存储的内容一探究竟。

准备工作

其实我们在之前的zookeeper的系列博客中《(3)zookeeper常用命令及节点属性介绍》，我们已经介绍了zookeeper的常用命令，我们可以通过zkCli.sh连接上zookeeper，然后通过 ls、get 等命令查看zookeeper的节点信息。这里给大家介绍一个好用的工具，就是zookeeper的eclipse插件，通过这个插件我们可以更清楚的去查看zookeeper的各个节点的关系及内容。

在我们启动Duubo服务之前，连接上zookeeper集群的任意一台机器 192.168.74.4，可以看到只有 /zookeeper、/test 这两个节点。

开始测试

启动一台服务提供者

然后我们启动Dubbo服务提供者，然后再查看节点信息：

可以看到多了一个/dubbo节点，而/dubbo节点下面有一个子节点，/dubbo/com.wkp.service.simple.SimpleService，通过节点名称我们可以看到是我们暴露的接口名称，如果暴露多个接口的话/dubbo下面会有多个子节点；

/dubbo/com.wkp.service.simple.SimpleService下面又有两个子节点，分别是configurators和providers，而provider就是我们的服务提供者的注册信息，

configurators节点的内容是当前机器的ip地址

providers下面有个子节点名称为"dubbo%3A%2F%2F169.254.68.252%3A20880%2Fcom.wkp.service.simple.SimpleService%3Fanyhost%3Dtrue%26application%3Dsimple-provider%26dubbo%3D2.0.2%26generic%3Dfalse%26interface%3Dcom.wkp.service.simple.SimpleService%26methods%3DsayHello%2CgetUsers%26pid%3D152624%26retries%3D0%26side%3Dprovider%26timestamp%3D1542812445986"，这明显是被encode过，我们进行一下decode，得到内容为"dubbo://169.254.68.252:20880/com.wkp.service.simple.SimpleService?anyhost=true&application=simple-provider&dubbo=2.0.2&generic=false&interface=com.wkp.service.simple.SimpleService&methods=sayHello,getUsers&pid=152624&retries=0&side=provider&timestamp=1542812445986"，我们可以看到服务提供者的ip，端口号，暴露的接口，接口中有哪些方法，应用名，时间戳等信息，如果有多个服务提供者会有多个节点。当有消费者启动时，会订阅这些服务提供者列表，通过负载均衡机制去访问其中一个服务提供者，当服务提供者变更或者下线了，服务消费者会得到对应的通知。

再启动一台服务提供者

然后，我们可以改变一下simple-provider.xml中<dubbo:protocol name="dubbo" port="20990"/>的端口，由20880改为20990，接着运行Provider类又启动了一个服务者，我们再观察一下zookeeper的节点如下：很明显，providers下面多了一个节点，也就是新的服务提供者的信息。

 启动消费者

通过上面的方式我们看到了服务提供者的注册信息，下面我们启动服务消费者，然后再观察zookeeper的节点信息

我们发现，com.wkp.service.simple.SimpleService节点下多了两个节点，分别是consumers（服务消费者列表）和routers（服务路由，节点内容为当前机器ip）

consumers下面的子节点内容我们可以进行解码得到"consumer://169.254.68.252/com.wkp.service.simple.SimpleService?application=simple-consumer&category=consumers&check=false&dubbo=2.0.2&interface=com.wkp.service.simple.SimpleService&methods=sayHello,getUsers&pid=18368&side=consumer&timestamp=1542814359353"，里面是服务消费者的ip，调用的服务接口，接口包含的方法，时间戳等相关信息。

如果启动多个消费者的话，consumers节点下会有多个子节点，跟多个服务提供者的情况类似。

持久化节点？临时节点？

上面我们已经看到了Dubbo服务在zookeeper上存储的数据内容及结构，但是这些节点是持久化节点，还是临时节点呢？下面我们来通过实验验证一下：

首先我们把所有服务消费者关掉，观察zookeeper节点信息：我们发现consumers节点下的子节点消失了

然后我们把服务提供者全部关掉，再观察一下zookeeper节点信息的变化：providers下面的子节点也消失了

 得出结论：

1、dubbo节点、dubbo下面的接口、接口下面的providers、consumers、configurators、routers都是持久化节点

2、providers和consumers下面的URL子节点是临时节点，这个其实就是运用了zookeeper的临时节点的特效，消费端订阅服务提供者的URL：当某个服务提供者出现宕机，则会从providers下面的临时子节点中消失，这个时候会通知订阅了这个服务的消费者自己已经挂掉了，你把你本地存储的可用的服务提供者列表更新一下，不要再调用我了；当增加服务提供者时，providers下面会增加临时子节点，这个时候会通知订阅了这个服务的消费者新增了服务提供者，你把你本地存储的可用的服务提供者列表进行更新，有新的服务提供者可供调用了。

因为我是在本地运行的，ip都是同一个，你可以自己搭建虚拟机，看看如果在不同机器上部署服务提供者、消费者的话，configurators和routers的内容，因为我都是在一台机器上的，所以两者的内容都是"169.254.68.252"（也就是我的机器ip）。

ZooKeeper宕机之后，consumer和provider还能否通信？

可以。消费者从ZK获取provider地址列表后，会在本地缓存一份。当ZK注册中心所有节点全部宕掉之后，消费者可以使用本地缓存的服务列表和provider进行通信。
          ZK的意义在于为consumer和provider提供服务地址的发布/订阅服务，让消费者及时感知最新的服务列表，consumer真正调用provider是通过某种通信协议直接调用，并不依赖ZK。
         所以当zookeeper宕机之后，不会影响消费者调用服务提供者，影响的是zookeeper宕机之后如果提供者有变动，增加或者减少，zk无法把变更通知推送给consumer，consumer会因为感知不到变更时间，不去拉取最新的服务列表，导致本地缓存的服务列表有可能过时的。