Dubbo 2.7 版本增加新特性，新系統開始使用 Dubbo 2.7.1 嘗鮮新功能。使用過程中不慎踩到這個版本的 Bug。 系統架構 Spring Boot 2.14 Release + Dubbo 2.7.1 現象 Dubbo 服務者啟動成功，正常提供服務，消費者調用偶現失敗的情況。錯誤如下圖 ...
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 發佈以後，再使用。
