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客戶端版本。

  <dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-dependencies-zookeeper-curator5</artifactId><version>${dubbo.version}</version><type>pom</type><exclusions><exclusion><artifactId>zookeeper</artifactId><groupId>org.apache.zookeeper</groupId></exclusion></exclusions></dependency><dependency><groupId>org.apache.zookeeper</groupId><artifactId>zookeeper</artifactId><version>3.8.1</version></dependency>

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-PROVIDERdubbo:application:qos-enable: falseregister-mode: interfaceprotocol:name: dubboport: -1registry:address: zookeeper://127.0.0.1:2181

(二)：Consumer

spring:application:name: DUBBO-03-REGISTER-CONSUMERdubbo:application:qos-enable: falseregistry:address: zookeeper://127.0.0.1:2181

3：啟動服務結果展示

? ? ? ? 首先我們直接啟動提供者，然后在啟動我們的消費者。

消費者：

@SpringBootTest
public class TestDubbo {@DubboReferenceprivate UserService userService;@Testvoid 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的這個功能的。