很長時間一直專注於業務編碼，不去關注底層實現和設計，導致面試啪啪打臉，學習吧!
RPC的全稱是Remote Procedure Call，是一種程式間通訊方式。它允許程式呼叫另一個程式上（通常是共享網路的另一臺機器）的過程或函式，而不用程式設計師顯式編碼這個遠端呼叫的細節。也就是說，程式設計師無論是呼叫本地的還是遠端的函式，本質上編寫的呼叫程式碼基本相同。
RPC主要解決三件事情：
- 程式間通訊
- 提供和本地方法呼叫一樣的呼叫機制
- 遮蔽程式設計師對遠端呼叫的細節實現
- RPC基本原理
- rpc對一些遠端呼叫的內部實現進行封裝：
- 序列化
- 編解碼
- 協議
- 網路
2. rpc遠端呼叫過程：
- 服務消費方（client）呼叫以本地呼叫方式呼叫服務
- client stub接收到呼叫後負責將方法、引數等組成能夠進行網路傳輸的訊息體
- client stub找到服務地址，並將訊息傳送到服務端
- server stub收到訊息後進行解碼
- server stub根據解碼結果呼叫本地服務
- 本地服務支援並將結果返回給server stub
- server stub將返回結果打包成訊息併傳送至消費方
- client stub接收到訊息，並進行解碼
- 服務消費方得到最終結果
rpc相當於將2至8步驟進行封裝，如圖：
2. RPC模型
對於上圖進一步拆解得到如下
上圖解讀：
- RPC服務端通過RpcServer去暴露服務介面，二客戶端通過RpcClient去獲取服務介面
- 客戶端像呼叫本地方法一樣去呼叫遠端介面方法
- RPC框架提供介面的代理實現，實際的呼叫將委託給代理Rpcproxy，代理封裝呼叫資訊並將呼叫轉給Rpcinvoker去實際執行。
- 在客戶端的RpcInvoker通過聯結器RpcConnect 去維持與 服務端的通道RpcChannel，並使用RpcProtocol執行協議編碼（encode）並將編碼後的請求訊息通過通道傳送給服務端。
- Rpc服務端接收器RpcAcceptor接收客戶端的呼叫請求，同樣使用RpcProtocol執行協議解碼（decode），解碼後的呼叫資訊傳遞給RpcProcessor去控制處理呼叫過程，最後在委託呼叫給RpcInvoker去實際執行並返回撥用結果。
- 用於暴露服務介面的RpcServer
- 用於發現服務介面的RpcClient
- 遠端介面的代理實現RpcPorxy
- 負責協議編解碼的RpcProtocol（實際中rpc框架中一般會提供多種不同的實現）
- 網路聯結器
- dubbo阿里巴巴公司開源的一個java高效能優秀的服務框架
- motan新浪微博開源的一個java框架
- gRPC Google開發的高效能、通用的開源RPC框架，主要面向移動應用開發並給予HTTP/2協議標準而設計，本身不是分散式的。
MQ（message queue）訊息佇列，從某種程度上來說，同樣可以實現RPC的功能，從功能特點上來說，MQ可以把訊息儲存，二rpc不行，簡單對比如下
本文主要是看了大神的分享，一個字一個字抄錄過來，後面可以常常學習瞭解，如有問題可聯絡我