新一代通信協(xié)議—— RSocket

一、簡介

RSocket 是一種二進制字節(jié)流傳輸協(xié)議，位于 OSI 模型中的5~6層，底層可以依賴 TCP、WebSocket、Aeron 協(xié)議。最初由 Netflix 開發(fā)，支持 Reactive Streams。其開發(fā)背后的動機是用開銷更少的協(xié)議取代超文本傳輸協(xié)議(HTTP)，HTTP 協(xié)議對于許多任務(wù)(如微服務(wù)通信)來說效率低下。

二、設(shè)計目標(biāo)

• 支持對象傳輸，包括 Fire-and-Forget、Request/Response、Request/Stream、Channel

• 支持應(yīng)用層流量控制

• 支持單連接雙向、多次復(fù)用

• 支持連接修復(fù)

• 更好的使用WebSocket和Aeron協(xié)議

三、消息驅(qū)動

網(wǎng)絡(luò)通信是異步的，RSocket 協(xié)議包含這一點，并將所有通信建模為在單個網(wǎng)絡(luò)連接（TCP）上的、多路復(fù)用的消息流，在等待響應(yīng)時從不同步阻塞。

響應(yīng)式宣言指出：

反應(yīng)式系統(tǒng)依賴異步的消息傳遞，從而確保了松耦合、隔離、位置透明的組件之間有著明確邊界。這一邊界還提供了將失敗作為消息委托出去的手段。使用顯式的消息傳遞，可以通過在系統(tǒng)中塑造并監(jiān)視消息流隊列， 并在必要時應(yīng)用回壓， 從而實現(xiàn)負載管理、 彈性以及流量控制。使用位置透明的消息傳遞作為通信的手段， 使得跨集群或者在單個主機中使用相同的結(jié)構(gòu)成分和語義來管理失敗成為了可能。非阻塞的通信使得接收者可以只在活動時才消耗資源， 從而減少系統(tǒng)開銷。

此外，HTTP/2 FAQ 很好地解釋了在持久連接上采用多路復(fù)用的面向消息的協(xié)議的動機：

• HTTP/1.x 有一個叫做 “head-of-line blocking（隊頭阻塞）” 的問題，在這種情況下，即在一個連接上一次只能有一個未完成請求。

• HTTP/1.1 試圖通過流水線（Pipelining）來解決這個問題，但它并沒有完全解決這個問題(大的或慢的響應(yīng)仍然會阻塞后面的其他響應(yīng))。此外，人們發(fā)現(xiàn)流水線很難部署，因為許多代理和服務(wù)器不能正確地處理它。

在HTTP/1中使用并發(fā)連接和域名分片來緩解HOL問題

• 并發(fā)連接，瀏覽器針對每個源（域名）可以打開4-8個TCP連接，提升并發(fā)度。

• 域名分片，瀏覽器和HTTP/1限制了并發(fā)連接的數(shù)量，那么就把多個域名指向一臺服務(wù)器，從而提升連接數(shù)量。

這迫使客戶端使用一些啟發(fā)式方法（通常是猜測）來確定什么請求在什么時候放在與源站的哪個連接上；由于加載一個頁面的次數(shù)通常是可用連接數(shù)量的10倍或者更多。這會導(dǎo)致被阻塞的請求“瀑布式”的增長，從而嚴(yán)重的影響性能。

多路復(fù)用通過允許多個請求和響應(yīng)消息在一個連接上同時傳輸來解決這些問題；甚至可以將一條消息的部分與另一條消息的部分混合在一起。

使用HTTP/1，瀏覽器為每個源打開4-8個連接，由于許多站點使用多個源，這可能意味著打開單個頁面要加載30多個TCP連接。

一個應(yīng)用程序同時打開如此多的連接，打破了TCP所建立的許多假設(shè)；由于每個連接都會在響應(yīng)中傳輸大量的數(shù)據(jù)，因此TCP緩沖區(qū)很大可能會溢出，從而導(dǎo)致?lián)砣录统瑫r重傳。

一個應(yīng)用程序同時打開如此多的連接，此外，使用如此多的連接不公平地壟斷了網(wǎng)絡(luò)資源，“竊取”了其他性能更好的應(yīng)用程序（如VoIP）的資源。

四、Interaction Models（交互模型）

不合適的協(xié)議會增加系統(tǒng)開發(fā)的成本。它可能是一個不匹配的抽象，但是我們必須將系統(tǒng)設(shè)計強加到他允許的交互模型中。這迫使開發(fā)人員花費額外的時間來解決它的缺點，以處理錯誤并獲得可接受的性能。在多語言環(huán)境中，這個問題被放大了，因為不同的語言將使用不同的方法來解決這個問題，這需要團隊之間的額外協(xié)調(diào)。到目前為止，通信協(xié)議事實上的標(biāo)準(zhǔn)是HTTP，它只支持請求/響應(yīng)的交互模式。在某些情況下，這可能不是最理想通信模型。

一個例子是推送通知。使用request/respones交互模型，客戶端必須使用輪訓(xùn)不斷檢查服務(wù)端的狀態(tài)。應(yīng)用程序每秒執(zhí)行大量的請求，只是為了輪詢，然后被告知沒有適合它們的東西。這對于客戶端、服務(wù)器、網(wǎng)絡(luò)來說是巨大的浪費?；ㄙM金錢；并增加了基礎(chǔ)設(shè)施的規(guī)模、運營的復(fù)雜性，從而提高了可用性。它還通常會增加用戶接收通知時的延遲，因為輪詢會縮減到更長的間隔以試圖降低成本。

出于這個和其他原因，RSocket不僅僅局限于一個交互模型。下面描述的各種支持的交互模型為系統(tǒng)設(shè)計提供了強大的新可能性：

4.1 Fire-and-Forget（即發(fā)即棄）

即發(fā)即棄是請求/響應(yīng)的優(yōu)化，在不需要響應(yīng)時很有用。它允許顯著的性能優(yōu)化，不僅僅是通過跳過響應(yīng)來節(jié)省網(wǎng)絡(luò)使用，而且還可以減少客戶端和服務(wù)器的處理時間，因為客戶端不需要記錄和等待請求關(guān)聯(lián)的響應(yīng)和取消請求。

此交互模型對于支持有損的用例非常有用，例如非關(guān)鍵事件日志記錄。

可以這樣使用：

Future<Void> completionSignalOfSend = socketClient.fireAndForget(message);

4.2 Request/Response (single-response)（請求/響應(yīng)（單響應(yīng)））

仍然支持標(biāo)準(zhǔn)請求/響應(yīng)語義，并且仍有望代表 RSocket 連接上的大多數(shù)請求。這些請求/響應(yīng)交互可以被認為是優(yōu)化的“只有 1 個響應(yīng)的流”，并且是在單個連接上多路復(fù)用的異步消息。

消費者“等待”響應(yīng)消息，所以它看起來像一個典型的請求/響應(yīng)，但它從不同步阻塞。

可以這樣使用：

Future<Payload> response = socketClient.requestResponse(requestPayload);

4.3 Request/Stream (multi-response, finite)（請求/流（多響應(yīng)，有限））

從request/response延伸出來的是request/stream，它允許多條消息流回。將此視為“集合”或“列表”響應(yīng)，但不是將所有數(shù)據(jù)作為單個響應(yīng)返回，而是按順序流回每個元素。

用例可能包括以下內(nèi)容：

• 獲取視頻列表

• 在目錄中獲取產(chǎn)品

• 逐行檢索文件

可以這樣使用：

Publisher<Payload> response = socketClient.requestStream(requestPayload);

4.4 Channel（通道）

通道是雙向的，在兩個方向上都有消息流。

受益于此交互模型的示例用例是：

• 客戶端請求一個數(shù)據(jù)流，該數(shù)據(jù)流最初會破壞當(dāng)前的世界視圖

• 當(dāng)發(fā)生變化時，增量/差異從服務(wù)器發(fā)送到客戶端

• 客戶端隨時間更新訂閱以添加/刪除標(biāo)準(zhǔn)/主題/等。

如果沒有雙向通道，客戶端將不得不取消初始請求，重新請求并從頭開始接收所有數(shù)據(jù)，而不是僅僅更新訂閱并有效地獲取差異。

可以這樣使用：

Publisher<Payload> output = socketClient.requestChannel(Publisher<Payload> input);

五、協(xié)議形式

• 連接上傳輸?shù)臄?shù)據(jù)是流（Stream）

• 流（Stream）由幀（Frame）組成

• 幀（Frame）包含了元數(shù)據(jù)（MetaData）與業(yè)務(wù)數(shù)據(jù)（Data）

基于 RSocket 協(xié)議，我們的業(yè)務(wù)數(shù)據(jù)會被打包成幀，并以幀流的形式在客戶端與服務(wù)端互相傳輸。所以 RSocket 的所有特性都是基于這個幀流實現(xiàn)的。協(xié)議詳情可以參考：https://rsocket.io/about/protocol

RSocket是一個二進制協(xié)議，也就是說在一個RSocket連接上傳輸?shù)南Ⅲw對數(shù)據(jù)格式?jīng)]有任何要求，應(yīng)用程序可以為所欲為的壓縮數(shù)據(jù)量的大小。

這樣的二進制協(xié)議通常來說能給性能帶來極大的提升，但是產(chǎn)生的代價是，網(wǎng)絡(luò)中間件也會因為無法解讀消息體中的數(shù)據(jù)，喪失了在對具體應(yīng)用流量進行監(jiān)控，日志和路由的能力。RSocket通過把每個消息體分成data和metadata的方式，在保證高效傳輸?shù)那疤嵯?，提供了暴露少量元?shù)據(jù)給網(wǎng)絡(luò)中間件的能力。

對于每個data和metadata，應(yīng)用可以采用不同的序列化方法。

• data一般作為應(yīng)用本身需要傳遞的業(yè)務(wù)數(shù)據(jù)，采取自定義的高效序列化方式，且對網(wǎng)絡(luò)基礎(chǔ)設(shè)施不可見。

• metadata可以采用網(wǎng)絡(luò)基礎(chǔ)設(shè)施一致默認的格式。在分布式傳輸?shù)倪^程中，這些中間件可以按需求對metadata進行讀寫，然后監(jiān)控應(yīng)用健康狀況或者調(diào)整路由。

六、RSocket與其它協(xié)議有什么區(qū)別？

6.1 對比Http1.x

Http1.x只支持request/response，但是現(xiàn)實應(yīng)用中并不是所有請求都需要有回應(yīng)（Fire And Forget）、有的需求需要一個請求返回一個數(shù)據(jù)流（request/stream）、有的還需要雙向數(shù)據(jù)傳輸(channel)。

6.2 對比Http2.x

http2.x不支持應(yīng)用層流量控制、偽雙向傳輸，即服務(wù)端push數(shù)據(jù)本質(zhì)上還是對客戶端請求的響應(yīng)，而不是直接推送。RSocket做到了真正的雙向傳輸，使得服務(wù)端可以調(diào)用客戶端服務(wù)，使得服務(wù)端和客戶端在角色上完全對等，即兩邊同時是Requester和Responder。

6.3 對比grpc

• grpc需要依賴protobuf，本質(zhì)上還是http2.x。RSocket不限制編解碼，可以是xml、json、protobuf等。

• 性能上grpc要差一些：詳見壓測對比，https://dzone.com/articles/rsocket-vs-grpc-benchmark

6.4 對比TCP

一個應(yīng)用層的協(xié)議、一個傳輸層的協(xié)議，其實兩者不在一個層面，為啥要作比較呢，因為netty讓tcp層的編程也很容易，但是需要自定義傳輸協(xié)議，比如定義header、body長度等等，用起來還是很麻煩的。

6.5 對比WebSockets

websocket不支持應(yīng)用層流量控制，本質(zhì)上也是一端請求另一端響應(yīng)，不支持連接修復(fù)。

七、RSocket適用于哪些場景？

• 移動設(shè)備與服務(wù)器的連接

• 數(shù)據(jù)雙向傳輸，且支持流量控制。支持背壓，背壓的意思：如果客戶端請求服務(wù)端過快，那么服務(wù)端會堆積請求，最終耗光資源。有了背壓機制，服務(wù)端可以根據(jù)自己的資源來控制客戶端的請求速度，即調(diào)用客戶端告訴它別發(fā)那么快。

• 支持連接修復(fù)，比如手機進地鐵之后，網(wǎng)絡(luò)斷開一段時間，其他協(xié)議需要重新建立連接，RSocket則可以修復(fù)連接繼續(xù)傳輸幀數(shù)據(jù)。

• 微服務(wù)場景

• spring cloud目前支持的http協(xié)議，不能fire and forget、不能請求流數(shù)據(jù)、不能單連接雙向調(diào)用；替換成RSocket之后可以滿足以上需求的同時提高性能。且針對服務(wù)治理、負載均衡等RSocket都在慢慢完善。

• 由于微服務(wù)和移動設(shè)備的普及，RSocket火起來應(yīng)該就是這幾年的事兒，讓我們拭目以待吧。