到底什麼才是rpc?
RPC是指遠端過程呼叫，也就是說兩臺伺服器A，B，一個應用部署在A伺服器上，想要呼叫B伺服器上應用提供的函式/方法，由於不在一個記憶體空間，不能直接呼叫，需要通過網路來表達呼叫的語義和傳達呼叫的資料！遠端服務呼叫
我眼中的RPC：
服務提供者提供服務 消費者去消費
服務提供者在青島撈海鮮,消費者坐在新疆的餐館裡點了一盤麻辣小龍蝦 這中間的過程就是RPC
本身http請求也可以理解為一種rpc服務 php呼叫golang的介面那也是遠端服務呼叫啊！
大白話理解RPC就是：RPC讓你用別人家的東西就像自己家的一樣
為什麼要用rpc?
以大家最熟悉的電商系統為例，這樣規模的分散式系統，需要拆分出使用者服務、商品服務、優惠券服務、支付服務、訂單服務、物流服務、售後服務等等。這些服務之間都相互呼叫，這時內部呼叫最好使用 RPC ，同時每個服務都可以獨立部署，獨立上線。
也就說當我們的專案太大，需要解耦服務，擴充套件性強、部署靈活，這時就要用到 RPC ，這主要是解決了分散式系統中，服務與服務之間的呼叫問題。
為什麼不直接使用http,而要搞rpc?
在日常業務中我們可以把功能封裝成靜態庫、動態庫、sdk、獨立服務等，最常見也最方便的還是HTTP這種形式的呼叫。
HTTP服務把需要提供的服務暴露成介面（也就是通常所說的http rest介面啦），使用方直接按約定的HTTP方法和URI進行資料互動。
我們都知道HTTP協議是應用層協議，是個非常標準的協議，在HTTP協議之下還有網路層、傳輸層、資料鏈路層等，一個資料包packet除了淨荷payload之外還有很多header，由於標準和通用性的設計目標也使得HTTP一次資料互動真正傳輸的payload只是其中一部分。
HTTP是我們用的最多最熟悉的互動模式，在系統內部各個服務之間介面較少，互動不多的情況下工作得還不錯。
但如果在內部系統呼叫很複雜的前提下，HTTP呼叫的效率和安全性就不那麼理想了。
以IM系統為例，單個IM例項的吞吐效率至少可以達到幾萬甚至數十萬QPS，使用HTTP這種短連線（呼叫時建立socket連線，完成後釋放連線）方式顯的相當低效（每次呼叫都要重新經歷TCP的3次握手、4次揮手過程），在分散式的情況下勢必拉低整個IM叢集的吞吐效率。而對於RPC，這種socket長連線方式對於高效能場景來說，效果是顯而易見的。
更重要的是面對眾多的服務我們需要的不僅僅是一個通訊方式，而是一個內部服務的管理系統，這也就是我們今天說的RPC框架。注意：RPC是一種模式策略和框架，並不是單純的通訊協議
實際上，HTTP在RPC系統中，並不是個你死我活的關係，必竟HTTP只是個通訊協議，而HTTP有某些效能要求不敏感的場景來說，是完全可以作為RPC的具體實現協議之一來使用的。
rpc的呼叫過程是怎樣的？
如上圖所示，一個典型的RPC呼叫過程是這樣（過程式號對應上圖中的數字）：
1）客戶端（client）以本地呼叫方式呼叫服務；
2）客戶端存根（client stub）接收到呼叫後，負責將方法、引數等組裝成能夠進行網路傳輸的訊息體（將訊息體物件序列化為二進位制）；
3）客戶端通過 sockets 將訊息傳送到服務端；
4）服務端存根（server stub）收到訊息後進行解碼（將訊息物件反序列化）；
5）服務端存根（server stub）根據解碼結果呼叫本地的服務；
6）本地服務執行並將結果返回給服務端存根（server stub）；
7）服務端存根（server stub）將返回結果打包成訊息（將結果訊息物件序列化）；
8）服務端（server）通過 sockets 將訊息傳送到客戶端；
9）客戶端存根（client stub）接收到結果訊息，並進行解碼（將結果訊息發序列化）；
10）客戶端（client）得到最終結果。
RPC的作用，其實就是要把上述2、3、4、7、8、9 這些步驟都封裝起來。是不是很神奇？
HTTP和RPC是兩個很容易混淆的概念，對於剛開始接觸RPC的人來說，通常都會困惑：有HTTP了為什麼還要用RPC？
![什麼是rpc?]
換個角度來說：HTTP 與 RPC 的關係就好比普通話與方言的關係。要進行跨企業服務呼叫時，往往都是通過 HTTP API，也就是普通話，雖然效率不高，但是通用，沒有太多溝通的學習成本。但是在企業內部還是 RPC 更加高效，同一個企業公用一套方言進行高效率的交流，要比通用的 HTTP 協議來交流更加節省資源。整個中國有非常多的方言，正如有很多的企業內部服務各有自己的一套互動協議一樣。雖然國家一直在提倡使用普通話交流，但是這麼多年過去了，你回一趟家鄉探個親什麼的就會發現身邊的人還是流行說方言。
如果再深入一點說，普通話本質上也是一種方言，只不過它是官方的方言，使用最為廣泛的方言，相比而言其它方言都是小語種，小語種之中也會有幾個使用比較廣泛比較特色的方言佔比也會比較大。這就好比開源 RPC 協議中 Protobuf 和 Thrift 一樣，它們兩應該是 RPC 協議中使用最為廣泛的兩個
總結：
RPC是一種程式設計模式和概念，並不是非常具體的一種技術，實際上和HTTP沒有明確的衝突，HTTP可以作為RPC傳輸協議，原因還是RPCpid際上是一種內部服務框架而不是一個具體的通訊協議，它可以涉及服務註冊、服務治理、服務發現、熔斷機制、負載均衡等。
基於 TCP 實現的 RPC 呼叫，能夠靈活對協議欄位進行定製，減少網路開銷提高效能，實現更大的吞吐量和併發數，但要關注底層細節，在進行資料解析時更加複雜一些（比如最受歡迎的Protobuf的使用）。
基於 HTTP 實現的 RPC 可以使用 JSON 和 XML 格式的請求或響應資料，解析工具很成熟，在其上進行二次開發會非常便捷和簡單。但是 HTTP 是上層協議，所佔用的位元組數會比使用 TCP 協議傳輸所佔用的位元組數更高。基於 HTTP 實現的 RPC 可以使用 JSON 和 XML 格式的請求或響應資料，解析工具很成熟，在其上進行二次開發會非常便捷和簡單。但是 HTTP 是上層協議，所佔用的位元組數會比使用 TCP 協議傳輸所佔用的位元組數更高。
本作品採用《CC 協議》，轉載必須註明作者和本文連結