dubbo zookeeper,如何查看Zookeeper下Dubbo的Provider与Consumer信息

dubbo zookeeper,如何查看Zookeeper下Dubbo的Provider与Consumer信息详细介绍

本文目录一览： dubbo和zookeeper

dubbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( dubbo://x.x.x.x )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。
Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。
咱们来看下Spring 配置声明暴露服务，provider.xml文件
再来看服务消费者，consumer.xml文件
这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。
配置多个服务调用者在comsumer.xml的dubbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的dubbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：
那么目前的架构有什么问题呢？ 1.当服务提供者增加节点时，需要修改配置文件。 2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。
这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：
如果zookeeper是一个集群，则多个地址之间用逗号分隔即可
把consumer.xml中配置的直连的方式去掉
注册信息在zookeeper中如何保存？ 启动上面服务后，我们观察zookeeper的根节点多了一个dubbo节点及其他，图示如下
最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。 其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如dubbo会创建一个/dubbo节点，storm会创建一个/storm节点。
zookeeper 介绍： zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。
流程说明：
支持以下功能：
补充： dubbo的协议使用什么序列化框架？ dubbo有多种协议，不同的协议默认使用不同的序列化框架。比如dubbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，http协议默认为为 json。
dubbo的通信方式？ 采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer 收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC 调用。
zookeeper选举机制？ zookeeper选举算法默认的是FastLeaderElection，选举机制的概念： 1.服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。 2.事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。 3.逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。 选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。 初次选举简述： 目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下： 1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。 2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。 3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。 4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。 5.服务器5启动，后面的逻辑同服务器4成为小弟。 如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态 ，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
引用： https://www.cnblogs.com/iisme/p/10620125.html

分布式天花板？阿里百万架构师的ZK+Dubbo笔记，颠覆认知

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式锁服务、集群管理、生成分布式唯一ID等。
Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，提供面向接口代理的高性能RPC调用、智能负载均衡、服务自动注册和发现、运行期流量调度、可视化服务治理和运维等功能。
作为架构师必须掌握的分布式架构技术， 你的我（雷锋）在这个星期费心费力给大家着重收集并整理了这份关于ZooKeeper+Dubbo技术栈的源码+笔记+项目实战的资料。
以上就是资料包含的内容，下面我会展示目录和详细内容截图，有需要完整版源码+笔记的朋友，只有点赞+关注，然后在我的主页私信【分布式】即可免费领取！！
一：Zookeeper篇
1.分布式概述
2.ZK概述
3.分布式CAP
4.一致性实现
5.ZK单机&集群搭建
6.ZK快速入门
7.ZK源码解析
8.ZK应用场景
9.分布式锁和队列
二：Dubbo篇
1.RPC核心
2.手写RPC
3.Dubbo高可用
4.Dubbo IO模型
5.Dubbo 架构
6.源码解析
第一部分Nginx能帮我们做什么
第二部分如何编写HTTP模块
第三部分深入Nginx
有需要完整版源码+笔记的朋友：

Dubbo与Zookeeper集群配置

dubbo.properties配置：

dubbo.application.name=sdp_order_srv

#zk集群的时候dubbo只能这样配置

dubbo.service.register.address=zookeeper://10.10.100.152:3181?backup=10.10.100.152:4181,10.10.100.152:5181

#zk单点的话下面两种配置都可以

#dubbo.service.register.address=zookeeper://${zookeeper.address}

#dubbo.service.register.address=zookeeper://10.1.203.171:2181

dubbo.service.protocol.name=dubbo

dubbo.service.protocol.port=20885

zk配置

#\u7cfb\u7edf\u53c2\u6570\u914d\u7f6e

zookeeper.sessionTimeout=60000

zookeeper.connectionTimeout=5000

#zk集群配置

zookeeper.address=10.10.100.152:3181,10.10.100.152:4181,10.10.100.152:5181

zookeeper.connect.status=true

zookeeper.connect.countersign=false

zookeeper.connect.username=

zookeeper.connect.password=

Dubbo注册中心

Dubbo的注册中心承担着Dubbo服务的注册与发现的功能。
Dubbo支持的注册中心主要包括：
其中dubbo官方推荐用Zookeeper作为注册中心，下面介绍 ZookeeperRegistry 。
Dubbo在Registry层实现服务的注册于发现，主要包括如下几个类：
流程说明 ：
RegistryProtocol 是对需要暴露服务到注册中心的一层封装，通过 RegistryProtocol 实现将暴露的服务信息注册到注册中心。
ZookeeperRegistry 是通过 ZookeeperRegistryFactory 创建。
说明：
上面是 AbstractRegistryFactory#getRegistry 方法根据URL获取对应注册中心，真正的创建在子类的 createRegistry 方法中实现。
注意 ：
ZookeeperTransporter 才是真正与Zookeeper通信的对象。默认的Zookeeper客户端是curator。
ZookeeperRegistry 在创建时便和Zookeeper创建了连接。
Zookeeper的服务注册就是创建Zookeeper的节点。
根据url对象构建一个URL的 Path ，然后在Zookeeper上创建一个节点，节点是否是持久化的根据 dynamic 参数决定， true 表示创建一个持久化节点，当注册方下线时，持久化节点仍然在Zookeeper上。 false 表示创建临时节点，当注册方下线时，会删除节点，同时通知监听节点的消费方。
Zookeeper中的服务节点路径如 Group/ServiceInterface/category/URL ：
服务下线就是把注册的节点进行删除。
订阅有两种方式pull、push ，pull是客户端定时轮询注册中心拉取配置，push是注册中心主动推送数据给客户端。dubbo是两者结合的方式进行配置的拉取，当第一次启动的时候通过客户端pull拉取 所有数据 方式，在订阅的节点上进行注册watcher，然后客户端与注册中心保持长连接，而后 每个节点有任何数据变化，注册中心就会更新watcher情况进行回调通知到客户端，客户端就接收到这个通知了。
服务在进行注册的时候，服务端会订阅configurators用来监听动态配置的变更。
在消费者启动的时候，消费者会监听providers、routers、configurators来监听服务提供者、路由规则、配置变更的通知。
取消订阅就是删除监听器。
当与zookeeper重新连接时，需要刷新本机生产者列表，这个方法就是干这个的，它把的已订阅的列表都加入订阅失败的容器。
注意 ：
addFailedSubscribed 方法是 FailbackRegistry 将订阅失败的连接放入失败容器， FailbackRegistry 有定时器会定时的处理这些失败的订阅。
通知事件是调用的 AbstractRegistry#notify 方法完成。
流程说明 ：
RegistryDirectory#notify 就是更新本地缓存。
注意 ：
file在 AbstractRegistry 对象创建的时候初始化。
这使用了文件锁的方式保证只有一个在读写文件。
消费者从注册中心获取注册信息后会做本地缓存。内存中也有一份，保存在 Properties 对象里，磁盘上也持久化一份，通过file对象进行引用。

分布式服务Dubbo+Zookeeper安全认证：KeeperErrorCode = NoAuth

我们Zookeeper正常的情况下是部署在内网进行服务注册和服务发现，难免有一些特许的情况需要部署到外网。而部署到外网的中我们需要对于服务注册和服务发现进行安全认证。至于怎样进行安全配置就不详细的描述，可以参考这篇文章（ https://www.cnblogs.com/smallSevens/p/8064995.html ）
在Dubbo registry上配置相应的用户、密码，服务就注册不到Zookeeper上了，会报KeeperErrorCode = NoAuth错误。

总结：通过源码的分析发现使用ZkclientZookeeperClient进行连接zookeeper和注册服务是不会设置安全配置。

将dubbo.registry.client由zkclient改为curator即可。dubbo.registry.client = curator

Dubbo服务注册到Zookeeper上的IP与本机IP不一致

1、问题描述

如图，本地在内网的ip为172.27.43.8，但是服务注册到了zk上后，ip变成了本地的ip:192.168.68.2

2、原因解析
发布服务到远程zk，dubbo是调用ServiceConfig.doExportUrlsFor1Protocol方法，
在doExportUrlsFor1Protocol方法中，通过以下两步获取到host和port两个值。

服务注册到zk上所用的ip，正是这个host，这个findConfigedHosts方法，入参就包括protocolConfig。
因此我们猜想，修改protocolConfig中的host配置，是不是就可以改变服务注册到zk上所显示的ip？

3、解决方法
在dubbo的xml配置文件中，配置protocol属性如下：

将host改为本地的ip后，重新尝试将服务注册到zk，发现zk上的ip已经变为我们所配置的host，问题解决~

如何查看Zookeeper下Dubbo的Provider与Consumer信息

查看Zookeeper下Dubbo的服务提供者与服务消费者信息：有些场景下我们需要查看ZK下dubbo的注册和消费信息，但是在没有安装dubbo admin等可视化管理插件时我们需要通过命令的方式查看。（如：收到provider不存在之类的报错信息）

引用： http://www.wangqi94.com

zookeeper在Dubbo中扮演了一个什么角色，起到了什么作用啊？

Zookeeper是゛dubbo゛推荐的注册中心，是管理员！
就像一个分布式的项目，web层与 service层被拆分了开来， 部署在不同的tomcat中， 我在web层 需要调用 service层的接口，但是两个运行在不同tomcat下的服务无法直接互调接口，那么就可以通过zookeeper和dubbo实现。
我们通过dubbo 建立ItemService这个服务，并且到zookeeper上面注册，填写对应的zookeeper服务所在 的IP及端口号。【按照我上面的比喻就是，学生注册入学（接口是学号，学生本人是impl实现），填写学校教务网网址（就是zookeeper）】
dubbo的服务提供者会在zookeeper上面创建一个临时节点，表明自己的ip和端口，当消费者需要使用服务时，会先在zookeeper上面查询，找到服务提供者，做一些负载的选择（比如随机、轮流），然后按照这些信息，访问服务提供者。
Zookeeper一个分布式的服务框架，是树型的目录服务的数据存储，能做到集群管理数据 ，这里能很好的作为Dubbo服务的注册中心，Dubbo能与Zookeeper做到集群部署，当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求。

dubbo，zookeeper只有一个注册中心，如果服务器挂了，还能正常访问吗？为什么

不能正常访问，zookeeper为dubbo提供服务注册和发现的功能，挂了一下，无法进行RPC。
zookeeper需要采用分布式集群的方式来保证高可用性。
追加回答：因为初期会从zookeeper获取节点到本地，如果没有发生变化的话是可以的

dubbo使用zookeeper连接，zookeeper宕机后怎么处理

1，配置文件同步2，主从切换3，分布式队列4，分布式锁5，其他在以前的文章里面有写过使用zookeeper原生的api，监听zk节点变化，那么本篇我们就来看下，如何使用curator来完成监听，代码如下：packagecom.qin.curator.zk;importjavax.sound.midi.Patch;importorg.apache.curator.RetryPolicy;importorg.apache.curator.framework.CuratorFramework;importorg.apache.curator.framework.CuratorFrameworkFactory;importorg.apache.curator.framework.CuratorFrameworkFactory.Builder;importorg.apache.curator.framework.api.CuratorWatcher;importorg.apache.curator.framework.recipes.cache.NodeCache;importorg.apache.curator.framework.recipes.cache.NodeCacheListener;importorg.apache.curator.framework.recipes.cache.PathChildrenCache;importorg.apache.curator.framework.recipes.cache.PathChildrenCacheEvent;importorg.apache.curator.framework.recipes.cache.PathChildrenCacheListener;importorg.apache.curator.retry.ExponentialBackoffRetry;importorg.apache.curator.utils.ZKPaths;importorg.apache.zookeeper.WatchedEvent;/****使用curator监听zookeeper节点*@authorqindongliang***/publicclassCuratorWatch{staticCuratorFrameworkzkclient=null;staticStringnameSpace="php";static{Stringzkhost="192.168.46.22:2181";//zk的hostRetryPolicyrp=newExponentialBackoffRetry(1000,3);//重试机制Builderbuilder=CuratorFrameworkFactory.builder().connectString(zkhost).connectionTimeoutMs(5000).sessionTimeoutMs(5000).retryPolicy(rp);builder.namespace(nameSpace);CuratorFrameworkzclient=builder.build();zkclient=zclient;zkclient.start();//放在这前面执行zkclient.newNamespaceAwareEnsurePath(nameSpace);}publicstaticvoidmain(String[]args)throwsException{watch();Thread.sleep(Long.MAX_VALUE);}/****监听节点变化***/publicstaticvoidwatch()throwsException{PathChildrenCachecache=newPathChildrenCache(zkclient,"/zk",false);cache.start();System.out.println("监听开始/zk..");PathChildrenCacheListenerplis=newPathChildrenCacheListener(){@OverridepublicvoidchildEvent(CuratorFrameworkclient,PathChildrenCacheEventevent)throwsException{switch(event.getType()){caseCHILD_ADDED:{System.out.println("Nodeadded:"+ZKPaths.getNodeFromPath(event.getData().getPath()));break;}caseCHILD_UPDATED:{System.out.println("Nodechanged:"+ZKPaths.getNodeFromPath(event.getData().getPath()));break;}caseCHILD_REMOVED:{System.out.println("Noderemoved:"+ZKPaths.getNodeFromPath(event.getData().getPath()));break;}}}};//注册监听cache.getListenable().addListener(plis);}}运行后的控制台打印：18:33:07.722[main]INFOo.a.c.f.imps.CuratorFrameworkImpl-Starting18:33:07.727[main]DEBUGo.a.curator.CuratorZookeeperClient-Starting18:33:07.727[main]DEBUGorg.apache.curator.ConnectionState-Starting18:33:07.727[main]DEBUGorg.apache.curator.ConnectionState-reset18:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:zookeeper.version=3.4.6-1569965,builton02/20/201409:09GMT18:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:host.name=QINDONGLIANG.dhgatecn.msf18:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:java.version=1.7.0_0418:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:java.vendor=OracleCorporation18:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:java.home=D:\Java\jdk1.7.0_04\jre18:33:07.734[main]INFOorg.apache.zookeeper.ZooKeeper-Clientenvironment:java.class.path=D:\eclipseworkspace2yw\opzk\bin;D:\eclipseworkspace2yw\opzk\lib\curator-client-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-examples-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-framework-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-recipes-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-test-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-x-discovery-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-x-discovery-server-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\curator-x-rpc-2.6.0.jar;D:\eclipseworkspace2yw\opzk\lib\log4j-1.2.15.jar;D:\eclipseworkspace2yw\opzk\lib\zookeeper-3.4.5.jar;D:\eclipseworkspace2yw\opzk\lib\commons-io-2.1.jar
1、配置文件同步
2、主从切换
3、分布式队列
4、分布式锁
Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。
通过监控这些数据状态的变化，从而可以达到基于数据的集群管理，后面将会详细介绍 Zookeeper 能够解决的一些典型问题，这里先介绍一下，Zookeeper 的操作接口和简单使用示例。
常用接口列表
客户端要连接 Zookeeper 服务器可以通过创建 org.apache.zookeeper. ZooKeeper 的一个实例对象，然后调用这个类提供的接口来和服务器交互。前面说了 ZooKeeper 主要是用来维护和监控一个目录节点树中存储的数据的状态，所有我们能够操作 ZooKeeper 的也和操作目录节点树大体一样，如创建一个目录节点，给某个目录节点设置数据，获取某个目录节点的所有子目录节点，给某个目录节点设置权限和监控这个目录节点的状态变化。
zookeeper宕机后，因为消费者会缓存提供者的信息，所以应用不会有问题。但是，此时提供者和消费者都无法重连zookeeper，因为dubbo貌似配置的zkclient不会重连zookeeper，所以一旦重启一台服务提供者，那么这台就从服务消费者的缓存中消失了，此时服务消费者又连不上zookeeper，所以如果同时重启，消费者就没有提供者可用了，所以只能重启一台提供者后，再重启一个消费者，交错重启。