RPC的由來
隨着互聯網的發展,網站應用的規模不斷擴大,常規的垂直應用架構已無法應對,分布式服務架構以及流動計算架構勢在必行,亟需一個治理系統確保架構有條不紊的演進。
- 單一應用架構
- 當網站流量很小時,只需一個應用,將所有功能都部署在一起,以減少部署節點和成本。
- 此時,用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
- 垂直應用架構
- 當訪問量逐漸增大,單一應用增加機器帶來的加速度越來越小,將應用拆成互不相干的幾個應用,以提升效率。
- 此時,用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
- 分布式服務架構
- 當垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來,作為獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速的響應多變的市場需求。
- 此時,用於提高業務復用及整合的 分布式服務框架(RPC),提供統一的服務是關鍵。
例如:各個團隊的服務提供方就不要各自實現一套序列化、反序列化、網絡框架、連接池、收發線程、超時處理、狀態機等“業務之外”的重復技術勞動,造成整體的低效。
所以,統一RPC框架來解決提供統一的服務。
以下我將分別從如下四個方面詳解RPC。

RPC的實現原理

也就是說兩台服務器A,B,一個應用部署在A服務器上,想要調用B服務器上應用提供的函數/方法,由於不在一個內存空間,不能直接調用,需要通過網絡來表達調用的語義和傳達調用的數據。
比如說,A服務器想調用B服務器上的一個方法:
Employee getEmployeeByName(String fullName)
整個調用過程,主要經歷如下幾個步驟:
1、建立通信
首先要解決通訊的問題:即A機器想要調用B機器,首先得建立起通信連接。
主要是通過在客戶端和服務器之間建立TCP連接,遠程過程調用的所有交換的數據都在這個連接里傳輸。連接可以是按需連接,調用結束后就斷掉,也可以是長連接,多個遠程過程調用共享同一個連接。
2、服務尋址
要解決尋址的問題,也就是說,A服務器上的應用怎么告訴底層的RPC框架,如何連接到B服務器(如主機或IP地址)以及特定的端口,方法的名稱名稱是什么。
通常情況下我們需要提供B機器(主機名或IP地址)以及特定的端口,然后指定調用的方法或者函數的名稱以及入參出參等信息,這樣才能完成服務的一個調用。
可靠的尋址方式(主要是提供服務的發現)是RPC的實現基石,比如可以采用redis或者zookeeper來注冊服務等等。

- 從服務提供者的角度看:當提供者服務啟動時,需要自動向注冊中心注冊服務;
- 當提供者服務停止時,需要向注冊中心注銷服務;
- 提供者需要定時向注冊中心發送心跳,一段時間未收到來自提供者的心跳后,認為提供者已經停止服務,從注冊中心上摘取掉對應的服務。
- 從調用者的角度看:調用者啟動時訂閱注冊中心的消息並從注冊中心獲取提供者的地址;
- 當有提供者上線或者下線時,注冊中心會告知到調用者;
- 調用者下線時,取消訂閱。
3、網絡傳輸
3.1、序列化
當A機器上的應用發起一個RPC調用時,調用方法和其入參等信息需要通過底層的網絡協議如TCP傳輸到B機器,由於網絡協議是基於二進制的,所有我們傳輸的參數數據都需要先進行序列化(Serialize)或者編組(marshal)成二進制的形式才能在網絡中進行傳輸。然后通過尋址操作和網絡傳輸將序列化或者編組之后的二進制數據發送給B機器。
3.2、反序列化
當B機器接收到A機器的應用發來的請求之后,又需要對接收到的參數等信息進行反序列化操作(序列化的逆操作),即將二進制信息恢復為內存中的表達方式,然后再找到對應的方法(尋址的一部分)進行本地調用(一般是通過生成代理Proxy去調用,
通常會有JDK動態代理、CGLIB動態代理、Javassist生成字節碼技術等),之后得到調用的返回值。
4、服務調用
B機器進行本地調用(通過代理Proxy)之后得到了返回值,此時還需要再把返回值發送回A機器,同樣也需要經過序列化操作,然后再經過網絡傳輸將二進制數據發送回A機器,而當A機器接收到這些返回值之后,則再次進行反序列化操作,恢復為內存中的表達方式,最后再交給A機器上的應用進行相關處理(一般是業務邏輯處理操作)。
通常,經過以上四個步驟之后,一次完整的RPC調用算是完成了。
PRC架構組件
一個基本的RPC架構里面應該至少包含以下4個組件:
1、客戶端(Client):服務調用方(服務消費者)
2、客戶端存根(Client Stub):存放服務端地址信息,將客戶端的請求參數數據信息打包成網絡消息,再通過網絡傳輸發送給服務端
3、服務端存根(Server Stub):接收客戶端發送過來的請求消息並進行解包,然后再調用本地服務進行處理
4、服務端(Server):服務的真正提供者
RPC調用過程

1、服務消費者(client客戶端)通過本地調用的方式調用服務
2、客戶端存根(client stub)接收到調用請求后負責將方法、入參等信息序列化(組裝)成能夠進行網絡傳輸的消息體
3、客戶端存根(client stub)找到遠程的服務地址,並且將消息通過網絡發送給服務端
4、服務端存根(server stub)收到消息后進行解碼(反序列化操作)
5、服務端存根(server stub)根據解碼結果調用本地的服務進行相關處理
6、本地服務執行具體業務邏輯並將處理結果返回給服務端存根(server stub)
7、服務端存根(server stub)將返回結果重新打包成消息(序列化)並通過網絡發送至消費方
8、客戶端存根(client stub)接收到消息,並進行解碼(反序列化)
9、服務消費方得到最終結果
什么是RPC
RPC(Remote Procedure Call Protocol)——遠程過程調用協議,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議。
簡言之,RPC使得程序能夠像訪問本地系統資源一樣,去訪問遠端系統資源。
- 比較關鍵的一些方面包括:
- 通訊協議
- 序列化
- 資源(接口)描述
- 服務框架
- 性能
- 語言支持等。
REST 和 SOAP、RPC的區別

1.REST
可以看着是http協議的一種直接應用,默認基於json作為傳輸格式,使用簡單,學習成本低效率高,但是安全性較低。
2.SOAP
SOAP是一種數據交換協議規范,是一種輕量的、簡單的、基於XML的協議的規范。而SOAP可以看着是一個重量級的協議,基於xml,SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規范組成了WS-Security來實現安全控制的,當前已經得到了各個廠商的支持 。
它有什么優點?簡單總結為: 易用,靈活,跨語言,跨平台。
3.RPC(遠程過程調用)是什么?
簡單的說,RPC就是從一台機器(客戶端)上通過參數傳遞的方式調用另一台機器(服務器)上的一個函數或方法(可以統稱為服務)並得到返回的結果。
REST 和 SOAP、RPC 有何區別呢?沒什么太大區別,他們的本質都是提供可支持分布式的基礎服務,最大的區別在於他們各自的的特點所帶來的不同應用場景 。
RPC工作原理
運行時,一次客戶機對服務器的RPC調用,其內部操作大致有如下十步:
1.調用客戶端句柄;執行傳送參數
2.調用本地系統內核發送網絡消息
3.消息傳送到遠程主機
4.服務器句柄得到消息並取得參數
5.執行遠程過程
6.執行的過程將結果返回服務器句柄
7.服務器句柄返回結果,調用遠程系統內核
8.消息傳回本地主機
9.客戶句柄由內核接收消息
10.客戶接收句柄返回的數據
主流RPC框架
簡單介紹其中幾種比較典型的:

1.Hessian
是一個輕量級的remoting onhttp工具,使用簡單的方法提供了RMI的功能。 基於HTTP協議,采用二進制編解碼。
2.protobuf-rpc-pro
是一個Java類庫,提供了基於 Google 的 Protocol Buffers 協議的遠程方法調用的框架。基於 Netty 底層的 NIO 技術。支持 TCP 重用/ keep-alive、SSL加密、RPC 調用取消操作、嵌入式日志等功能。
3.Thrift
是一種可伸縮的跨語言服務的軟件框架。它擁有功能強大的代碼生成引擎,無縫地支持C + +,C#,Java,Python和PHP和Ruby。thrift允許你定義一個描述文件,描述數據類型和服務接口。依據該文件,編譯器方便地生成RPC客戶端和服務器通信代碼。
最初由facebook開發用做系統內個語言之間的RPC通信,2007年由facebook貢獻到apache基金 ,現在是apache下的opensource之一 。支持多種語言之間的RPC方式的通信:php語言client可以構造一個對象,調用相應的服務方法來調用java語言的服務,跨越語言的C/S RPC調用。底層通訊基於SOCKET。
4.Avro
出自Hadoop之父Doug Cutting, 在Thrift已經相當流行的情況下推出Avro的目標不僅是提供一套類似Thrift的通訊中間件,更是要建立一個新的,標准性的雲計算的數據交換和存儲的Protocol。支持HTTP,TCP兩種協議。
5.Dubbo
Dubbo是 阿里巴巴公司開源的一個高性能優秀的服務框架,使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能,可以和 Spring框架無縫集成。
簡單的使用方法:
1、被遠程調用的接口,需要在zookeeper中進行注冊;
2、需要遠程調用的服務在zookeeper中聲明自己需要的接口;
3、zookeeper將已經注冊的接口通知給需要的服務;
詳解RPC遠程調用和消息隊列MQ的區別
什么是RPC
RPC(Remote Procedure Call)遠程過程調用,主要解決遠程通信間的問題,不需要了解底層網絡的通信機制。
RPC服務框架有哪些
知名度較高的有Thrift(FB的)、Dubbo(阿里的)、grpc(google)等

RPC的一般需要經歷4個步驟:
1、建立通信
首先要解決通訊的問題:即A機器想要調用B機器,首先得建立起通信連接,主要是通過在客戶端和服務器之間建立TCP連接。
2、服務尋址
要解決尋址的問題,A服務器上如何連接到B服務器(如主機或IP地址)以及特定的端口,方法的名稱是什么。
3、網絡傳輸
1)序列化
當A服務器上的應用發起一個RPC調用時,調用方法和參數數據都需要先進行序列化。
2)反序列化
當B服務器接收到A服務器的請求之后,又需要對接收到的參數等信息進行反序列化操作。
4、服務調用
B服務器進行本地調用(通過代理Proxy)之后得到了返回值,此時還需要再把返回值發送回A服務器,同樣也需要經過序列化操作,然后再經過網絡傳輸將二進制數據發送回A服務器。
通常,一次完整的PRC調用需要經歷如上4個步驟。
更加詳細RPC 通信流程深入的視頻講解,點擊查看RPC通信核心流程剖析,大廠面試必看!
MQ(消息隊列)
消息隊列(MQ)是一種能實現生產者到消費者單向通信的通信模型,一般來說是指實現這個模型的中間件。
MQ消息中間件比較:
RocketMQ、Kafka、RabbitMQ的架構設計與選型
典型的特點:
1、解耦
2、可靠投遞
3、廣播
4、最終一致性
5、流量削峰
6、消息投遞保證
7、異步通信(支持同步)
8、提高系統吞吐、健壯性
典型的使用場景:秒殺業務中利用MQ來實現流量削峰,以及應用解耦使用。
RPC和MQ的區別和關聯
1.在架構上,RPC和MQ的差異點是,Message有一個中間結點Message Queue,可以把消息存儲。

2.同步調用:對於要立即等待返回處理結果的場景,RPC是首選。
3.MQ 的使用,一方面是基於性能的考慮,比如服務端不能快速的響應客戶端(或客戶端也不要求實時響應),需要在隊列里緩存。
另外一方面,它更側重數據的傳輸,因此方式更加多樣化,除了點對點外,還有訂閱發布等功能。
4.而且隨着業務增長,有的處理端處理量會成為瓶頸,會進行同步調用改造為異步調用,這個時候可以考慮使用MQ。