dubbo是乙個分布式服務框架，致力於提供高效能和透明化的rpc遠端服務呼叫方案，以及soa服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分布式的需求，其實是不需要用的，只有在分布式的時候，才有dubbo這樣的分布式服務框架的需求，並且本質上是個服務呼叫的東東，說白了就是個遠端服務呼叫的分布式框架（告別web service模式中的wsdl，以服務者與消費者的方式在dubbo上註冊）
其核心部分包含:
1. 遠端通訊: 提供對多種基於長連線的nio框架抽象封裝，包括多種執行緒模型，序列化，以及「請求-響應」模式的資訊交換方式。
2. 集群容錯: 提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，位址路由，動態配置等集群支援。
3. 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使位址透明，使服務提供方可以平滑增加或減少機器。
1.透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何api侵入。
2.軟負載均衡及容錯機制，可在內網替代f5等硬體負載均衡器，降低成本，減少單點。
3. 服務自動註冊與發現，不再需要寫死服務提供方位址，註冊中心基於介面名查詢服務提供者的ip位址，並且能夠平滑新增或刪除服務提供者。
dubbo採用全spring配置方式，透明化接入應用，對應用沒有任何api侵入，只需用spring載入dubbo的配置即可，dubbo基於spring的schema擴充套件進行載入。
之前使用web service，我想測試介面可以通過模擬訊息的方式通過soapui或lr進行功能測試或效能測試。但現在使用dubbo，介面之間不能直接互動，我嘗試通過模擬消費者位址測試，結果不堪入目，再而使用jmeter通過junit進行測試，但還是需要往dubbo上去註冊，如果再不給提供源**的前提下，這個測試用例不好寫啊....
dubbo架構圖如下所示：
節點角色說明：
provider: 暴露服務的服務提供方。
consumer: 呼叫遠端服務的服務消費方。
registry: 服務註冊與發現的註冊中心。
monitor: 統計服務的呼叫次調和呼叫時間的監控中心。
container: 服務執行容器。
這點我覺得非常好，角色分明，可以根據每個節點角色的狀態來確定該服務是否正常。
呼叫關係說明：
0 服務容器負責啟動，載入，執行服務提供者。
1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4. 服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
5. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
dubbo的容錯性顯而易見，效能方面還沒有還得及測，我們系統某頁面需要掉5次介面，本來想建議做個快取，但業務關係不能採納，還需要研究下dubbo的效能調優問題...
以下摘自：
Dubbo介面的invek資料
使用telnet命令進入控制台 命令 telnet ip 埠 這個埠和ip，可以去dubbo管理控制台中搜尋服務名，然後找到提供者的機器ip 使用invoke命令注入 如果注入的是json 那就直接傳入json串就ok了，如果是基礎資料型別，也可以分別對應引數直接傳 invoke service.m...
Linux命令呼叫Dubbo介面
第一步 telnet ip dubbo埠號，連線dubbo。例如 telnet 127.0.0.1 21963 第二步 ls，獲取所有dubbo service 第三步 ls service全名稱，例如 ls com.zm.dubbo.test.service.mydubboservice 第四步 ...
Dubbo服務介面的設計原則
1 介面粒度 1.1 服務介面盡可能大粒度，每個服務方法應代表乙個功能，而不是某功能的乙個步驟，否則將面臨分布式事務問題，dubbo暫未提供分布式事務支援。同時可以減少系統間的網路互動。1.2 服務介面建議以業務場景為單位劃分，並對相近業務做抽象，防止介面數量 1.3 不建議使用過於抽象的通用介面，...