Dubbo3 dubbo 協(xié)議

2022-04-24 16:40 更新

dubbo:// 協(xié)議參考手冊(cè)

Dubbo 缺省協(xié)議采用單一長(zhǎng)連接和 NIO 異步通訊,適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用,以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況。

反之,Dubbo 缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務(wù),比如傳文件,傳視頻等,除非請(qǐng)求量很低。

dubbo-protocol.jpg

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

特性

缺省協(xié)議,使用基于 netty 3.2.5.Final 和 hessian2 3.2.1-fixed-2(Alibaba embed version) 的 tbremoting 交互。

  • 連接個(gè)數(shù):?jiǎn)芜B接
  • 連接方式:長(zhǎng)連接
  • 傳輸協(xié)議:TCP
  • 傳輸方式:NIO 異步傳輸
  • 序列化:Hessian 二進(jìn)制序列化
  • 適用范圍:傳入傳出參數(shù)數(shù)據(jù)包較?。ńㄗh小于100K),消費(fèi)者比提供者個(gè)數(shù)多,單一消費(fèi)者無(wú)法壓滿提供者,盡量不要用 dubbo 協(xié)議傳輸大文件或超大字符串。
  • 適用場(chǎng)景:常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用

約束

  • 參數(shù)及返回值需實(shí)現(xiàn) Serializable 接口
  • 參數(shù)及返回值不能自定義實(shí)現(xiàn) List, Map, Number, Date, Calendar 等接口,只能用 JDK 自帶的實(shí)現(xiàn),因?yàn)?hessian 會(huì)做特殊處理,自定義實(shí)現(xiàn)類中的屬性值都會(huì)丟失。
  • Hessian 序列化,只傳成員屬性值和值的類型,不傳方法或靜態(tài)變量,兼容情況 12
數(shù)據(jù)通訊情況結(jié)果
A->B類A多一種 屬性(或者說(shuō)類B少一種 屬性)不拋異常,A多的那 個(gè)屬性的值,B沒(méi)有, 其他正常
A->B枚舉A多一種 枚舉(或者說(shuō)B少一種 枚舉),A使用多 出來(lái)的枚舉進(jìn)行傳輸拋異常
A->B枚舉A多一種 枚舉(或者說(shuō)B少一種 枚舉),A不使用 多出來(lái)的枚舉進(jìn)行傳輸不拋異常,B正常接 收數(shù)據(jù)
A->BA和B的屬性 名相同,但類型不相同拋異常
A->BserialId 不相同正常傳輸

接口增加方法,對(duì)客戶端無(wú)影響,如果該方法不是客戶端需要的,客戶端不需要重新部署。輸入?yún)?shù)和結(jié)果集中增加屬性,對(duì)客戶端無(wú)影響,如果客戶端并不需要新屬性,不用重新部署。

輸入?yún)?shù)和結(jié)果集屬性名變化,對(duì)客戶端序列化無(wú)影響,但是如果客戶端不重新部署,不管輸入還是輸出,屬性名變化的屬性值是獲取不到的。

總結(jié):服務(wù)器端和客戶端對(duì)領(lǐng)域?qū)ο蟛⒉恍枰耆恢?,而是按照最大匹配原則。

配置

配置協(xié)議:

<dubbo:protocol name="dubbo" port="20880" />

設(shè)置默認(rèn)協(xié)議:

<dubbo:provider protocol="dubbo" />

設(shè)置某個(gè)服務(wù)的協(xié)議:

<dubbo:service interface="..." protocol="dubbo" />

多端口:

<dubbo:protocol id="dubbo1" name="dubbo" port="20880" />
<dubbo:protocol id="dubbo2" name="dubbo" port="20881" />

配置協(xié)議選項(xiàng):

<dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo” serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9” buffer=“8192” accepts=“1000” payload=“8388608” />

多連接配置:

Dubbo 協(xié)議缺省每服務(wù)每提供者每消費(fèi)者使用單一長(zhǎng)連接,如果數(shù)據(jù)量較大,可以使用多個(gè)連接。

<dubbo:service interface="..." connections="1"/>
<dubbo:reference interface="..." connections="1"/>
  • <dubbo:service connections="0"> 或 <dubbo:reference connections="0"> 表示該服務(wù)使用 JVM 共享長(zhǎng)連接。缺省
  • <dubbo:service connections="1"> 或 <dubbo:reference connections="1"> 表示該服務(wù)使用獨(dú)立長(zhǎng)連接。
  • <dubbo:service connections="2"> 或<dubbo:reference connections="2"> 表示該服務(wù)使用獨(dú)立兩條長(zhǎng)連接。

為防止被大量連接撐掛,可在服務(wù)提供方限制大接收連接數(shù),以實(shí)現(xiàn)服務(wù)提供方自我保護(hù)。

<dubbo:protocol name="dubbo" accepts="1000" />

常見(jiàn)問(wèn)題

為什么要消費(fèi)者比提供者個(gè)數(shù)多?

因 dubbo 協(xié)議采用單一長(zhǎng)連接,假設(shè)網(wǎng)絡(luò)為千兆網(wǎng)卡 3,根據(jù)測(cè)試經(jīng)驗(yàn)數(shù)據(jù)每條連接最多只能壓滿 7MByte(不同的環(huán)境可能不一樣,供參考),理論上 1 個(gè)服務(wù)提供者需要 20 個(gè)服務(wù)消費(fèi)者才能壓滿網(wǎng)卡。

為什么不能傳大包?

因 dubbo 協(xié)議采用單一長(zhǎng)連接,如果每次請(qǐng)求的數(shù)據(jù)包大小為 500KByte,假設(shè)網(wǎng)絡(luò)為千兆網(wǎng)卡 3,每條連接最大 7MByte(不同的環(huán)境可能不一樣,供參考),單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數(shù))最大為:128MByte / 500KByte = 262。單個(gè)消費(fèi)者調(diào)用單個(gè)服務(wù)提供者的 TPS(每秒處理事務(wù)數(shù))最大為:7MByte / 500KByte = 14。如果能接受,可以考慮使用,否則網(wǎng)絡(luò)將成為瓶頸。

為什么采用異步單一長(zhǎng)連接?

因?yàn)榉?wù)的現(xiàn)狀大都是服務(wù)提供者少,通常只有幾臺(tái)機(jī)器,而服務(wù)的消費(fèi)者多,可能整個(gè)網(wǎng)站都在訪問(wèn)該服務(wù),比如 Morgan 的提供者只有 6 臺(tái)提供者,卻有上百臺(tái)消費(fèi)者,每天有 1.5 億次調(diào)用,如果采用常規(guī)的 hessian 服務(wù),服務(wù)提供者很容易就被壓跨,通過(guò)單一連接,保證單一消費(fèi)者不會(huì)壓死提供者,長(zhǎng)連接,減少連接握手驗(yàn)證等,并使用異步 IO,復(fù)用線程池,防止 C10K 問(wèn)題。


  1. 由吳亞軍提供 ??

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

  3. 1024Mbit=128MByte ??


以上內(nèi)容是否對(duì)您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號(hào)
微信公眾號(hào)

編程獅公眾號(hào)