原來這就是RPC呀，也沒那么難嘛

發布時間：2023-07-03 12:28:23 作者：網友整理

大家好，歡迎收看猿話！

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

原理

一個完整的RPC主要包括三部分:

服務注冊中心（Registry），負責將本地服務發布成遠程服務，管理遠程服務，提供給服務消費者使用。
服務提供者（RPC Server），負責提供服務接口定義與服務實現類。
服務消費者（RPC Client），負責通過遠程代理對象調用遠程服務。

服務提供者（Server）啟動后主動向服務注冊中心（Registry）注冊機器IP、端口以及提供的服務列表；

服務消費者（Client）啟動時向服務注冊中心（Registry）獲取服務提供方地址列表。

服務注冊中心（Registry）可實現負載均衡和故障切換。

RPC調用過程如下圖所示：

(1) 客戶端（Client）以本地調用方式調用服務；

(2) 客戶端存根（Client stub）接收到調用后，負責將方法、參數等組裝成能夠進行網絡傳輸的消息體（將消息體對象序列化為二進制）；

(3) 客戶端通過 Network Service 將消息發送到服務端；

(4) 服務端存根（Server stub）收到消息后進行解碼（將消息對象反序列化）；

(5) 服務端存根（Server stub）根據解碼結果調用本地的服務；

(6) 本地服務執行并將結果返回給服務端存根（Server stub）；

(7) 服務端存根（Server stub）將返回結果打包成消息（將結果消息對象序列化）；

(8) 服務端（Server）通過 Network Service 將消息發送到客戶端；

(9) 客戶端存根（Client stub）接收到結果消息，并進行解碼（將結果消息發序列化）；

(10) 客戶端（Client）得到最終結果。

RPC 就是要把 2、3、4、7、8、9 這些步驟都封裝起來。

什么情況下使用 RPC ？

RPC一般用于分布式系統中，且通常是內部調用使用。例如，開發電商系統，需要拆分出用戶服務、商品服務、優惠券服務、支付服務、訂單服務、物流服務、售后服務等等，這些服務之間都相互調用，這時內部調用最好使用 RPC ，同時每個服務都可以獨立部署，獨立上線。也就說，當我們的項目太大，需要解耦服務，擴展性強、部署靈活，這時就要用到 RPC ，主要解決了分布式系統中，服務與服務之間的調用問題。

目前流行的開源 RPC 框架還是比較多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、google 的 gRPC、Twitter 的 Finagle 等。選擇什么樣的RPC框架，大家可以根據自己項目的需要來定。

已經有HTTP請求，為什么還要RPC？

這主要是歷史原因！RPC在1984年就被人用來做分布式系統的通信，JAVA在1.1版本提供了Java版本的RPC框架（RMI），而HTTP協議直到1990年才開始作為主流協議出現，而且HTTP發明的場景是用于web架構，而不是分布式系統間通信，這導致了在很長一段時間內，HTTP都是瀏覽器程序和后端web系統通信用的東西，沒有人會把HTTP作為分布式系統通信的協議。在很長一段時間內，RPC才是正統。

隨著前端技術的發展，AJAX技術和JSON文檔在前端界逐漸成為主流，HTTP調用才擺脫html，開始使用JSON這一相對簡潔的文檔格式，為后面用于系統間調用定下基礎。最后，隨著RESTFUL思潮的興起，越來越多系統考慮用HTTP來提供服務，但這時候，RPC已經是各種大型分布式調用的標配了。所以這個問題我們也可以反過來問，既然有RPC了，為什么還要有HTTP請求？

既然有RPC了，為什么還要有HTTP請求？這個問題不難回答，因為現在大部分的系統都是給瀏覽器使用的，因此，HTTP協議必不可少，而這大部分系統中的絕大部分，對于后端系統間調用的性能都是要求不高的，畢竟走的都是內網，它們關心的是前端和后端的性能，因此后端系統間調用如果能夠采用和前端一樣的技術棧，那無疑是維護成本最低的，而這時HTTP的技術生態也剛好滿足這個條件，所以就星星之火可以燎原了。那么對于少數的部分系統，他們需要使用RPC，一可能是老架構，也不敢動這塊，二是性能要求可能只有RPC可以滿足。

傳輸協議