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客户端版本。
org.apache.dubbo
dubbo-dependencies-zookeeper-curator5
${dubbo.version}
pom
zookeeper
org.apache.zookeeper
org.apache.zookeeper
zookeeper
3.8.1
2：实际开发
接下来我们就需要进行相应的开发了。接下来的开发反而比较简单了，首先我们的依赖已经引入进来了。我们只需要在provider和consumer当中进行一个配置即可，其中一个非常指的注意的是，不论我们选择使用什么注册中心或者Zookeeper或者Nacos也好，只要在Dubbo的体系下使用注册中心，那么这个配置必须在我们的Provider和Consumer下面都进行注册！
如果我们还引入了DubboAdmin的话，我们也得在DubboAdmin当中对注册中心进行相应的配置。并且呢Provider对注册中心的配置和Consumer对注册中心的配置以及DubboAdmin对注册中心的配置要保持一致！所以，我们的配置流程就是在Consumer和Provider的配置文件中去配置一个dubbo.registry.address即可：
dubbo:
registry:
address:zookeeper://127.0.0.1:2181注册中心的地址里面如果我们选择的是Zookeeper作为注册中心，那么需要使用Zookeeper协议。Zookeeper://这样就代表了Zookeeper的协议，如果后续我们选择Nacos的话，只需要使用：
dubbo:
registry:
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
spring:
application:
name: DUBBO-02-REGISTER-PROVIDER
dubbo:
application:
qos-enable: false
register-mode: interface
protocol:
name: dubbo
port: -1
registry:
address: zookeeper://127.0.0.1:2181(二)：Consumer
spring:
application:
name: DUBBO-03-REGISTER-CONSUMER
dubbo:
application:
qos-enable: false
registry:
address: zookeeper://127.0.0.1:21813：启动服务结果展示
首先我们直接启动提供者，然后在启动我们的消费者。
消费者：
@SpringBootTest
public class TestDubbo {
@DubboReference
private UserService userService;
@Test
void test1() throws IOException {
String xiaohei = userService.login("xiaohei", "11111");
System.out.println("xiaohei = " + xiaohei);
System.in.read();
}
}启动之后，服务向我们的注册中心发起注册，PrettyZoo界面发生变化：
消费者是基于测试启动的一个服务，然后UserService代理对象已经基于DubboReference注解注入了进来，我们加入一个阻塞方便查看结果，首先是我们的消费端的结果展示：
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
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
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
xiaohei = this is login提供者基于SpringBoot入口类进行服务启动，服务启动完毕之后等待消费者的调用，接下来是我们消费者的调用结果：
2023-11-23 22:48:38.704 INFO 612 --- [pool-1-thread-1] .b.c.e.AwaitingNonWebApplicationListener : [Dubbo] Current Spring Boot Application is await...
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
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
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的这个功能的。
