(4)Dubbo服务之zookeeper注册中心

版权声明:欢迎转载,但是看在我辛勤劳动的份上,请注明来源,谢谢! https://blog.csdn.net/u012988901/article/details/84394168

本节介绍

前面我们介绍了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会因为感知不到变更时间,不去拉取最新的服务列表,导致本地缓存的服务列表有可能过时的。
 

展开阅读全文

没有更多推荐了,返回首页