默認
打賞 發表評論 0
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途
閱讀(1107) | 評論(0 收藏1 淘帖 1

本文引用了作者“李金葵”的“花了一個星期,我終于把RPC框架整明白了!”一文部分內容,感謝作者的無私分享。


1、引言


RPC對于分布式系統來說,是一項非常有價值的技術。

就拿IM系統來說,單實例情況下自然沒RPC什么事,最多用用MQ消息中間件就能很好的發揮系統效力。但一旦IM用戶規模越來越大,單實例絡究有出現拼頸的那一天,那么自然而然就要走到IM集群這一步了。

說到IM集群,好像看起來很簡單,很多Web后端出身的程序員可能脫口而出——用Nginx解決不就行了?顯然不是那么回事,如果你也有這種想法,那么請讀一讀《即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?》后,再來討論。

當然,真正要做到可投入到生產級別的IM集群系統,難度還是相當大的,必竟IM這種長連接應用相比傳統Http這種短連接應用太不標準,因而現成可用的技術太少,多數時候只能自已造輪子。以一個典型的IM聊天消息傳輸為例,假設存在兩個正在聊天的用戶(用戶A和用戶B),當A連接的是IM集群中的IM實例1、B連接的是IM集群中的IM實例2,此時當用戶A向用戶B發送一條聊天消息時,這條消息應該如何傳遞呢?

我們梳理一下這個過程:

  • 1)消息首先會由用戶A發往IM實例1;
  • 2)IM實例1會將此條消息轉交給IM實例2;
  • 3)IM實例2會將此條消息最終投遞給連接在本實例上的用戶B。

以上,就是一個IM集群中,一條聊天消息的典型投遞流程。

那么,這其中涉及到一個關鍵步驟:即第2)步中如何實現“IM實例1會將此條消息轉交給IM實例2”?

要解決這個問題,就需要用到RPC技術了。本文將帶你從基本概念、原理和用途方面,快速理解快速理解RPC技術,以便您在進行IM集群開發時能更好的進行方案設計和實現。

2、相關文章



3、基本概念


RPC(Remote Procedure Call):遠程過程調用,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的思想。

RPC 是一種技術思想而非一種具體的規范或協議。

常見 RPC 技術和框架有:

  • 1)應用級的服務框架:阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
  • 2)遠程通信協議:RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
  • 3)通信框架:MINA 和 Netty。

目前流行的開源 RPC 框架還是比較多的,有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

下面重點介紹當前最流行的三種:

  • 1)gRPC是 Google 公布的開源軟件,基于最新的 HTTP 2.0 協議,并支持常見的眾多編程語言。RPC 框架是基于 HTTP 協議實現的,底層使用到了 Netty 框架的支持;
  • 2)Thrift是 Facebook 的開源 RPC 框架,主要是一個跨語言的服務開發框架。用戶只要在其之上進行二次開發就行,應用對于底層的 RPC 通訊等都是透明的。不過這個對于用戶來說需要學習特定領域語言這個特性,還是有一定成本的;
  • 3)Dubbo是阿里集團開源的一個極為出名的 RPC 框架,在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是極其鮮明的特色。

4、典型的 RPC 框架


在一個典型 RPC 的使用場景中,包含了服務發現、負載、容錯、網絡傳輸、序列化等組件,其中“RPC 協議”就指明了程序如何進行網絡傳輸和序列化。

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_1.jpg
▲ 一個典型的 RPC 架構原理圖

如下是 Dubbo 的設計架構圖,分層清晰,功能復雜:
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_2.jpg
▲ Dubbo 架構圖

5、RPC的核心功能


RPC 的核心功能是指實現一個 RPC 最重要的功能模塊,就是上圖中的”RPC 協議”部分:

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_3.jpg
▲ RPC 核心功能

一個 RPC 的核心功能主要有 5 個部分組成,分別是:客戶端、客戶端 Stub、網絡傳輸模塊、服務端 Stub、服務端等。

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_4.jpg
▲ RPC 核心功能原理圖

下面分別介紹核心 RPC 框架的重要組成:

  • 1)客戶端(Client):服務調用方;
  • 2)客戶端存根(Client Stub):存放服務端地址信息,將客戶端的請求參數數據信息打包成網絡消息,再通過網絡傳輸發送給服務端;
  • 3)服務端存根(Server Stub):接收客戶端發送過來的請求消息并進行解包,然后再調用本地服務進行處理;
  • 4)服務端(Server):服務的真正提供者;
  • 5)Network Service:底層傳輸,可以是 TCP 或 HTTP。

我們用一個demo實例來講解這個調用過程。

Demo實例中,客戶端和服務端的ip地址如下:

客戶端 IP:172.171.4.176
服務端 IP:172.171.5.95


通信使用 HTTP 協議,XML 文件傳輸格式。傳輸的字段包括:方法名 methodName,兩個參數 2,3:
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_5.jpg
▲ Request 抓包

服務端返回結果,字段返回值 Value,結果是 5:
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_6.jpg
▲ Response 抓包

在這兩次網絡傳輸中使用了 HTTP 協議,建立 HTTP 協議之間有 TCP 三次握手,斷開 HTTP 協議時有 TCP 四次揮手:
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_7.png
▲ 基于 HTTP 協議的 RPC 連接過程

Demo實例詳細調用過程,我們來一起看看。

Demo 實現的實現過程,流程和分工角色可以用下圖來表示:
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_8.jpg
▲ RPC 調用詳細流程圖

針對Demo實例,我們可以知道一次典型的 RPC 調用流程如下:

  • 1)服務消費者(Client 客戶端)通過本地調用的方式調用服務;
  • 2)客戶端存根(Client Stub)接收到調用請求后負責將方法、入參等信息序列化(組裝)成能夠進行網絡傳輸的消息體;
  • 3)客戶端存根(Client Stub)找到遠程的服務地址,并且將消息通過網絡發送給服務端;
  • 4)服務端存根(Server Stub)收到消息后進行解碼(反序列化操作);
  • 5)服務端存根(Server Stub)根據解碼結果調用本地的服務進行相關處理;
  • 6)服務端(Server)本地服務業務處理;
  • 7)處理結果返回給服務端存根(Server Stub);
  • 8)服務端存根(Server Stub)序列化結果;
  • 9)服務端存根(Server Stub)將結果通過網絡發送至消費方;
  • 10)客戶端存根(Client Stub)接收到消息,并進行解碼(反序列化);
  • 11)服務消費方得到最終結果。

5、RPC 核心功能的實現介紹


5.1概述


RPC 的核心功能主要由 5 個模塊組成,如果想要自己實現一個 RPC,最簡單的方式要實現三個技術點。

它們分別是:

  • 1)服務尋址;
  • 2)數據流的序列化和反序列化;
  • 3)網絡傳輸。

5.2服務尋址


服務尋址可以使用 Call ID 映射。在本地調用中,函數體是直接通過函數指針來指定的,但是在遠程調用中,函數指針是不行的,因為兩個進程的地址空間是完全不一樣的。

所以在 RPC 中,所有的函數都必須有自己的一個 ID。這個 ID 在所有進程中都是唯一確定的。

客戶端在做遠程過程調用時,必須附上這個 ID。然后我們還需要在客戶端和服務端分別維護一個函數和Call ID的對應表。

當客戶端需要進行遠程調用時,它就查一下這個表,找出相應的 Call ID,然后把它傳給服務端,服務端也通過查表,來確定客戶端需要調用的函數,然后執行相應函數的代碼。

實現方式:服務注冊中心。

要調用服務,首先你需要一個服務注冊中心去查詢對方服務都有哪些實例。Dubbo 的服務注冊中心是可以配置的,官方推薦使用 Zookeeper。

實現案例:RMI(Remote Method Invocation,遠程方法調用)也就是 RPC 本身的實現方式。

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_9.jpg
▲ RMI 架構圖

Registry(服務發現):借助 JNDI 發布并調用了 RMI 服務。實際上,JNDI 就是一個注冊表,服務端將服務對象放入到注冊表中,客戶端從注冊表中獲取服務對象。

RMI 服務在服務端實現之后需要注冊到 RMI Server 上,然后客戶端從指定的 RMI 地址上 Lookup 服務,調用該服務對應的方法即可完成遠程方法調用。

Registry 是個很重要的功能,當服務端開發完服務之后,要對外暴露,如果沒有服務注冊,則客戶端是無從調用的,即使服務端的服務就在那里。

5.3序列化和反序列化


客戶端怎么把參數值傳給遠程的函數呢?在本地調用中,我們只需要把參數壓到棧里,然后讓函數自己去棧里讀就行。

但是在遠程過程調用時,客戶端跟服務端是不同的進程,不能通過內存來傳遞參數。

這時候就需要客戶端把參數先轉成一個字節流,傳給服務端后,再把字節流轉成自己能讀取的格式。

只有二進制數據才能在網絡中傳輸,序列化和反序列化的定義是:

  • 1)將對象轉換成二進制流的過程叫做序列化;
  • 2)將二進制流轉換成對象的過程叫做反序列化。

這個過程叫序列化和反序列化。

同理,從服務端返回的值也需要序列化反序列化的過程。

5.4網絡傳輸


網絡傳輸:遠程調用往往用在網絡上,客戶端和服務端是通過網絡連接的。

所有的數據都需要通過網絡傳輸,因此就需要有一個網絡傳輸層。網絡傳輸層需要把 Call ID 和序列化后的參數字節流傳給服務端,然后再把序列化后的調用結果傳回客戶端。

只要能完成這兩者的,都可以作為傳輸層使用。因此,它所使用的協議其實是不限的,能完成傳輸就行。

盡管大部分 RPC 框架都使用 TCP 協議,但其實 UDP 也可以,而 gRPC 干脆就用了 HTTP2。

TCP 的連接是最常見的,簡要分析基于 TCP 的連接:通常 TCP 連接可以是按需連接(需要調用的時候就先建立連接,調用結束后就立馬斷掉),也可以是長連接(客戶端和服務器建立起連接之后保持長期持有,不管此時有無數據包的發送,可以配合心跳檢測機制定期檢測建立的連接是否存活有效),多個遠程過程調用共享同一個連接。

所以,要實現一個 RPC 框架,只需要把以下三點實現了就基本完成了:

  • 1)Call ID 映射:可以直接使用函數字符串,也可以使用整數 ID。映射表一般就是一個哈希表;
  • 2)序列化反序列化:可以自己寫,也可以使用 Protobuf 或者 FlatBuffers 之類的;
  • 3)網絡傳輸庫:可以自己寫 Socket,或者用 Asio,ZeroMQ,Netty 之類。

6、RPC 核心之網絡傳輸協議


6.1概述


上一節中說明了要實現一個 RPC,需要選擇網絡傳輸的方式。

即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途_10.jpg
▲ 網絡傳輸

在 RPC 中可選的網絡傳輸方式有多種,可以選擇 TCP 協議、UDP 協議、HTTP 協議。

每一種協議對整體的性能和效率都有不同的影響,如何選擇一個正確的網絡傳輸協議呢?首先要搞明白各種傳輸協議在 RPC 中的工作方式。

6.2基于 TCP 協議的 RPC 調用


由服務的調用方與服務的提供方建立 Socket 連接,并由服務的調用方通過 Socket 將需要調用的接口名稱、方法名稱和參數序列化后傳遞給服務的提供方,服務的提供方反序列化后再利用反射調用相關的方法。

最后將結果返回給服務的調用方,整個基于 TCP 協議的 RPC 調用大致如此。

但是在實例應用中則會進行一系列的封裝,如 RMI 便是在 TCP 協議上傳遞可序列化的 Java 對象。

6.3基于 HTTP 協議的 RPC 調用


該方法更像是訪問網頁一樣,只是它的返回結果更加單一簡單。

其大致流程為:由服務的調用者向服務的提供者發送請求,這種請求的方式可能是 GET、POST、PUT、DELETE 等中的一種,服務的提供者可能會根據不同的請求方式做出不同的處理,或者某個方法只允許某種請求方式。

而調用的具體方法則是根據 URL 進行方法調用,而方法所需要的參數可能是對服務調用方傳輸過去的 XML 數據或者 JSON 數據解析后的結果,最后返回 JOSN 或者 XML 的數據結果。

由于目前有很多開源的 Web 服務器,如 Tomcat,所以其實現起來更加容易,就像做 Web 項目一樣。

6.4兩種方式對比


基于 TCP 的協議實現的 RPC 調用,由于 TCP 協議處于協議棧的下層,能夠更加靈活地對協議字段進行定制,減少網絡開銷,提高性能,實現更大的吞吐量和并發數。

但是需要更多關注底層復雜的細節,實現的代價更高。同時對不同平臺,如安卓,iOS 等,需要重新開發出不同的工具包來進行請求發送和相應解析,工作量大,難以快速響應和滿足用戶需求。

基于 HTTP 協議實現的 RPC 則可以使用 JSON 和 XML 格式的請求或響應數據。

而 JSON 和 XML 作為通用的格式標準(使用 HTTP 協議也需要序列化和反序列化,不過這不是該協議下關心的內容,成熟的 Web 程序已經做好了序列化內容),開源的解析工具已經相當成熟,在其上進行二次開發會非常便捷和簡單。

但是由于 HTTP 協議是上層協議,發送包含同等內容的信息,使用 HTTP 協議傳輸所占用的字節數會比使用 TCP 協議傳輸所占用的字節數更高。

因此在同等網絡下,通過 HTTP 協議傳輸相同內容,效率會比基于 TCP 協議的數據效率要低,信息傳輸所占用的時間也會更長,當然壓縮數據,能夠縮小這一差距。

7、RPC的主要使用場景


RPC 主要用于公司內部的服務調用(準確地說是大型系統內部各模塊、子系統間的調用,而不是提供給外界調用),性能消耗低,傳輸效率高,實現復雜。

相對而言,HTTP 主要用于對外的異構環境,比如:瀏覽器接口調用、App 接口調用、第三方接口調用等。

RPC 的主要使用場景尤其是大型的網站的情況下,內部子系統較多、接口非常多的情況下適合使用 RPC。

RPC 的使用場景一般來說有以下特點:

  • 1)長鏈接:不必每次通信都要像 HTTP 一樣去 3 次握手,減少了網絡開銷;
  • 2)注冊發布機制:RPC 框架一般都有注冊中心,有豐富的監控管理;發布、下線接口、動態擴展等,對調用方來說是無感知、統一化的操作;
  • 3)安全性:沒有暴露資源操作;
  • 4)微服務支持:就是最近流行的服務化架構、服務化治理,RPC 框架是一個強力的支撐。

8、小結一下


RPC(即遠程調用)簡單說就是發送一個請求給遠程機器(一般來說就是分布系統內網中的機器),遠程機器返回一個結果回來的過程。

為什么要這么做?因為單臺服務器的性能遠遠不能滿足現在互聯網這個體量的用戶的需求,就好比你去肯德基點個餐,餐臺的服務員把薯條雞腿漢堡的任務分給不同的人,然后收集起來給你的過程,餐臺服務員就相當于調用遠程服務。

但假如不這么做,點餐員直接做這些事情(又得點餐,又得炸薯條、炸雞腿等等),兩相比較,你就知道遠程調用有什么好處了。

簡單來說就是無法在一個進程內,甚至一個計算機內通過本地調用的方式完成的需求,比如比如不同的系統間的通訊,甚至不同的組織間的通訊。由于計算能力需要橫向擴展,需要在多臺機器組成的集群上部署應用。

當然,RPC有有點也有缺點,只有用在合適的場景,才能發揮它的最大威力。

RPC的主要優點有:

  • 1)提升系統可擴展性;
  • 2)提升系統可維護性和持續交付能力;
  • 3)實現系統高可。

RPC的主要缺點有:

  • 1)一個完善的RPC框架開發難度大、成本高 ;
  • 2)RPC框架調用成功率受限于網絡狀況;
  • 3)調用遠程方法對初學者來說難度大。

附錄:有關IM架構設計的文章


淺談IM系統的架構設計
簡述移動端IM開發的那些坑:架構設計、通信協議和客戶端
一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)
一套原創分布式即時通訊(IM)系統理論架構方案
從零到卓越:京東客服即時通訊系統的技術架構演進歷程
蘑菇街即時通訊/IM服務器開發之架構選擇
騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT
微信后臺基于時間序的海量數據冷熱分級架構設計實踐
微信技術總監談架構:微信之道——大道至簡(演講全文)
如何解讀《微信技術總監談架構:微信之道——大道至簡》
快速裂變:見證微信強大后臺架構從0到1的演進歷程(一)
17年的實踐:騰訊海量產品的技術方法論
移動端IM中大規模群消息的推送如何保證效率、實時性?
現代IM系統中聊天消息的同步和存儲方案探討
IM開發基礎知識補課(二):如何設計大量圖片文件的服務端存儲架構?
IM開發基礎知識補課(三):快速理解服務端數據庫讀寫分離原理及實踐建議
IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token
WhatsApp技術實踐分享:32人工程團隊創造的技術神話
微信朋友圈千億訪問量背后的技術挑戰和實踐總結
王者榮耀2億用戶量的背后:產品定位、技術架構、網絡方案等
IM系統的MQ消息中間件選型:Kafka還是RabbitMQ?
騰訊資深架構師干貨總結:一文讀懂大型分布式系統設計的方方面面
以微博類應用場景為例,總結海量社交系統的架構設計步驟
快速理解高性能HTTP服務端的負載均衡技術原理
子彈短信光鮮的背后:網易云信首席架構師分享億級IM平臺的技術實踐
知乎技術分享:從單機到2000萬QPS并發的Redis高性能緩存實踐之路
IM開發基礎知識補課(五):通俗易懂,正確理解并用好MQ消息隊列
微信技術分享:微信的海量IM聊天消息序列號生成實踐(算法原理篇)
微信技術分享:微信的海量IM聊天消息序列號生成實踐(容災方案篇)
新手入門:零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐
一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐
阿里技術分享:深度揭秘阿里數據庫技術方案的10年變遷史
阿里技術分享:阿里自研金融級數據庫OceanBase的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐
社交軟件紅包技術解密(八):全面解密微博紅包技術方案
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?
即時通訊新手入門:快速理解RPC技術——基本概念、原理和用途
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:快速了解Electron:新一代基于Web的跨平臺桌面技術下一篇:多維度對比5款主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了
推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特