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

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

Dubbo 協議注意項