dubbo通訊協議

對dubbo的協議的學習，能夠知道目前主流RPC通訊大概是什麼狀況，本文參考dubbo官方文檔

http://dubbo.io/User+Guide-zh.htm

dubbo共支持以下幾種通訊協議：

• dubbo://
• rmi://
• hessian://
• http://
• webservice://
• thrift://
• memcached://
• redis://

部分協議的特色和使用場景以下：

一、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問題。

二、RMI

RMI協議採用JDK標準的java.rmi.*實現，採用阻塞式短鏈接和JDK標準序列化方式

Java標準的遠程調用協議。

鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：TCP
傳輸方式：同步傳輸
序列化：Java標準二進制序列化
適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差很少，可傳文件。
適用場景：常規遠程服務方法調用，與原生RMI服務互操做

三、hessian

Hessian協議用於集成Hessian的服務，Hessian底層採用Http通信，採用Servlet暴露服務，Dubbo缺省內嵌Jetty做爲服務器實現

基於Hessian的遠程調用協議。

鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進制序列化
適用範圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。
適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操做

四、http

採用Spring的HttpInvoker實現

基於http表單的遠程調用協議。

鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化（JSON）
適用範圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
適用場景：需同時給應用程序和瀏覽器JS使用的服務。

五、webservice

基於CXF的frontend-simple和transports-http實現

基於WebService的遠程調用協議。

鏈接個數：多鏈接
鏈接方式：短鏈接
傳輸協議：HTTP
傳輸方式：同步傳輸
序列化：SOAP文本序列化
適用場景：系統集成，跨語言調用。

六、thrif

Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，好比service name，magic number等。