Dubbo 2.7.1 踩坑的我,你踩過嗎?

Dubbo 2.7 版本增加新特性,新系統開始使用 Dubbo 2.7.1 嚐鮮新功能。使用過程中不慎踩到這個版本的 Bug。

系統架構

Spring Boot 2.14-Release + Dubbo 2.7.1

現象

Dubbo 服務者啓動成功,正常提供服務,消費者調用偶現失敗的情況。錯誤如下圖:
在這裏插入圖片描述

可以看出,主要原因爲 cause: message can not send, because channel is closed。 但是檢查提供者,卻發現服務進程正常。

登陸 Dubbo admin 查看提供者服務,發現這個服務存在兩個節點。
在這裏插入圖片描述

192.168.164.77 爲測試服務器的 ip,提供者位於這臺機器,而另一個 10.20.80.67 卻是本地電腦的 IP,但是此時本地並未運行這個服務。

再次查看服務報錯的原因,可以看到提供者調用l本地提供 RPC 的服務。由於本地服務已停止,導致調用失敗。

這個問題在之前版本從未碰到,剛開始隱約記得 Dubbo 服務提供者註冊使用 ZooKeeper 臨時節點,服務斷開,會刪除該節點。

問題原因

在 Dubbo 主頁搜索相關 issue,看到同樣的問題 Dubbo-2.7.1 providers 重複註冊.

查看相關回復,可以看到問題主要由於 dynamic 默認值變成 false ,而 2.7.1 之前版本默認不賦值,初始值爲 null。
在這裏插入圖片描述

後續 PR 中已修復該問題 Fix issue 3785,修復代碼將 dynamic 默認設置成 true。但是截止 20190515 該版本暫未發佈。

源碼分析

知道問題原因,這裏我們從源碼分析一下,爲什麼 dynamic 設置成 false 會導致該問題。

注:下面分析的是 Dubbo 2.7.1 的源碼

下面我們使用 Dubbo xml 配置相關。

在 xml 配置中,可以在以下兩個地方設置 dynamic 屬性。
在這裏插入圖片描述

服務啓動時將會使用 DubboNamespaceHandler 解析,注入 Spring 容器。
在這裏插入圖片描述

其中會將 provider 標籤解析成 ProviderConfig 對象,service 標籤解析成 ServiceBean 對象。

在這裏插入圖片描述查看繼承關係,可以看到以上兩個類都繼承 AbstractServiceConfig , dynamic 位於這個父對象中。
在這裏插入圖片描述

可以看到該字段默認值爲 false。

接着查看 Dubbo 服務導出過程,位於 ServiceBean#export,略過其他代碼,我們直接跳到關鍵 ServiceConfig#doExportUrlsFor1Protocol 。
在這裏插入圖片描述

可以看到這裏調用了多次 appendParameters 方法。 這個方法將利用反射,獲取對象的中所有字段信息,然後添加到 map 中。其中字段名字爲鍵值,字段實際值爲內容。此時 map 鍵值內容爲:
在這裏插入圖片描述

可以看到 map 中還有一個 default.dynamic,大家翻看代碼自己思考一下,爲什麼會出現這個?

接着我們跳到後面:
在這裏插入圖片描述

在這裏會將上面得到 map 組裝到 URL 對象中,然後再註冊到註冊中心。。

由於註冊中心使用的是 ZooKeeper,所以這裏將會使用 ZookeeperRegistry 實現類。
在這裏插入圖片描述

首先查看 url##getParameter 方法,這裏 Constants.DYNAMIC_KEY 值爲 dynamic。
在這裏插入圖片描述

該方法會先從 parameters 中根據鍵值取值。若不存在,會再根據 default 作爲前綴拼接再次取值。若還不存在則使用傳入的默認值。

查看此時的 parameters 對象。
在這裏插入圖片描述

url.getParameter(Constants.DYNAMIC_KEY, true) 返回爲 false。

然後分析 zkClient#create 方法,
在這裏插入圖片描述

由於 ephemeral 爲 false,所以這個服務註冊到 ZooKeeper 的節點爲持久節點。

臨時節點,客戶端斷開,會話超時後,ZooKeeper 將會自動刪除這個節點。zookeeper-faq

面試題:服務提供者能實現失效踢出是什麼原理(高頻題)

服務宕機的時候,該節點由於是持久節點會永遠存在,而且當服務再次重啓的時候會將重新註冊一個新節點。這樣就導致 ZooKeeper 中存在額外失效的節點,且該節點還無法自然消除(除非手動調用 ZooKeeper 刪除節點方法)。

總結

由於 Dubbo 2.7.2 暫未發佈,所以建議若想使用 Dubbo 2.7 新功能的同學,使用 2.7.0 版本。若現在正在使用 2.7.2 版本,也不要慌張。只要服務不是異常宕機或者使用 kill -9 強制殺死進程,以上的現象將不會碰到。正常服務關閉的時候,Dubbo 服務會主動去 ZooKeeper 註銷該服務,並刪除這個節點。

還未使用該版本的同學們,建議使用 2.7.0 或者等 2.7.2 發佈以後,再使用。

寫在最後:

碼字不易看到最後了,那就點個關注唄,只收藏不點關注的都是在耍流氓!

關注並私信我“架構”,免費送一些Java架構資料,先到先得!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章