dubbo:// 協議參考手冊
dubbo 預設協議採用單一長連線和 nio 非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。
預設協議，使用基於 mina1.1.7和 hessian3.2.1的 tbremoting 互動。
資料通訊
情況結果
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 協議預設每服務每提供者每消費者使用單一長連線，如果資料量較大，可以使用多個連線。
dubbo.properties配置：
dubbo.service.protocol=dubbo因 dubbo 協議採用單一長連線，假設網路為千兆網絡卡 3，根據測試經驗資料每條連線最多只能壓滿 7mbyte(不同的環境可能不一樣，供參考)，理論上 1 個服務提供者需要 20 個服務消費者才能壓滿網絡卡。
為什麼不能傳大包?
因 dubbo 協議採用單一長連線，如果每次請求的資料報大小為 500kbyte，假設網路為千兆網絡卡 3，每條連線最大 7mbyte(不同的環境可能不一樣，供參考)，單個服務提供者的 tps(每秒處理事務數)最大為：128mbyte / 500kbyte = 262。單個消費者呼叫單個服務提供者的 tps(每秒處理事務數)最大為：7mbyte / 500kbyte = 14。如果能接受，可以考慮使用，否則網路將成為瓶頸。
為什麼採用非同步單一長連線?
因為服務的現狀大都是服務提供者少，通常只有幾台機器，而服務的消費者多，可能整個**都在訪問該服務，比如 morgan 的提供者只有 6 臺提供者，卻有上百臺消費者，每天有 1.5 億次呼叫，如果採用常規的 hessian 服務，服務提供者很容易就被壓跨，通過單一連線，保證單一消費者不會壓死提供者，長連線，減少連線握手驗證等，並使用非同步 io，復用執行緒池，防止 c10k 問題。
由吳亞軍提供 ↩︎
總結：會拋異常的情況：列舉值一邊多一種，一邊少一種，正好使用了差別的那種，或者屬性名相同，型別不同 ↩︎
1024mbit=128mbyte ↩︎
Dubbo系列之 Dubbo入門介紹
分布式soa服務治理框架dubbo 背景 隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。比較常用的分布式服務治理框架也有很多，比如著名的spring cloud dubbo等 spring clo...
dubbo原始碼 dubbo之Listener
1.exporterlistener spi public inte ce exporterlistener 使用者可以繼承該方法重寫需要的方法 public abstract class exporterlisteneradapter implements exporterlistener pub...
Dubbo 如何使用Dubbo
如上圖所示，dubbo的設計結構如上所示。包含服務消費者 consumer 服務提供者 provider 註冊中心 registry 監控中心 monitor 紫色箭頭代表初始化時的動作 藍色虛線箭頭代表非同步動作 藍色實線箭頭代表同步動作 1 配置乙個zookeeper為註冊中心，也可以使用red...