一、dubbo的特性
(1) 連通性：
- 注冊中心負責服務地址的注冊與查找，相當於目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發請求，壓力較小
- 監控中心負責統計各服務調用次數，調用時間等，統計先在內存匯總后每分鍾一次發送到監控中心服務器，並以報表展示
- 服務提供者向注冊中心注冊其提供的服務，並匯報調用時間到監控中心，此時間不包含網絡開銷
- 服務消費者向注冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時匯報調用時間到監控中心，此時間包含網絡開銷
- 注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外
- 注冊中心通過長連接感知服務提供者的存在，服務提供者宕機，注冊中心將立即推送事件通知消費者
- 注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
- 注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
(2) 健狀性：
- 監控中心宕掉不影響使用，只是丟失部分采樣數據
- 數據庫宕掉后，注冊中心仍能通過緩存提供服務列表查詢，但不能注冊新服務
- 注冊中心對等集群，任意一台宕掉后，將自動切換到另一台
- 注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態，任意一台宕掉后，不影響使用
- 服務提供者全部宕掉后，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
(3) 伸縮性：
- 注冊中心為對等集群，可動態增加機器部署實例，所有客戶端將自動發現新的注冊中心
- 服務提供者無狀態，可動態增加機器部署實例，注冊中心將推送新的服務提供者信息給消費者
(4) 升級性：
當服務集群規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分布式服務架構不會帶來阻力：
Dubbo支持的協議
在通信過程中，不同的服務等級一般對應着不同的服務質量，那么選擇合適的協議便是一件非常重要的事情。你可以根據你應用的創建來選擇。例如，使用RMI協議，一般會受到防火牆的限制，所以對於外部與內部進行通信的場景，就不要使用RMI協議，而是基於HTTP協議或者Hessian協議。Dubbo支持8種左右的協議，如下所示：
- (1) dubbo:// Dubbo協議
- (2) rmi:// RMI協議
- (3) hessian:// Hessian協議
- (4) http:// HTTP協議
- (5) webservice:// WebService協議
- (6) thrift:// Thrift協議
- (7) memcached:// Memcached協議
- (8)redis:// Redis協議
- 在通信過程中，不同的服務等級一般對應着不同的服務質量，那么選擇合適的協議便是一件非常重要的事情。你可以根據你應用的創建來選擇。
- 例如，使用RMI協議，一般會受到防火牆的限制，所以對於外部與內部進行通信的場景，就不要使用RMI協議，而是基於HTTP協議或者Hessian協議。
部分協議的特點和使用場景如下：
1、dubbo協議
Dubbo缺省協議采用單一長連接和NIO異步通訊，適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況。
缺省協議，使用基於mina1.1.7+hessian3.2.1的tbremoting交互。
連接個數：單連接
連接方式：長連接
傳輸協議：TCP
傳輸方式：NIO異步傳輸
序列化：Hessian二進制序列化
適用范圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用
為什么要消費者比提供者個數多： 因dubbo協議采用單一長連接， 假設網絡為千兆網卡(1024Mbit=128MByte)， 根據測試經驗數據每條連接最多只能壓滿7MByte(不同的環境可能不一樣，供參考)， 理論上1個服務提供者需要20個服務消費者才能壓滿網卡。 為什么不能傳大包： 因dubbo協議采用單一長連接， 如果每次請求的數據包大小為500KByte，假設網絡為千兆網卡(1024Mbit=128MByte)，每條連接最大7MByte(不同的環境可能不一樣，供參考)， 單個服務提供者的TPS(每秒處理事務數)最大為：128MByte / 500KByte = 262。 單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大為：7MByte / 500KByte = 14。 如果能接受，可以考慮使用，否則網絡將成為瓶頸。 為什么采用異步單一長連接： 因為服務的現狀大都是服務提供者少，通常只有幾台機器， 而服務的消費者多，可能整個網站都在訪問該服務， 比如Morgan的提供者只有6台提供者，卻有上百台消費者，每天有1.5億次調用， 如果采用常規的hessian服務，服務提供者很容易就被壓跨， 通過單一連接，保證單一消費者不會壓死提供者， 長連接，減少連接握手驗證等， 並使用異步IO，復用線程池，防止C10K問題。
2、RMI
RMI協議采用JDK標准的java.rmi.*實現，采用阻塞式短連接和JDK標准序列化方式
Java標准的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：TCP
傳輸方式：同步傳輸
序列化：Java標准二進制序列化
適用范圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。
適用場景：常規遠程服務方法調用，與原生RMI服務互操作
3、hessian
Hessian協議用於集成Hessian的服務，Hessian底層采用Http通訊，采用Servlet暴露服務，Dubbo缺省內嵌Jetty作為服務器實現
基於Hessian的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進制序列化
適用范圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。
適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操作
4、http
采用Spring的HttpInvoker實現
基於http表單的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化（JSON）
適用范圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
適用場景：需同時給應用程序和瀏覽器JS使用的服務。
5、webservice
基於CXF的frontend-simple和transports-http實現
基於WebService的遠程調用協議。
連接個數：多連接
連接方式：短連接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：SOAP文本序列化
適用場景：系統集成，跨語言調用。
6、thrif
Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，比如service name，magic number等。
參考：dubbo通信協議之對比