2019獨角獸企業重金招聘Python工程師標準>>>

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

?

缺省協議，使用基于netty3.2.2+hessian3.2.1交互。

??? 連接個數：單連接
??? 連接方式：長連接
??? 傳輸協議：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問題。

(1) 約束：

??? 參數及返回值需實現Serializable接口
??? 參數及返回值需有無參構造函數(可以是private的)或者有參構造所有函數允許傳入null值。
??? 參數及返回值不能自定義實現List, Map, Number, Date, Calendar等接口，只能用JDK自帶的實現，因為hessian會做特殊處理，自定義實現類中的屬性值都會丟失。
??? Hessian序列化，只傳成員屬性值和值的類型，不傳方法或靜態變量，兼容情況：(由吳亞軍提供)
??? 數據通訊 ??? 情況 ??? 結果
??? A->B ??? 類A多一種 屬性（或者說類B少一種 屬性） ??? 不拋異常，A多的那 個屬性的值，B沒有， 其他正常
??? A->B ??? 枚舉A多一種 枚舉（或者說B少一種 枚舉），A使用多 出來的枚舉進行傳輸 ??? 拋異常
??? A->B ??? 枚舉A多一種 枚舉（或者說B少一種 枚舉），A不使用 多出來的枚舉進行傳輸 ??? 不拋異常，B正常接 收數據
??? A->B ??? A和B的屬性 名相同，但類型不相同 ??? 拋異常
??? A->B ??? serialId 不相同 ??? 正常傳輸

??? 總結：會拋異常的情況：枚 舉值一邊多一種，一邊少一種，正好使用了差別的那種，或者屬性名相同，類型不同

接口增加方法，對客戶端無影響，如果該方法不是客戶端需要的，客戶端不需要重新部署；
輸入參數和結果集中增加屬性，對客戶端無影響，如果客戶端并不需要新屬性，不用重新
部署；
輸入參數和結果集屬性名變化，對客戶端序列化無影響，但是如果客戶端不重新部署，不管輸入還是輸

轉載于:https://my.oschina.net/91jason/blog/377674

總結

以上是生活随笔為你收集整理的dubbo协议参考的全部內容，希望文章能夠幫你解決所遇到的問題。

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