Dubbo3利用Zookeeper作为注册中央的方案讨论！详解DubboAdmin与PrettyZoo来监控服务的优劣！

文章目次
一：Dubbo注册中央的根本利用
二：Zookeeper注册中央的利用
1：依赖引入
2：现实开辟
三：Zookeeper作为注册中央的利用展示
1：启动注册Zookeeper服务
2：引入注册中央
(一)：Provider
(二)：Consumer
3：启动服务效果展示
4：监控服务的两种本事

---

一：Dubbo注册中央的根本利用

        我们利用的和分析解说的Dubbo版本是Dubbo3，作为Dubbo来讲Dubbo支持的注册中央有很多Zookeeper、Nacos、Consule等等。这是三种比力常见的注册中央固然我指的是在Dubbo当中，别的不太常见的另有Etced如许的注册中央。我们在举行Dubbo注册中央解说的时间，会把这个三个偏重挑选出来作为重点解说对象，这个缘故原由黑白常简单的。
        起首我们在前面的Rpc专栏的时间，Zookeeper我们已经分析过了，而别的的Nacos在微服务当中有着举足轻重的职位！他也是阿里的DNS这种办理方案当中N的这个元素，他在阿里的体系技能中有着很高的作用。对于Consul来讲，在云原生情况下这个Consul黑白常实用于云原生情况的技能栈，以是顺应新的潮水我们不得不对Consul举行分析息争说。Etced相对来讲利用要少一点，我们临时不对他举行相应的解说。
二：Zookeeper注册中央的利用

        应用Zookeeper作为注册中央，起首我们要对引入对应的依赖。这个依赖现实上包罗的是两个部分的内容。第一个依赖是Zookeeper的Java客户端，客户端是Java应用与Zookeeper举行通讯交互的根本，我们当前利用的是3.8.1这个版本，第二个依赖是对Zookeeper的Java客户端的高级封装curator，在这里我们选择的是curator5这个版本。现实上作为Zookeeper客户端和curator版本的利用，Dubbo已经在他的官网上给我们摆列出来了：

Zookeeper Server版本	Dubbo版本	Dubbo Zookeeper依赖包	阐明
3.4.x及以下	3.0.x及以上	dubbo-dependencies-zookeeper	转达依赖Curator4.x、Zookeeper 3.4.x
3.5.x及以上	3.0.x及以上	dubbo-dependencies-zookeeper-curator5	转达依赖Curator5.x、Zookeeper 3.7.x
3.4.x及以上	2.7.x及以下	dubbo-dependencies-zookeeper	转达依赖Curator4.x、Zookeeper 3.4.x
3.5.x及以上	2.7.x及以下	无	须要手动添加Curator、Zookeeper等相干客户端依赖

        这里边涉及到的版本有Dubbo的版本和Zookeeper的版本和他们对应的依赖包的阐明，当前咱们的Dubbo选择的是3.2.0且Zookeeper的版本选择是的3.6这个版本，按照这个关系我们应该从第二行的表格中的设置方式去挑选。 以是应该选择dubbo-dependencies-zookeeper-curator5这个依赖包。
1：依赖引入

        基于上边的依赖关系，我们挑选如下的版原来设置我们的Zookeeper客户端版本。

1.   <dependency>
2.     <groupId>org.apache.dubbo</groupId>
3.   <artifactId>dubbo-dependencies-zookeeper-curator5</artifactId>
4.     <version>${dubbo.version}</version>
5.     <type>pom</type>
6.     <exclusions>
7.       <exclusion>
8.         <artifactId>zookeeper</artifactId>
9.         <groupId>org.apache.zookeeper</groupId>
10.       </exclusion>
11.     </exclusions>
12.   </dependency>
14.   <dependency>
15.     <groupId>org.apache.zookeeper</groupId>
16.     <artifactId>zookeeper</artifactId>
17.     <version>3.8.1</version>
18.   </dependency>

复制代码

2：现实开辟

        接下来我们就须要举行相应的开辟了。接下来的开辟反而比力简单了，起首我们的依赖已经引入进来了。我们只须要在provider和consumer当中举行一个设置即可，此中一个非常指的留意的是，岂论我们选择利用什么注册中央大概Zookeeper大概Nacos也好，只要在Dubbo的体系下利用注册中央，那么这个设置必须在我们的Provider和Consumer下面都举行注册！
        假如我们还引入了DubboAdmin的话，我们也得在DubboAdmin当中对注册中央举行相应的设置。而且呢Provider对注册中央的设置和Consumer对注册中央的设置以及DubboAdmin对注册中央的设置要保持划一！以是，我们的设置流程就是在Consumer和Provider的设置文件中去设置一个dubbo.registry.address即可：

1. dubbo:
2.     registry:
3.         address:zookeeper://127.0.0.1:2181

复制代码

        注册中央的地点内里假如我们选择的是Zookeeper作为注册中央，那么须要利用Zookeeper协议。Zookeeper://如许就代表了Zookeeper的协议，假如后续我们选择Nacos的话，只须要利用：

1. dubbo:
2.     registry:
3.         address:nacos://127.0.0.1:2181

复制代码

        值得留意的是，协议后边的ip地点就是我们的注册中央折务对应的主机ip地点。我们当前是本地安装那么就是127.0.0.1。当前的端口是注册中央的监听端口，Zookeeper的默认端口是2181，Nacos的默认端口是8848，Consul的默认端口是8500 ，通过如许的一种方式，我们就在我们的整个服务中引入了Zookeeper作为我们的注册中央了。
三：Zookeeper作为注册中央的利用展示

1：启动注册Zookeeper服务

启动下令：bin/zkServer.cmd
启动效果：

利用我们的PrettyZoo可视化工具可以看到Zookeeper的服务内容。 当前我们可以清晰的看到在我们的根节点下只有我们一个zookeeper的节点，这黑白常正常和干净的。接下来我们启动我们的服务来举行测试。

             
2：引入注册中央

(一)：Provider

1. spring:
2.   application:
3.     name: DUBBO-02-REGISTER-PROVIDER
5. dubbo:
6.   application:
7.     qos-enable: false
8.     register-mode: interface
9.   protocol:
10.     name: dubbo
11.     port: -1
12.   registry:
13.     address: zookeeper://127.0.0.1:2181

复制代码

(二)：Consumer

1. spring:
2.   application:
3.     name: DUBBO-03-REGISTER-CONSUMER
5. dubbo:
6.   application:
7.     qos-enable: false
8.   registry:
9.     address: zookeeper://127.0.0.1:2181

复制代码

3：启动服务效果展示

        起首我们直接启动提供者，然后在启动我们的消耗者。
消耗者：

1. @SpringBootTest
2. public class TestDubbo {
3.     @DubboReference
4.     private UserService userService;
6.     @Test
7.     void test1() throws IOException {
8.         String xiaohei = userService.login("xiaohei", "11111");
9.         System.out.println("xiaohei = " + xiaohei);
10.         System.in.read();
11.     }
12. }

复制代码

        启动之后，服务向我们的注册中央发起注册，PrettyZoo界面发生厘革：

        消耗者是基于测试启动的一个服务，然后UserService署理对象已经基于DubboReference注解注入了进来，我们参加一个壅闭方便检察效果，起首是我们的消耗端的效果展示：

1. 2023-11-23 22:51:04.008  INFO 4272 --- [           main] o.a.d.r.c.m.MigrationRuleHandler         :  [DUBBO] Succeed Migrated to APPLICATION_FIRST mode. Service Name: com.suns.service.UserService, dubbo version: 3.2.0, current host: 192.168.8.1
2. 2023-11-23 22:51:04.008  INFO 4272 --- [           main] org.apache.dubbo.config.ReferenceConfig  :  [DUBBO] Referred dubbo service: [com.suns.service.UserService]. it's not GenericService reference, dubbo version: 3.2.0, current host: 192.168.8.1
3. 2023-11-23 22:51:04.011  INFO 4272 --- [Report-thread-1] o.a.d.m.s.z.ZookeeperMetadataReport      :  [DUBBO] store consumer metadata. Identifier : org.apache.dubbo.metadata.report.identifier.MetadataIdentifier@440c2c9d; definition: org.apache.dubbo.common.url.component.URLParam$URLParamMap@58ea4a38, dubbo version: 3.2.0, current host: 192.168.8.1
4. xiaohei = this is login

复制代码

        提供者基于SpringBoot入口类举行服务启动，服务启动完毕之后等候消耗者的调用，接下来是我们消耗者的调用效果：

1. 2023-11-23 22:48:38.704  INFO 612 --- [pool-1-thread-1] .b.c.e.AwaitingNonWebApplicationListener :  [Dubbo] Current Spring Boot Application is await...
2. 2023-11-23 22:51:03.960  INFO 612 --- [erverWorker-3-1] o.a.d.r.t.netty4.NettyServerHandler      :  [DUBBO] The connection of /192.168.8.1:55886 -> /192.168.8.1:20880 is established., dubbo version: 3.2.0, current host: 192.168.8.1
3. 2023-11-23 22:51:04.123  INFO 612 --- [erverWorker-3-1] o.a.dubbo.rpc.protocol.dubbo.DubboCodec  :  [DUBBO] Because thread pool isolation is enabled on the dubbo protocol, the body can only be decoded on the io thread, and the parameter[decode.in.io.thread] will be ignored, dubbo version: 3.2.0, current host: 192.168.8.1
4. UserServiceImpl.login name is xiaohei password is 11111

复制代码

        从效果上来看，我们从消耗端收支的参数在服务提供端控制台精确的被打印了出来，阐明我们的消耗者和提供者之间的Rpc调用乐成举行，也证明白基于此次Zookeeper作为我们的注册中央完成消耗者和提供者之间的通讯是乐成的！
4：监控服务的两种本事

        固然我们刚才监控注册中央的方式是基于PrettyZoo的情势来检测我们的注册中央，那么另有没有其他的方式来监控我们的注册中央中的内容呢？当时是有的，这个本事就是基于DubboAdmin当我们启动完毕DubboAdmin之后，大概会碰到如许的一个标题导致启动失败。这个非常就是端口地点绑定失败，这个是由于我们的DubboAdmin启动的时间会模拟一个Dubbo服务出来往我们的注册中央发起注册，现在报错是由于我们的我们刚才启动的提供者的服务已经把我们的本地20880端口给占用了，这个时间DubboAdmin在基于这个端口启动就启动不起来了，我们须要先启动我们的DubboAdmin，然后在启动我们的Provider和Consumer即可，由于按照原理来讲也应该先启动我们的监控平台，在启动我们的Dubbo服务。
        欣赏器中输入Localhost:9000就可以检察我们的DubboAdmin监控平台。上来之后，我们可发发现DubboAdmin中只有我们的MockService。这个时间重新启动我们的提供者和消耗者即可。这个时间，我们可以在DubboAdmin中看到我们的Dubbo服务了。
        这件事变告诉我们怎样监控我们的服务，第一种方式就是基于我们的注册中央，假如是Zookeeper作为注册中央的话，我们可以利用PrettyZoo作为可视化工具举行检测即可。第二种方式就是利用DubboAdmin也可以完成对Dubbo服务的监控！
        后续，我们剧烈发起利用DubboAdmin来监控我们的服务，起首就是DubboAdmin不光仅可以可以监测到详细的服务，别的还可以对服务举行测试、服务的统计等等功能。以是后续我们的Pretty可以少用，只管多用我们的DubboAdmin。
        为什么我们切换启动序次之后，后续的Provider的端口就不再是20880了呢？当前我们的提供者基于Dubbo协议，他的端标语我们设置的是-1，这个负一的特点就是假如服务启动的时间假如默认端标语20880被占用的话，就会在原有的根本上举行+1，如许我们的DubboAdmin中的MockService和提供者服务就都能正常启动了。值得留意的是DubboAdmin启动的时间，是没有端标语+1的这个功能的。