dubbo通訊協議之對比
dubbo共支援如下幾種通訊協議：
- dubbo://
- rmi://
- hessian://
- http://
- webservice://
- thrift://
- memcached://
- redis://
部分協議的特點和使用場景如下：
- 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等。