zk客户端命令查看dubbo服务的生产者和消费者

 假设zookeeper安装在17216222这台服务器上,现在我们通过命令行查看dubbo在zookeeper注册服务的生产者和消费者信息

首先通过命令切换到/zookeeper-3411/bin目录,然后输入

(2182为zookeeper在服务器上提供服务的端口)会看到如下截图:

然后在命令行再输入:

查看目录信息,就能看到注册的dubbo服务,截图如下:

在命令行依次输入:

会看到dubbo服务提供的对外接口,截图如下:

查看消费者命令:

会看到消费者的信息,截图如下:

查看生产者命令:

会看到生产者的信息，截图如下：

如果不用zk，你去调用rpc的时候你就得知道对方的地址，这样如果以后对方部署的服务器变了，你那边也得跟着改，就耦合了，如果加入zk，对方把服务注册到zk上，你只要通过zk获取就行了，别人变了ip也不会影响你。zk在dubbo中就是用来进行服务注册的，dubbo也支持用redis进行服务注册

Dubbo建议使用Zookeeper作为服务注册中心。

dubbo和zookeeper的关系1

dubbo和zookeeper的关系2

dubbo原理和机制：应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料

在大规模dubbo服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。

(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。

此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。

(2)当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。

这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。

(3)接着，服务的调用量越来越大，服务的容量问题就暴露出来。

为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。

其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案： 服务消费端: DUBBO在消费端提供了一个url的属性来指定某个服务端的地址 <!--lang:xml--> <dubbo:reference interface="comalibabadubbodemoHelloWorldService" check="false" id="helloWorldService"/> 默认的方式是从注册中心发现接口为comalibabadubbodemoHelloWorldService的服务，但是如果需要直连，可以在dubboproperties下面配置dubboreferencehelloWorldServiceurl=dubbo://ip:port/comalibabadubbodemoHelloWorldService可以通过配置dubboreferenceurl=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）

没有重叠，只是两者侧重点不一样。Nacos主要功能集中在动态服务发现、服务配置、服务元数据及流量管理。你可以把他简单的理解为是一个注册中心和配置中心，而Dubbo是一款高性能、轻量级的开源Java服务框架，主要功能点在于RPC框架。

Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力，面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

dubbo自带的运维工具dubbo-admin，主要面向开发人员去管理服务，携带很多管理、控制等功能，然后在dubbo新版本又推出了qos（Quality of Service），主要面向运维管理。我在之前公司有用到次功能，在和k8s结合时，通过>