1.rpc是什么：

RPC（Remote Procedure Call）是遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。簡單的理解是一個節點請求另一個節點提供的服務

RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程序更加容易。

RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，然后等待應答信息。

2.為什么要用RPC服務

我們在做一個訪問量不大的項目的時候,一臺服務器部署上一個應用+數據庫也就夠了.

那么訪問量稍微大一點之后呢,為了解決用戶反饋的卡,反應慢的情況,我們就上集群.架設nginx,部署多個服務,由nginx負責把請求轉發到其他服務上,這樣就解決了用戶說的卡慢問題.

過了一段時間之后呢,我們發現數據庫已經扛不住了,應用服務完好,數據庫有時候宕機. 那這個時候呢,我們就上數據庫讀寫分離,再架設幾臺數據庫服務器,做主從,做分庫分表. 然后數據庫也不宕機了,服務又恢復了流暢.

又過了一段時間,公司事業增增日上,服務訪問量越來越高,且大部分都是查詢, 吸取之前宕機且為了辦證數據庫的健壯性,我們這個時候又加上了緩存, 把用戶高頻次訪問的數據放到緩存里.

后來,項目功能越來越多,整個項目也愈發龐大,修改一個類就需要全盤上傳,切換nginx重啟,這樣的發布流程越來越長,越來越繁雜.然后我們開始把模塊拆分,用戶信息分個項目,訂單系統分一個項目.這樣就達到了,用戶模塊代碼修改的時候,只需要更新用戶信息服務就好了.但是還是需要切換頂層的nginx.把要重啟的服務的流量切到可用服務上. 這個時候我們就想到了RPC

那么RPC解決了什么呢? 所有的服務在啟動的時候注冊到一個注冊機里面,然后頂層處理在接收到nginx的請求時,去注冊機找一個可用的服務,并調用接口. 這樣子呢,在不加新功能的時候,頂層處理服務我們就不需要動了? 那修改了用戶信息項目的時候,我們只需要一個個更新用戶信息項目的服務群就好了?

?

3.本地與遠程調用

本地過程調用：如果需要將本地student對象的age+1，可以實現一個addAge()方法，將student對象傳入，對年齡進行更新之后返回即可，本地方法調用的函數體通過函數指針來指定。

遠程過程調用：上述操作的過程中，如果addAge()這個方法在服務端，執行函數的函數體在遠程機器上，如何告訴機器需要調用這個方法呢？

首先客戶端需要告訴服務器，需要調用的函數，這里函數和進程ID存在一個映射，客戶端遠程調用時，需要查一下函數，找到對應的ID，然后執行函數的代碼。

客戶端需要把本地參數傳給遠程函數，本地調用的過程中，直接壓棧即可，但是在遠程調用過程中不再同一個內存里，無法直接傳遞函數的參數，因此需要客戶端把參數轉換成字節流，傳給服務端，然后服務端將字節流轉換成自身能讀取的格式，是一個序列化和反序列化的過程。
3.數據準備好了之后，如何進行傳輸？網絡傳輸層需要把調用的ID和序列化后的參數傳給服務端，然后把計算好的結果序列化傳給客戶端，因此TCP層即可完成上述過程，gRPC中采用的是HTTP2協議。

?

4.Restful和RPC是什么關系：

這兩個不是互斥的，HTTP是不是RPC完全取決于client的具體形式。傳統的RPC一般是基于二進制協議的，client發個二進制包過來（然后阻塞），server處理完回復一個包，client收到后醒來。在二進制協議中一般可以在包中加個id來指明回復和請求的對應關系，這樣我們就能在一個tcp連接上同時發起多個請求和回復。HTTP這種文本協議也可以加id，但由于一些原因（Content-Length可能缺失），即使加了id也做不到一個連接上同時傳多個HTTP消息，所以HTTP協議一般會和server保持多個連接，每個連接上同時最多只有一個HTTP消息。此種”連接池“方式即為HTTP中的”Keep-alive“。所以即使在HTTP上（或任何協議上），我們仍然可以做到高效地發送一個請求過去，阻塞，等待server處理完后，再醒來。這不就是RPC么。所以這兒的選擇更多是平衡功能和性能。一般來說，面向終端用戶的盡量用Restful HTTP。原因是認知廣，直觀，編程語言都支持HTTP（包括shell，這樣調試起來方便），性能不是那么重要，方便用戶share鏈接。而面向內部系統的話如果機器不多也可以考慮用Restful HTTP，如果機器很多還是盡量用二進制的RPC吧，畢竟性能差距還是很大的。

?

5.Http和RPC的區別

RPC（即Remote Procedure Call，遠程過程調用）和HTTP（HyperText Transfer Protocol，超文本傳輸協議）他們最本質的區別，就是RPC主要工作在TCP協議之上，而HTTP服務主要是工作在HTTP協議之上，我們HTTP協議是在傳輸層協議TCP之上的，且HTTP接口由于受限于HTTP協議，需要帶HTTP請求頭。所以效率來看的話，RPC要要更勝一籌。
在性能消耗上 主要在于序列化和反序列化的耗時
RPC，可以基于thrift實現高效的二進制傳輸
HTTP，大部分是通過json來實現的，字節大小和序列化耗時都比thrift要更消耗性能RPC基本都自帶了負載均衡策略且在服務治理方面能做到自動通知，RPC主要要用于公司內部的服務調用，HTTP主要用于對外的異構環境，app，瀏覽器調用

總結

以上是生活随笔為你收集整理的RPC服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。