dubbo://

Dubbo 缺省協議采用單一長連接和 NIO 異步通訊，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況。

反之，Dubbo 缺省協議不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很低。

• Transporter: mina, netty, grizzy
• Serialization: dubbo, hessian2, java, json
• Dispatcher: all, direct, message, execution, connection
• ThreadPool: fixed, cached

特性

缺省協議，使用基于 mina?1.1.7?和 hessian?3.2.1?的 tbremoting 交互。

• 連接個數：單連接
• 連接方式：長連接
• 傳輸協議：TCP
• 傳輸方式：NIO 異步傳輸
• 序列化：Hessian 二進制序列化
• 適用范圍：傳入傳出參數數據包較小（建議小于100K），消費者比提供者個數多，單一消費者無法壓滿提供者，盡量不要用 dubbo 協議傳輸大文件或超大字符串。
• 適用場景：常規遠程服務方法調用

約束

• 參數及返回值需實現?Serializable?接口
• 參數及返回值不能自定義實現?List,?Map,?Number,?Date,?Calendar?等接口，只能用 JDK 自帶的實現，因為 hessian 會做特殊處理，自定義實現類中的屬性值都會丟失。
• Hessian 序列化，只傳成員屬性值和值的類型，不傳方法或靜態變量，兼容情況?[1][2]：

數據通訊情況結果

A->B	類A多一種 屬性（或者說類B少一種 屬性）	不拋異常，A多的那 個屬性的值，B沒有， 其他正常
A->B	枚舉A多一種 枚舉（或者說B少一種 枚舉），A使用多 出來的枚舉進行傳輸	拋異常
A->B	枚舉A多一種 枚舉（或者說B少一種 枚舉），A不使用 多出來的枚舉進行傳輸	不拋異常，B正常接 收數據
A->B	A和B的屬性 名相同，但類型不相同	拋異常
A->B	serialId 不相同	正常傳輸

接口增加方法，對客戶端無影響，如果該方法不是客戶端需要的，客戶端不需要重新部署。輸入參數和結果集中增加屬性，對客戶端無影響，如果客戶端并不需要新屬性，不用重新部署。

輸入參數和結果集屬性名變化，對客戶端序列化無影響，但是如果客戶端不重新部署，不管輸入還是輸出，屬性名變化的屬性值是獲取不到的。

總結：服務器端和客戶端對領域對象并不需要完全一致，而是按照最大匹配原則。

常見問題

為什么要消費者比提供者個數多?

因 dubbo 協議采用單一長連接，假設網絡為千兆網卡?[3]，根據測試經驗數據每條連接最多只能壓滿 7MByte(不同的環境可能不一樣，供參考)，理論上 1 個服務提供者需要 20 個服務消費者才能壓滿網卡。

為什么不能傳大包?

因 dubbo 協議采用單一長連接，如果每次請求的數據包大小為 500KByte，假設網絡為千兆網卡?[3:1]，每條連接最大 7MByte(不同的環境可能不一樣，供參考)，單個服務提供者的 TPS(每秒處理事務數)最大為：128MByte / 500KByte = 262。單個消費者調用單個服務提供者的 TPS(每秒處理事務數)最大為：7MByte / 500KByte = 14。如果能接受，可以考慮使用，否則網絡將成為瓶頸。

為什么采用異步單一長連接?

因為服務的現狀大都是服務提供者少，通常只有幾臺機器，而服務的消費者多，可能整個網站都在訪問該服務，比如 Morgan 的提供者只有 6 臺提供者，卻有上百臺消費者，每天有 1.5 億次調用，如果采用常規的 hessian 服務，服務提供者很容易就被壓跨，通過單一連接，保證單一消費者不會壓死提供者，長連接，減少連接握手驗證等，并使用異步 IO，復用線程池，防止 C10K 問題。

?

總結

以上是生活随笔為你收集整理的后台服务系统之Dubbo协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。