一、什么是RPC框架？
RPC，全稱為Remote Procedure Call，即遠程過程調用，是一種計算機通信協議。
比如現在有兩臺機器：A機器和B機器，并且分別部署了應用A和應用B。假設此時位于A機器上的A應用想要調用位于B機器上的B應用提供的函數或是方法，由于A應用和B應用不在一個內存空間里面，所以不能直接調用，此時就需要通過網絡來表達調用的方式和傳輸調用的數據。也即所謂的遠程調用。
二、RPC框架的實現原理？
主要有以下幾個步驟：

1、建立通信
首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接。主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有相關的數據都在這個連接里面進行傳輸交換。

通常這個連接可以是按需連接（需要調用的時候就先建立連接，調用結束后就立馬斷掉），也可以是長連接（客戶端和服務器建立起連接之后保持長期持有，不管此時有無數據包的發送，可以配合心跳檢測機制定期檢測建立的連接是否存活有效），多個遠程過程調用共享同一個連接。

2、服務尋址
解決尋址的問題：即A機器上的應用A要調用B機器上的應用B，那么此時對于A來說如何告知底層的RPC框架所要調用的服務具體在哪里呢？

通常情況下我們需要提供B機器（主機名或IP地址）以及特定的端口，然后指定調用的方法或者函數的名稱以及入參出參等信息，這樣才能完成服務的一個調用。比如基于Web服務協議棧的RPC，就需要提供一個endpoint URI，或者是從UDDI服務上進行查找。如果是RMI調用的話，還需要一個RMI Registry來注冊服務的地址。

3、網絡傳輸
3.1、序列化
當A機器上的應用發起一個RPC調用時，調用方法和其入參等信息需要通過底層的網絡協議如TCP傳輸到B機器，由于網絡協議是基于二進制的，所有我們傳輸的參數數據都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。然后通過尋址操作和網絡傳輸將序列化或者編組之后的二進制數據發送給B機器。

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

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

通常，經過以上四個步驟之后，一次完整的RPC調用算是完成了，另外可能因為網絡抖動等原因需要重試等。

三、為什么需要RPC？
主要就是因為在幾個進程內（應用分布在不同的機器上），無法共用內存空間，或者在一臺機器內通過本地調用無法完成相關的需求，比如不同的系統之間的通訊，甚至不同組織之間的通訊。此外由于機器的橫向擴展，需要在多臺機器組成的集群上部署應用等等。

四、RPC支持哪些協議？
最早的CORBA、Java RMI， WebService方式的RPC風格， Hessian, Thrift甚至Rest API。

五、RPC的實現基礎？

1、需要有非常高效的網絡通信，比如一般選擇Netty作為網絡通信框架
2、需要有比較高效的序列化框架，比如谷歌的Protobuf序列化框架
3、可靠的尋址方式（主要是提供服務的發現），比如可以使用Zookeeper來注冊服務等等
4、如果是帶會話（狀態）的RPC調用，還需要有會話和狀態保持的功能

六、RPC調用過程？
6.1 一個基本的RPC架構里面應該至少包含以下4個組件：

1、客戶端（Client）:服務調用方（服務消費者）
2、客戶端存根（Client Stub）:存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再通過網絡傳輸發送給服務端
3、服務端存根（Server Stub）:接收客戶端發送過來的請求消息并進行解包，然后再調用本地服務進行處理
4、服務端（Server）:服務的真正提供者

6.2 具體的調用過程如下：

1、服務消費者（client客戶端）通過本地調用的方式調用服務
2、客戶端存根（client stub）接收到調用請求后負責將方法、入參等信息序列化（組裝）成能夠進行網絡傳輸的消息體
3、客戶端存根（client stub）找到遠程的服務地址，并且將消息通過網絡發送給服務端
4、服務端存根（server stub）收到消息后進行解碼（反序列化操作）
5、服務端存根（server stub）根據解碼結果調用本地的服務進行相關處理
6、本地服務執行具體業務邏輯并將處理結果返回給服務端存根（server stub）
7、服務端存根（server stub）將返回結果重新打包成消息（序列化）并通過網絡發送至消費方
8、客戶端存根（client stub）接收到消息，并進行解碼（反序列化）
9、服務消費方得到最終結果

而RPC框架的實現目標則是將上面的第2-10步完好地封裝起來，也就是把調用、編碼/解碼的過程給封裝起來，讓用戶感覺上像調用本地服務一樣的調用遠程服務。

七、RPC框架需要解決的問題？

1、如何確定客戶端和服務端之間的通信協議？
2、如何更高效地進行網絡通信？
3、服務端提供的服務如何暴露給客戶端？
4、客戶端如何發現這些暴露的服務？
5、如何更高效地對請求對象和響應結果進行序列化和反序列化操作？

八、使用了哪些技術？
8.1、動態代理
生成Client Stub（客戶端存根）和Server Stub（服務端存根）的時候需要用到java動態代理技術，可以使用jdk提供的原生的動態代理機制，也可以使用開源的：Cglib代理，Javassist字節碼生成技術。

8.2、序列化
在網絡中，所有的數據都將會被轉化為字節進行傳送，所以為了能夠使參數對象在網絡中進行傳輸，需要對這些參數進行序列化和反序列化操作。

序列化：把對象轉換為字節序列的過程稱為對象的序列化，也就是編碼的過程。
反序列化：把字節序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。

目前比較高效的開源序列化框架：如Kryo、fastjson和Protobuf等。

8.3、NIO通信
出于并發性能的考慮，傳統的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。
Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支持。可以選擇Netty或者mina來解決NIO數據傳輸的問題。

8.4、服務注冊中心
可選：Redis、Zookeeper、Consul 、Etcd。
一般使用ZooKeeper提供服務注冊與發現功能，解決單點故障以及分布式部署的問題(注冊中心)。