一 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過程中的一些心得感悟,有興趣的同學可檢視相關連結。
技術公開課
《HaaS物聯網雲端一體低程式碼開發課程》
由阿里雲IoT一線技術專家精心打磨,直擊當前物聯網領域學習痛點,由淺入深全方位介紹物聯網基礎知識和網路層基礎知識,幫助開發者建立物聯網感知層、傳輸層、平臺層及應用層各層的功能概念,並深入學習如何使用HaaS進行端雲一體開發以及低程式碼開發新模式。