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

創(chuàng)新互聯(lián)服務(wù)項目包括金牛網(wǎng)站建設(shè)、金牛網(wǎng)站制作、金牛網(wǎng)頁制作以及金牛網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,金牛網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到金牛省份的部分城市,未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
1 四種通訊模式
即發(fā)即忘FireAndForget
立即發(fā)送一個請求,無需為這個請求發(fā)送響應(yīng)報文。適用于監(jiān)控埋點,日志上報等,這種場景下無需回執(zhí),丟失幾個請求無傷大雅。
??
??
請求響應(yīng)RequestResponse
請求方發(fā)送一條請求消息,響應(yīng)方收到請求后并返回一條響應(yīng)消息。傳統(tǒng)的HTTP是典型的RequestResponse。
??
??
流RequestStream
請求方發(fā)送一個請求報文,響應(yīng)方發(fā)回N個響應(yīng)報文。傳統(tǒng)的MQ是典型的RequestStream。
??
??
通道RequestChannel
創(chuàng)建一個通道上下文,雙方可以互相發(fā)送消息。IM是個典型的RequestChannel通訊場景。
??
??
2 雙向通訊Bi-Directional
RSocket的Client連接到Server,這個過程稱為Setup,在連接成功后,會約定收發(fā)消息的方向邏輯:
- 當Client請求Server時,發(fā)送的請求ID永遠為奇數(shù)
- 當Server請求Client時,發(fā)送的請求ID永遠為偶數(shù)
??
??
正是因為這個奇偶性確定方向的特性,不同于傳統(tǒng)的如HTTP請求,RSocket可以做到雙向請求。
3 其他
- 二進制協(xié)議,緊湊高效
- 多路復(fù)用
- 基于幀(Frame)的背壓,與ReactiveStreams語義契合
- 靈活的傳輸層切換: TCP/UDP/WebSocket等
- 支持Cancel、斷點續(xù)傳、租約等高級特性
綜上與HTTP做一些比較,RSocket的效率更高,支持的通訊場景更豐富,也沒有隊頭阻塞的問題。與SocketIO這種基于純事件的框架相比,RSocket的請求具有很清晰的上下文,API精煉易用。
??
??
二 RSocket的內(nèi)部實現(xiàn)
1 幀的設(shè)計
幀(Frame)是RSocket協(xié)議報文的最小單位。
- 一個幀由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兩個部分。
- 傳輸層如果本身不支持分幀特性的(如TCP),那么RSocket會用3 bytes的uint24表示幀長度,所以最大的幀大小是16MB。
- 如果幀超出16MB,RSocket支持幀分裂重組,也就是拆成更小的幀,接收端再自動重組。
??
??
2 數(shù)據(jù)載體——Payload
基于幀之上,一般開發(fā)者接觸到的是Payload, 它類似一個HTTP報文,可以是一個Request,也可以是一個Response。由兩個二進制部分組成:
- Metadata——元數(shù)據(jù),類似HTTP的header
- Data——數(shù)據(jù),類似HTTP的body
??
??
3 架構(gòu)
這里基于筆者在實現(xiàn)Golang版SDK的基礎(chǔ)上整理的架構(gòu)圖,Java版基本也類似。
??
??
- Transport層將網(wǎng)絡(luò)二進制流編解碼為Frames。
- RSocket支持自定義最大Frame Size,默認16MB,當某個Frame超出時,會被拆解為N個小Frame,收到時再重組,在介紹幀的時候也提到了,這個特性稱為Fragmentation。
- DuplexConnection轉(zhuǎn)換Frames為Payload,抽象為一個個Request/Response上下文,并負責讀寫。
- RSocket組裝Connection為RSocket Interface,其中Resumable支持斷點續(xù)傳,連接斷開重連也能自愈,個人覺得這個特性有點雞肋,在弱網(wǎng)環(huán)境有些優(yōu)勢,但是因為期間會緩存住未處理完畢的幀,所以會耗費大量的系統(tǒng)資源。
- RSocket使用Reactor核心庫暴露為4種通訊模式,抽象為高級API。
4 玩法
RSocket有很多玩法,傳統(tǒng)的RPC自然不在話下,用來做IM也未嘗不可,某些特性也可以用來做代理或者網(wǎng)絡(luò)穿透。
IoT的場景,比如小明的家里有個智能空調(diào),小明想在外面通過手機APP來控制空調(diào)開關(guān),如何優(yōu)雅地描述這個控制問題?最精煉的解決方案就是"小明調(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è)計,類似我們平時全局的Nginx一樣,但是Broker的優(yōu)雅啟停顯然更加復(fù)雜,受限于整個Broker集群的瓶頸等等。上帝為你關(guān)閉了一扇門,就一定會為你打開一扇窗。
目前高德落地的FaaS中大量使用了基于RSocket架構(gòu)的集團Broker,支撐了今年的五一長假,峰值QPS超20萬,平穩(wěn)零故障。
??
??
這里筆者也準備了一個教學(xué)用的Mini Broker,演示了兩個瀏覽器之間相互上下文調(diào)用彼此服務(wù)的場景,有興趣的同學(xué)可以查看。
??
??
三 響應(yīng)式編程
響應(yīng)式編程是個老話題了,它早已無處不在,甚至你在Excel里SUM求和,本質(zhì)上也是種響應(yīng)式的思維。響應(yīng)式本質(zhì)上就是響應(yīng)變化的數(shù)據(jù)流。RSocket這個協(xié)議本身就是以響應(yīng)式之名,將其擴展到網(wǎng)絡(luò)層面。
1 響應(yīng)式編程大概長這樣
??
??
而在我們平時工作中,必然會引入各種操作和變換:
??
??
2 Reactive Streams
JDK推出了響應(yīng)式標準API,撇開Processor之外,其核心接口就Publisher/Subscriber/Subscription,非常精煉。
- Publisher:發(fā)布者,負責生產(chǎn)數(shù)據(jù)。唯一的方法subscribe,接收一個Subscriber開始一次新的訂閱。
- Subscriber:訂閱者,負責訂閱消費數(shù)據(jù)。
- Subscription:訂閱,某次訂閱的上下文控制,如取消、通知獲取下N條數(shù)據(jù)。
Spring的Reactor是一個標準的實現(xiàn),其一次完整的執(zhí)行過程如下圖:
??
??
- 創(chuàng)建subscriber,開始訂閱Publisher。
- 生成上下文subscription。
- Publisher就緒,調(diào)用onSubscribe。
- Publisher開始生產(chǎn)數(shù)據(jù)。
- 每條成功生產(chǎn)的數(shù)據(jù)回調(diào)onNext。
- 當生產(chǎn)失敗時,回調(diào)onError并結(jié)束當前訂閱。
- 當所有數(shù)據(jù)生產(chǎn)完畢時,回調(diào)onComplete并結(jié)束當前訂閱。
- 中途可以調(diào)用subscription隨時cancel取消訂閱,或者通過request(n)通知生產(chǎn)下N個元素,這個過程即背壓。
由于Java天生的語言優(yōu)勢,很適合使用RxJava或Reactor之類的框架,代碼邏輯清晰可讀性會非常高。筆者在實現(xiàn)Go版的Reactor時,深深地體會到了沒有泛型支持的API表現(xiàn)力是多么匱乏,也期待Go2的泛型能夠有所改善。
四 總結(jié)
RSocket是個很有趣的網(wǎng)絡(luò)協(xié)議,它可能不會普及流行,但貴在它解決問題的思路和設(shè)計很令人耳目一新。如果大家有興趣,可以去它的官網(wǎng)了解下。
本文總結(jié)了筆者在實現(xiàn)Go和Rust版RSocket SDK過程中的一些心得感悟,有興趣的同學(xué)可查看相關(guān)鏈接。
分享文章:淺談RSocket與響應(yīng)式編程
網(wǎng)頁地址:http://m.fisionsoft.com.cn/article/dhpsips.html


咨詢
建站咨詢
