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
<bean id="xxxService" class="com.xxx.XxxServiceImpl" /> <!-- 聲明bean id, 以便和消費者的id相匹配 --> <dubbo:service interface="com.xxx.XxxService" ref="xxxService" /> <!-- 使用dubbo:service方法，增加暴露遠程服務配置 -->
- 消費者配置 dubbo-consumer.xml
<dubbo:reference id=“xxxService” interface=“com.xxx.XxxService” /> <!-- 使用dubbo:reference，引用遠程服務實現配置，使用 @Resource等方法注入引用 -->
以上，兩個配置好后，就可以啟動dubbo, 服務端， 然后通過consumer進行測試了。
但是，現在講究的都是微服務化，那么就可能是，提供者是一波人，消費者是另一波人，這是正常情況，那么如果要測試提供者怎么辦呢？
方法有二：
1. 自己寫簡單消費者功能，進行各種情況測試。（這確實是有必要的）
2. 使用telnet直接連接上dubbo，使用命令調用，然后調試。（這是本文的初衷）
下面，就說說怎么樣連接dubbo吧：
1. 查看提供者暴露的端口（這很重要，我曾經為找這個端口繞了不少彎路），我主要是通過dubbo的管理后台進行查看的，截圖如下：
通過這個顯示，我們知道，提供者的ip是172.17.0.13，端口是60003
2. 使用telnet登錄dubbo,進行調用
$-#: telnet 172.17.0.13 60003
3. 查看提供者都提供了什么服務，ls命令，ls com.cxxx.xxxx
dubbo>ls com.test.DemoService dubbo>ls com.test.DemoService queryDemoPageList insertDemolist
4. 調用方法，invoke com.cxxx
dubbo> invoke com.test.DemoService.queryDemoPageList({"id":"100"}, 1, 2)
{"totalCount":1,"data":[{date":"2017-03-23 14:10:32","name":"張三","keyword":"222"}]}
elapsed: 11 ms.
以上，就這樣就可以快速調試你的方法了。對於你調用服務端有用，對於消費者也有用的，特別是有時懷疑對方寫錯了的時候。
怎樣確認dubbo接口出問題了？
dubbo有一個管理后台，可以觀察哪些服務是否已經掛掉了
有時修改在提供者頁面會看到警告，大部分情況是可以不用管的，但是有時是因為zookeeper掛掉了，可能需要重啟。
壓力測試？
對於dubbo接口的壓力測試，目前我們是通過編寫http接口來調用進行測試的。
dubbo只是一個調用框架，做的事情其實也不是特別多，但是項目里面還是需要有這么一種管理工具的，比較使用原生的rpc調用，排查問題比較難，和安全性比起來，效率都是次要的。
dubbo是為java而生的，hprose用於寫php遠程調用，據說比較好哦。