淺談RSocket與響應式編程

簡介： RSocket是高效一個二進制的網路通訊協定，能夠滿足很多場景下使用。另外，RSocket也是一個激進的響應式捍衛者，激進到連API都跟響應式無縫整合。本文我們將和大家分享RSocket與響應式編程。

作者 | 素渡
來源 | 阿裏技術公眾號

一 RSocket的主要特性

首先，RSocket是高效一個二進制的網路通訊協定，能夠滿足很多場景下使用。其次，RSocket是一個激進的響應式捍衛者，激進到連API都跟響應式無縫整合。

1 四種通訊模式

即發即忘FireAndForget

立即發送一個請求，無需為這個請求發送響應報文。適用於監控埋點，日誌上報等，這種場景下無需回執，遺失幾個請求無傷大雅。

請求響應RequestResponse

請求方發送一條請求訊息，響應方收到請求後並返回一條響應訊息。傳統的HTTP是典型的RequestResponse。

流RequestStream

請求方發送一個請求報文，響應方發回N個響應報文。傳統的MQ是典型的RequestStream。

通道RequestChannel

建立一個通道上下文，雙方可以互相發送訊息。IM是個典型的RequestChannel通訊場景。

2 雙向通訊Bi-Directional

RSocket的Client連線到Server，這個過程稱為Setup，在連線成功後，會約定收發訊息的方向邏輯：

當Client請求Server時，發送的請求ID永遠為奇數

當Server請求Client時，發送的請求ID永遠為偶數

正是因為這個奇偶性確定方向的特性，不同於傳統的如HTTP請求，RSocket可以做到雙向請求。

3 其他

二進制協定，緊湊高效

多路復用

基於幀(Frame)的背壓，與ReactiveStreams語意契合

靈活的傳輸層切換: TCP/UDP/WebSocket等

支持Cancel、斷點續傳、租約等高級特性

綜上與HTTP做一些比較，RSocket的效率更高，支持的通訊場景更豐富，也沒有隊頭阻塞的問題。與SocketIO這種基於純事件的框架相比，RSocket的請求具有很清晰的上下文，API精煉易用。

二 RSocket的內部實作

1 幀的設計

幀(Frame)是RSocket協定報文的最小單位。

一個幀由6 bytes的Header和剩余的Body構成，其中Header的4 bytes表示 StreamID，6 bits表示Frame Type, 10 bits作為Flags。Body根據不同的幀型別，結構也不同，常用的帶Payload的幀一般會包括Metadata和Data兩個部份。

傳輸層如果本身不支持分幀特性的(如TCP)，那麽RSocket會用3 bytes的uint24表示幀長度，所以最大的幀大小是16MB。

如果幀超出16MB，RSocket支持幀分裂重組，也就是拆成更小的幀，接收端再自動重組。

2 數據載體——Payload

基於幀之上，一般開發者接觸到的是Payload, 它類似一個HTTP報文，可以是一個Request，也可以是一個Response。由兩個二進制部份組成：

Metadata——後設資料，類似HTTP的header

Data——數據，類似HTTP的body

3 架構

這瑞奇於筆者在實作Golang版SDK的基礎上整理的架構圖，Java版基本也類似。

Transport層將網路二進制流編解碼為Frames。

RSocket支持自訂最大Frame Size，預設16MB，當某個Frame超出時，會被拆解為N個小Frame，收到時再重組，在介紹幀的時候也提到了，這個特性稱為Fragmentation。

DuplexConnection轉換Frames為Payload，抽象為一個個Request/Response上下文，並負責讀寫。

RSocket組裝Connection為RSocket Interface，其中Resumable支持斷點續傳，連線斷開重連也能自愈，個人覺得這個特性有點雞肋，在弱網環境有些優勢，但是因為期間會緩存住未處理完畢的幀，所以會耗費大量的系統資源。

RSocket使用Reactor核心庫暴露為4種通訊模式，抽象為高級API。

4 玩法

RSocket有很多玩法，傳統的RPC自然不在話下，用來做IM也未嘗不可，某些特性也可以用來做代理或者網路穿透。

IoT的場景，比如小明的家裏有個智慧空調，小明想在外面透過手機APP來控制空調開關，如何優雅地描述這個控制問題？最精煉的解決方案就是"小明呼叫空調上開關的API"。

另外最經典的玩法就是Broker了，Broker類似一種「軟路由」的方案，可以讓服務的釋出存取變得簡單。釋出服務只要連線到Broker，呼叫方透過反向請求的方式來讓Broker透明轉發即可，摒棄了傳統的註冊中心，埠管理等常見的服務治理手段。

5 關於RSocket Broker

Broker有很多優勢，釋出服務不需要監聽埠，無需Sidecar，服務註冊變得簡單，無需zk、etcd之類，LoadBalance變得簡單，也更安全，沒監聽埠後很難攻擊。也有很多劣勢，網路上多了一跳，效能是有一定損耗的，Broker是中心化設計，類似我們平時全域的Nginx一樣，但是Broker的優雅啟停顯然更加復雜，受限於整個Broker集群的瓶頸等等。上帝為你關閉了一扇門，就一定會為你開啟一扇窗。

目前高德落地的FaaS中大量使用了基於RSocket架構的集團Broker，支撐了今年的五一長假，峰值QPS超20萬，平穩零故障。

這裏筆者也準備了一個教學用的Mini Broker，演示了兩個瀏覽器之間相互上下文呼叫彼此服務的場景，有興趣的同學可以檢視。

三 響應式編程

響應式編程是個老話題了，它早已無處不在，甚至你在Excel裏SUM求和，本質上也是種響應式的思維。響應式本質上就是響應變化的數據流。RSocket這個協定本身就是以響應式之名，將其擴充套件到網路層面。

1 響應式編程大概長這樣

而在我們平時工作中，必然會引入各種操作和變換：

2 Reactive Streams

JDK推出了響應式標準API，撇開Processor之外，其核心介面就Publisher/Subscriber/Subscription，非常精煉。

Publisher：釋出者，負責生產數據。唯一的方法subscribe，接收一個Subscriber開始一次新的訂閱。

Subscriber：訂閱者，負責訂閱消費數據。

Subscription：訂閱，某次訂閱的上下文控制，如取消、通知獲取下N條數據。

Spring的Reactor是一個標準的實作，其一次完整的執行過程如下圖：

建立subscriber，開始訂閱Publisher。

生成上下文subscription。

Publisher就緒，呼叫onSubscribe。

Publisher開始生產數據。

每條成功生產的數據回呼onNext。

當生產失敗時，回呼onError並結束當前訂閱。

當所有數據生產完畢時，回呼onComplete並結束當前訂閱。

中途可以呼叫subscription隨時cancel取消訂閱，或者透過request(n)通知生產下N個元素，這個過程即背壓。

由於Java天生的語言優勢，很適合使用RxJava或Reactor之類的框架，程式碼邏輯清晰可讀性會非常高。筆者在實作Go版的Reactor時，深深地體會到了沒有泛型支持的API表現力是多麽匱乏，也期待Go2的泛型能夠有所改善。

四 總結

RSocket是個很有趣的網路協定，它可能不會普及流行，但貴在它解決問題的思路和設計很令人耳目一新。如果大家有興趣，可以去它的官網了解下。

本文總結了筆者在實作Go和Rust版RSocket SDK過程中的一些心得感悟，有興趣的同學可檢視相關連結。

相關連結
https:// github.com/jjeffcaii/rs ocket-minibroker
https:// github.com/rsocket/rsoc ket-go
https:// github.com/rsocket/rsoc ket-rust

技術公開課

【HaaS物聯網雲端一體低程式碼開發課程】

由阿裏雲IoT一線技術專家精心打磨，直擊當前物聯網領域學習痛點，由淺入深全方位介紹物聯網基礎知識和網路層基礎知識，幫助開發者建立物聯網感知層、傳輸層、平台層及套用層各層的功能概念，並深入學習如何使用HaaS進行端雲一體開發以及低程式碼開發新模式。

點選這裏，開始學習吧~

版權聲明： 本文內容由阿裏雲實名註冊使用者自發貢獻，版權歸原作者所有，阿裏雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視【阿裏雲開發者社群使用者服務協定】和【阿裏雲開發者社群智慧財產權保護指引】。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。