Dubbo 協議注意項


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 不相同     正常傳輸

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM