RSocket雲原生架構下的另外一種通訊協議選擇

寫在前面

奈飛公司在整個微服務架構體系處於行業領先地位，在其內部有一種自研的通訊協議方式，以實現微服務架構下高性能的通訊，他就是RSocket。同時在雲原生概念盛行的今天，一種能夠在service mesh下高性能通訊的組件一樣也是各個企業須要的，因此今天咱們就聊聊RSocket吧。

爲何須要一種新的通訊協議？

在微服務，雲原生架構盛行的今天，各類服務之間，mesh之間須要進行大量的通訊，網絡彷佛成了整個架構棧中的一等公民。

爲減小因網絡的不肯定性而帶來對於整個網絡架構系統的影響，下降請求延遲每每須要進行一系列的可用性設計。

而目前常見的網絡協議，如HTTP的request-response交互方式，很難有效或高效的進行通訊，也很難解決海量請求下對於後端資源有效使用的問題。同時HTTP這種文本協議方式較二進制協議的實現也能夠有效提高性能。

RSocket是什麼？

對RSocket吹了一波，那麼RSocket到底是什麼呢？

官方定義：RSocket是基於reactive stream flow control的雙向，多路，基於消息的，二進制的通訊協議。

RSocket是一種新的七層通訊協議，某種程度能夠認爲是HTTP等其餘協議的替代方案。較HTTP協議來講，其增長了異步，雙向背壓，多路複用，斷線重連，消息驅動等特色。

因爲是Pivatal公司主導的項目，其實現上大量引入了Reactive Stream相關的編程實現。

以前咱們Reactive相關文章說過，響應式規範的興起，目的之一就是爲了解決海量終端設備背景下，服務端接受請求過載，超時宕機等問題，經過響應式編程中的背壓能夠實現這種壓力過載的控制。

交互模式分爲四種：

1. request-response：請求響應式，目前基於http請求的模式都是這種。
2. fire-and-forget：對於那些不關心結果的請求，直接返回。
3. request-stream：一個請求，能夠經過流方式返回屢次結果。
4. channel：服務器能夠主動發多個請求到客戶端，客戶端能夠發多個結果給服務器。

特色：

• 對於請求和響應均可以取消掉，能夠釋放掉一些系統資源。
• 若是數據提供方因爲某種緣由hang住，請求方能夠先斷開，以後有時間以後再來檢查結果。
• 相似於「背壓」的能力，能夠根據本身的性能狀況控制調用方的頻率。

因此其更適合分佈式場景下的通訊。

在RSocket傳輸信息中，請求能夠劃分爲一個個的幀，每一個幀都包含一個幀頭，其中包含：流ID，幀類型，其餘數據。幀頭後是元數據和有效負載（承載用戶數據）。

對於這種幀的流，咱們可使用任何的序列化方式進行處理，好比JSON，Protobuf或avro等。

除了這種在協議文本上下功夫以外，其多路複用模型也是其能夠進行高效通訊的緣由。

在請求中，每一個流都有一個惟一的ID，經過ID能夠區分每一個流，解決了之前HTTP協議下每一個請求獨佔鏈接的問題，解決相應的性能問題。

另外一個優點就是咱們屢次提到的「背壓」，其「背壓」實現上實現了一種「租約機制」，響應者能夠指定請求者在定義的時間範圍內發送多少請求。

在負載均衡角度，RSocket能夠實現客戶端方式的負載均衡，實現方式依賴於LoadBalancedRSocketMono對象，在其中一組可用的RSocket實例中選擇合適的RSocket實例進行訪問。須要訂閱LoadBalancedRSocketMono的onNext方法獲取所有RSocket實例，同時對每一個RSocket信息進行統計，計算每一個實例負載以肯定最佳選擇。

在統計信息選擇上包括：延遲，保持的鏈接數及未處理的請求數。這些運行時數據能夠實時反應出來。

整個流上，經過keep-alive幀按期來回發送，探測鏈接的穩定性，keep-alive幀中還包含令牌，以確認請求者響應者最後的接收位置。

框架的支持

在Java體系下，對於RSocket的實現通常是基於TCP長連接實現的。不一樣於其餘基於TCP協議的長連接的在於RSocket是一系列的協議規範。

在Spring5時代，Reactor和webflux是值得咱們關注的一套技術，Reactor模型並不能提高請求性能，下降延遲，可是能夠提高吞吐加強系統彈性。可是結合了RSocket後，對於http處理性能則如虎添翼。

以前的文章中講過Reactor和WebFlux就不贅述了，RSocket和WebFlux結合的很好，能夠很方便的使用Mono/Flux相關接口。

既然一直在提「背壓」，那麼「背壓」在真實產品體驗上有什麼用呢？

試想一下，咱們在刷朋友圈的時候，常常會遇到卡頓的狀況，這個時候通常是發起的http請求沒有正常獲得響應，通常須要用戶主動重試，這樣就再次發起了一次請求，http自己是無狀態的，每次請求服務器都須要受理並處理。

若是有了基於應用程序協議上的「背壓」實現，能夠必定程度上減小APP上的無效或重複請求，必定程度上提高系統資源利用率。一些超級用戶量產品的通訊工程團隊已經這樣搞了，好比谷歌和FB。

固然國內阿里團隊也將一部分精力投入到對於RSocket應用的普及上了，好比在Dubbo中就嘗試了對RSocket的適配。

說了這麼多，你是否是已經手癢癢了呢？打開SpringBoot2趕忙搞起來吧！