一 RSocket的主要特性

首先，RSocket是高效一個(gè)二進(jìn)制的網(wǎng)絡(luò)通訊協(xié)議，能夠滿足很多場景下使用。其次，RSocket是一個(gè)激進(jìn)的響應(yīng)式捍衛(wèi)者，激進(jìn)到連API都跟響應(yīng)式無縫集成。

1 四種通訊模式

即發(fā)即忘FireAndForget

立即發(fā)送一個(gè)請求，無需為這個(gè)請求發(fā)送響應(yīng)報(bào)文。適用于監(jiān)控埋點(diǎn)，日志上報(bào)等，這種場景下無需回執(zhí)，丟失幾個(gè)請求無傷大雅。

??

請求響應(yīng)RequestResponse

請求方發(fā)送一條請求消息，響應(yīng)方收到請求后并返回一條響應(yīng)消息。傳統(tǒng)的HTTP是典型的RequestResponse。

??

流RequestStream

請求方發(fā)送一個(gè)請求報(bào)文，響應(yīng)方發(fā)回N個(gè)響應(yīng)報(bào)文。傳統(tǒng)的MQ是典型的RequestStream。

??

通道RequestChannel

創(chuàng)建一個(gè)通道上下文，雙方可以互相發(fā)送消息。IM是個(gè)典型的RequestChannel通訊場景。

??

2 雙向通訊Bi-Directional

RSocket的Client連接到Server，這個(gè)過程稱為Setup，在連接成功后，會約定收發(fā)消息的方向邏輯：

• 當(dāng)Client請求Server時(shí)，發(fā)送的請求ID永遠(yuǎn)為奇數(shù)
• 當(dāng)Server請求Client時(shí)，發(fā)送的請求ID永遠(yuǎn)為偶數(shù)

??

正是因?yàn)檫@個(gè)奇偶性確定方向的特性，不同于傳統(tǒng)的如HTTP請求，RSocket可以做到雙向請求。

3 其他

• 二進(jìn)制協(xié)議，緊湊高效
• 多路復(fù)用
• 基于幀(Frame)的背壓，與ReactiveStreams語義契合
• 靈活的傳輸層切換: TCP/UDP/WebSocket等
• 支持Cancel、斷點(diǎn)續(xù)傳、租約等高級特性

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

??

二 RSocket的內(nèi)部實(shí)現(xiàn)

1 幀的設(shè)計(jì)

幀(Frame)是RSocket協(xié)議報(bào)文的最小單位。

• 一個(gè)幀由6 bytes的Header和剩余的Body構(gòu)成，其中Header的4 bytes表示 StreamID，6 bits表示Frame Type, 10 bits作為Flags。Body根據(jù)不同的幀類型，結(jié)構(gòu)也不同，常用的帶Payload的幀一般會包括Metadata和Data兩個(gè)部分。
• 傳輸層如果本身不支持分幀特性的(如TCP)，那么RSocket會用3 bytes的uint24表示幀長度，所以最大的幀大小是16MB。
• 如果幀超出16MB，RSocket支持幀分裂重組，也就是拆成更小的幀，接收端再自動重組。

??

2 數(shù)據(jù)載體——Payload

基于幀之上，一般開發(fā)者接觸到的是Payload, 它類似一個(gè)HTTP報(bào)文，可以是一個(gè)Request，也可以是一個(gè)Response。由兩個(gè)二進(jìn)制部分組成：

• Metadata——元數(shù)據(jù)，類似HTTP的header
• Data——數(shù)據(jù)，類似HTTP的body

??

3 架構(gòu)

這里基于筆者在實(shí)現(xiàn)Golang版SDK的基礎(chǔ)上整理的架構(gòu)圖，Java版基本也類似。

??

• Transport層將網(wǎng)絡(luò)二進(jìn)制流編解碼為Frames。
• RSocket支持自定義最大Frame Size，默認(rèn)16MB，當(dāng)某個(gè)Frame超出時(shí)，會被拆解為N個(gè)小Frame，收到時(shí)再重組，在介紹幀的時(shí)候也提到了，這個(gè)特性稱為Fragmentation。
• DuplexConnection轉(zhuǎn)換Frames為Payload，抽象為一個(gè)個(gè)Request/Response上下文，并負(fù)責(zé)讀寫。
• RSocket組裝Connection為RSocket Interface，其中Resumable支持?jǐn)帱c(diǎn)續(xù)傳，連接斷開重連也能自愈，個(gè)人覺得這個(gè)特性有點(diǎn)雞肋，在弱網(wǎng)環(huán)境有些優(yōu)勢，但是因?yàn)槠陂g會緩存住未處理完畢的幀，所以會耗費(fèi)大量的系統(tǒng)資源。
• RSocket使用Reactor核心庫暴露為4種通訊模式，抽象為高級API。

4 玩法

RSocket有很多玩法，傳統(tǒng)的RPC自然不在話下，用來做IM也未嘗不可，某些特性也可以用來做代理或者網(wǎng)絡(luò)穿透。

IoT的場景，比如小明的家里有個(gè)智能空調(diào)，小明想在外面通過手機(jī)APP來控制空調(diào)開關(guān)，如何優(yōu)雅地描述這個(gè)控制問題?最精煉的解決方案就是"小明調(diào)用空調(diào)上開關(guān)的API"。

??

另外最經(jīng)典的玩法就是Broker了，Broker類似一種“軟路由”的方案，可以讓服務(wù)的發(fā)布訪問變得簡單。發(fā)布服務(wù)只要連接到Broker，調(diào)用方通過反向請求的方式來讓Broker透明轉(zhuǎn)發(fā)即可，摒棄了傳統(tǒng)的注冊中心，端口管理等常見的服務(wù)治理手段。

??

5 關(guān)于RSocket Broker

Broker有很多優(yōu)勢，發(fā)布服務(wù)不需要監(jiān)聽端口，無需Sidecar，服務(wù)注冊變得簡單，無需zk、etcd之類，LoadBalance變得簡單，也更安全，沒監(jiān)聽端口后很難攻擊。也有很多劣勢，網(wǎng)絡(luò)上多了一跳，性能是有一定損耗的，Broker是中心化設(shè)計(jì)，類似我們平時(shí)全局的Nginx一樣，但是Broker的優(yōu)雅啟停顯然更加復(fù)雜，受限于整個(gè)Broker集群的瓶頸等等。上帝為你關(guān)閉了一扇門，就一定會為你打開一扇窗。

目前高德落地的FaaS中大量使用了基于RSocket架構(gòu)的集團(tuán)Broker，支撐了今年的五一長假，峰值QPS超20萬，平穩(wěn)零故障。

??

這里筆者也準(zhǔn)備了一個(gè)教學(xué)用的Mini Broker，演示了兩個(gè)瀏覽器之間相互上下文調(diào)用彼此服務(wù)的場景，有興趣的同學(xué)可以查看。

??

三 響應(yīng)式編程

響應(yīng)式編程是個(gè)老話題了，它早已無處不在，甚至你在Excel里SUM求和，本質(zhì)上也是種響應(yīng)式的思維。響應(yīng)式本質(zhì)上就是響應(yīng)變化的數(shù)據(jù)流。RSocket這個(gè)協(xié)議本身就是以響應(yīng)式之名，將其擴(kuò)展到網(wǎng)絡(luò)層面。

1 響應(yīng)式編程大概長這樣

??

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

??

2 Reactive Streams

JDK推出了響應(yīng)式標(biāo)準(zhǔn)API，撇開Processor之外，其核心接口就Publisher/Subscriber/Subscription，非常精煉。

• Publisher：發(fā)布者，負(fù)責(zé)生產(chǎn)數(shù)據(jù)。唯一的方法subscribe，接收一個(gè)Subscriber開始一次新的訂閱。
• Subscriber：訂閱者，負(fù)責(zé)訂閱消費(fèi)數(shù)據(jù)。
• Subscription：訂閱，某次訂閱的上下文控制，如取消、通知獲取下N條數(shù)據(jù)。

Spring的Reactor是一個(gè)標(biāo)準(zhǔn)的實(shí)現(xiàn)，其一次完整的執(zhí)行過程如下圖：

??

• 創(chuàng)建subscriber，開始訂閱Publisher。
• 生成上下文subscription。
• Publisher就緒，調(diào)用onSubscribe。
• Publisher開始生產(chǎn)數(shù)據(jù)。
• 每條成功生產(chǎn)的數(shù)據(jù)回調(diào)onNext。
• 當(dāng)生產(chǎn)失敗時(shí)，回調(diào)onError并結(jié)束當(dāng)前訂閱。
• 當(dāng)所有數(shù)據(jù)生產(chǎn)完畢時(shí)，回調(diào)onComplete并結(jié)束當(dāng)前訂閱。
• 中途可以調(diào)用subscription隨時(shí)cancel取消訂閱，或者通過request(n)通知生產(chǎn)下N個(gè)元素，這個(gè)過程即背壓。

由于Java天生的語言優(yōu)勢，很適合使用RxJava或Reactor之類的框架，代碼邏輯清晰可讀性會非常高。筆者在實(shí)現(xiàn)Go版的Reactor時(shí)，深深地體會到了沒有泛型支持的API表現(xiàn)力是多么匱乏，也期待Go2的泛型能夠有所改善。

四 總結(jié)

RSocket是個(gè)很有趣的網(wǎng)絡(luò)協(xié)議，它可能不會普及流行，但貴在它解決問題的思路和設(shè)計(jì)很令人耳目一新。如果大家有興趣，可以去它的官網(wǎng)了解下。

本文總結(jié)了筆者在實(shí)現(xiàn)Go和Rust版RSocket SDK過程中的一些心得感悟，有興趣的同學(xué)可查看相關(guān)鏈接。