作者 | 素渡
來源 | 阿裡技術公衆号
一 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/rsocket-minibroker https://github.com/rsocket/rsocket-go https://github.com/rsocket/rsocket-rust
技術公開課
《HaaS物聯網雲端一體低代碼開發課程》
由阿裡雲IoT一線技術專家精心打磨，直擊目前物聯網領域學習痛點，由淺入深全方位介紹物聯網基礎知識和網絡層基礎知識，幫助開發者建立物聯網感覺層、傳輸層、平台層及應用層各層的功能概念，并深入學習如何使用HaaS進行端雲一體開發以及低代碼開發新模式。
點選這裡，開始學習吧~