java調試技能之dubbo調試—telnet

dubbo作為一個遠程調用框架，雖與同類型的框架，不知道誰優誰劣，但是就公司層面使用來說，還是很棒的。這裡簡單的寫一下怎麼使用和調試技巧，就算是作個使用總結吧，供快速使用和問題解決！

dubbo是基於spring做配置使用的，雖也提供其他方法，但是比較麻煩，所以使用spring還是有好處的吧。

先來一個整體架構圖，這對於了解其是如何工作的是很有必要的。（比如我當初就誤以為dubbo會做一個服務轉發，好尷尬）

下面是一個更完整架構圖，可以更清晰的看到軟體是如何工作的：

（以下是官方說明，我覺得很有必要了解下，so）節點角色說明：

Provider: 暴露服務的服務提供方。

Consumer: 調用遠程服務的服務消費方。

Registry: 服務註冊與發現的註冊中心。

Monitor: 統計服務的調用次調和調用時間的監控中心。

Container: 服務運行容器。

調用關係說明：

0. 服務容器負責啟動，載入，運行服務提供者。

1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。

2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。

3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。

4. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。

5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

(1) 連通性：

註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心交互，註冊中心不轉發請求，壓力較小

監控中心負責統計各服務調用次數，調用時間等，統計先在內存匯總後每分鐘一次發送到監控中心伺服器，並以報表展示

服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網路開銷

服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網路開銷

註冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外

註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者

註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者

(2) 健狀性：

監控中心宕掉不影響使用，只是丟失部分採樣數據

資料庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務

註冊中心對等集群，任意一台宕掉後，將自動切換到另一台

註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊

服務提供者無狀態，任意一台宕掉後，不影響使用

服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

(3) 伸縮性：

註冊中心為對等集群，可動態增加機器部署實例，所有客戶端將自動發現新的註冊中心

服務提供者無狀態，可動態增加機器部署實例，註冊中心將推送新的服務提供者信息給消費者

(4) 升級性：

當服務集群規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分布式服務架構不會帶來阻力：

以上，官方文檔很全面的哦，有時間請查看 官網 說明。

使用配置如下（分提供者和消費者配置，這很容易理解）：

- 提供者配置 dubbo-provider.xml

- 消費者配置 dubbo-consumer.xml

以上，兩個配置好後，就可以啟動dubbo, 服務端， 然後通過consumer進行測試了。

但是，現在講究的都是微服務化，那麼就可能是，提供者是一波人，消費者是另一波人，這是正常情況，那麼如果要測試提供者怎麼辦呢？

方法有二：

自己寫簡單消費者功能，進行各種情況測試。（這確實是有必要的）

使用telnet直接連接上dubbo，使用命令調用，然後調試。（這是本文的初衷）

下面，就說說怎麼樣連接dubbo吧：

1. 查看提供者暴露的埠（這很重要，我曾經為找這個埠繞了不少彎路），我主要是通過dubbo的管理後台進行查看的，截圖如下：

通過這個顯示，我們知道，提供者的ip是172.17.0.13，埠是{}

2. 使用telnet登錄dubbo,進行調用

4. 調用方法，invoke com.cxxx

以上，就這樣就可以快速調試你的方法了。對於你調用服務端有用，對於消費者也有用的，特別是有時懷疑對方寫錯了的時候。

怎樣確認dubbo介面出問題了？

dubbo有一個管理後台，可以觀察哪些服務是否已經掛掉了

有時修改在提供者頁面會看到警告，大部分情況是可以不用管的，但是有時是因為zookeeper掛掉了，可能需要重啟。

壓力測試？

對於dubbo介面的壓力測試，目前我們是通過編寫http介面來調用進行測試的。

dubbo只是一個調用框架，做的事情其實也不是特別多，但是項目裡面還是需要有這麼一種管理工具的，比較使用原生的rpc調用，排查問題比較難，和安全性比起來，效率都是次要的。

dubbo是為java而生的，hprose用於寫php遠程調用，據說比較好哦。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！