RPC的由來

隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)站應用的規(guī)模不斷擴大，常規(guī)的垂直應用架構(gòu)已無法應對，分布式服務架構(gòu)以及流動計算架構(gòu)勢在必行，亟需一個治理系統(tǒng)確保架構(gòu)有條不紊的演進。

• 單一應用架構(gòu)
• 當網(wǎng)站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節(jié)點和成本。
• 此時，用于簡化增刪改查工作量的 數(shù)據(jù)訪問框架（ORM） 是關鍵。
• 垂直應用架構(gòu)
• 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
• 此時，用于加速前端頁面開發(fā)的 Web框架（MVC） 是關鍵。
• 分布式服務架構(gòu)
• 當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來，作為獨立的服務，逐漸形成穩(wěn)定的服務中心，使前端應用能更快速的響應多變的市場需求。
• 此時，用于提高業(yè)務復用及整合的 分布式服務框架（RPC），提供統(tǒng)一的服務是關鍵。

例如：各個團隊的服務提供方就不要各自實現(xiàn)一套序列化、反序列化、網(wǎng)絡框架、連接池、收發(fā)線程、超時處理、狀態(tài)機等“業(yè)務之外”的重復技術勞動，造成整體的低效。

所以，統(tǒng)一RPC框架來解決提供統(tǒng)一的服務。

以下我將分別從如下四個方面詳解RPC。

RPC的實現(xiàn)原理

也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調(diào)用B服務器上應用提供的函數(shù)/方法，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡來表達調(diào)用的語義和傳達調(diào)用的數(shù)據(jù)。

比如說，A服務器想調(diào)用B服務器上的一個方法：

Employee getEmployeeByName（String fullName）

整個調(diào)用過程，主要經(jīng)歷如下幾個步驟：

1、建立通信

首先要解決通訊的問題：即A機器想要調(diào)用B機器，首先得建立起通信連接。

主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調(diào)用的所有交換的數(shù)據(jù)都在這個連接里傳輸。連接可以是按需連接，調(diào)用結(jié)束后就斷掉，也可以是長連接，多個遠程過程調(diào)用共享同一個連接。

2、服務尋址

要解決尋址的問題，也就是說，A服務器上的應用怎么告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什么。

通常情況下我們需要提供B機器（主機名或IP地址）以及特定的端口，然后指定調(diào)用的方法或者函數(shù)的名稱以及入?yún)⒊鰠⒌刃畔?#xff0c;這樣才能完成服務的一個調(diào)用。

可靠的尋址方式（主要是提供服務的發(fā)現(xiàn)）是RPC的實現(xiàn)基石，比如可以采用redis或者zookeeper來注冊服務等等。

從服務提供者的角度看：當提供者服務啟動時，需要自動向注冊中心注冊服務；

當提供者服務停止時，需要向注冊中心注銷服務；

提供者需要定時向注冊中心發(fā)送心跳，一段時間未收到來自提供者的心跳后，認為提供者已經(jīng)停止服務，從注冊中心上摘取掉對應的服務。

從調(diào)用者的角度看：調(diào)用者啟動時訂閱注冊中心的消息并從注冊中心獲取提供者的地址；

當有提供者上線或者下線時，注冊中心會告知到調(diào)用者；

調(diào)用者下線時，取消訂閱。

3、網(wǎng)絡傳輸

3.1、序列化

當A機器上的應用發(fā)起一個RPC調(diào)用時，調(diào)用方法和其入?yún)⒌刃畔⑿枰ㄟ^底層的網(wǎng)絡協(xié)議如TCP傳輸?shù)紹機器，由于網(wǎng)絡協(xié)議是基于二進制的，所有我們傳輸?shù)膮?shù)數(shù)據(jù)都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網(wǎng)絡中進行傳輸。然后通過尋址操作和網(wǎng)絡傳輸將序列化或者編組之后的二進制數(shù)據(jù)發(fā)送給B機器。

3.2、反序列化

當B機器接收到A機器的應用發(fā)來的請求之后，又需要對接收到的參數(shù)等信息進行反序列化操作（序列化的逆操作），即將二進制信息恢復為內(nèi)存中的表達方式，然后再找到對應的方法（尋址的一部分）進行本地調(diào)用（一般是通過生成代理Proxy去調(diào)用,
通常會有JDK動態(tài)代理、CGLIB動態(tài)代理、Javassist生成字節(jié)碼技術等），之后得到調(diào)用的返回值。

4、服務調(diào)用

B機器進行本地調(diào)用（通過代理Proxy）之后得到了返回值，此時還需要再把返回值發(fā)送回A機器，同樣也需要經(jīng)過序列化操作，然后再經(jīng)過網(wǎng)絡傳輸將二進制數(shù)據(jù)發(fā)送回A機器，而當A機器接收到這些返回值之后，則再次進行反序列化操作，恢復為內(nèi)存中的表達方式，最后再交給A機器上的應用進行相關處理（一般是業(yè)務邏輯處理操作）。

通常，經(jīng)過以上四個步驟之后，一次完整的RPC調(diào)用算是完成了。

PRC架構(gòu)組件

一個基本的RPC架構(gòu)里面應該至少包含以下4個組件：

1、客戶端（Client）:服務調(diào)用方（服務消費者）

2、客戶端存根（Client Stub）:存放服務端地址信息，將客戶端的請求參數(shù)數(shù)據(jù)信息打包成網(wǎng)絡消息，再通過網(wǎng)絡傳輸發(fā)送給服務端

3、服務端存根（Server Stub）:接收客戶端發(fā)送過來的請求消息并進行解包，然后再調(diào)用本地服務進行處理

4、服務端（Server）:服務的真正提供者

RPC調(diào)用過程

1、服務消費者（client客戶端）通過本地調(diào)用的方式調(diào)用服務

2、客戶端存根（client stub）接收到調(diào)用請求后負責將方法、入?yún)⒌刃畔⑿蛄谢?#xff08;組裝）成能夠進行網(wǎng)絡傳輸?shù)南Ⅲw

3、客戶端存根（client stub）找到遠程的服務地址，并且將消息通過網(wǎng)絡發(fā)送給服務端

4、服務端存根（server stub）收到消息后進行解碼（反序列化操作）

5、服務端存根（server stub）根據(jù)解碼結(jié)果調(diào)用本地的服務進行相關處理

6、本地服務執(zhí)行具體業(yè)務邏輯并將處理結(jié)果返回給服務端存根（server stub）

7、服務端存根（server stub）將返回結(jié)果重新打包成消息（序列化）并通過網(wǎng)絡發(fā)送至消費方

8、客戶端存根（client stub）接收到消息，并進行解碼（反序列化）

9、服務消費方得到最終結(jié)果

有哪些主流的RPC框架

具體可以參考阿里P8架構(gòu)師談：主流RPC框架詳解，以及與SOA、SOAP、REST的區(qū)別

你可能也喜歡:

如何從0到1設計一個類Dubbo的RPC框架

深度剖析RPC框架的核心設計

---

總結(jié)

以上是生活随笔為你收集整理的RPC框架的实现原理，及RPC架构组件详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。