RPC(remote procedure call)远程方法调用，就是像调用本地方法一样调用远程方法。
RPC是远程调用过程的简写，是一个协议，处于网络通信协议的第五层：会话层，其下就是TCP/IP协议，在建立在其基础上的通信会话协议。
常见RPC框架结构图
RPC架构里包含如下4个组件:
1、 客户端(Client)：服务调用方
2、 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方
3、 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务
4、服务端(Server)：真正的服务提供者RPC是分布式架构的核心，按响应方式分如下两种：
同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作
异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。
完整的架构图如下图所示
执行过程如下图所示
具体实现步骤：
1、 服务调用方（client）(客户端)以本地调用方式调用服务；
2、 client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程3、 client stub找到服务地址，并将消息通过网络发送到服务端；
4、 server stub收到消息后进行解码,在Java里就是反序列化的过程；
5、 server stub根据解码结果调用本地的服务；
6、 本地服务执行处理逻辑；
7、 本地服务将结果返回给server stub；
8、 server stub将返回结果打包成消息，Java里的序列化；
9、 server stub将打包后的消息通过网络并发送至消费方
10、 client stub接收到消息，并进行解码, Java里的反序列化；
11、 服务调用方（client）得到最终结果。RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。要做到对客户端（调用方）透明化服务， RPC框架需要考虑解决如下问题：
1、通讯问题 : 主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
2、寻址问题 ： A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。
3、序列化与反序列化 ： 当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。 同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。
为什么说RPC性能要高于REST
首先声明REST API 和 RPC 都是把一个个函数封装成接口暴露出去，以供调用
不过 REST API 一般都是基于 HTTP 协议（表示层），而 RPC 则可以不基于 HTTP，可以基于TCP/IP协议（会话层）
因此，如果是后端两种语言互相调用，用 RPC 可以获得更好的性能（因为RPC 本质上像调用本地方法一样调用远程方法，省去了 HTTP 报头等一系列东西），应该也更容易配置
如果是前端通过 AJAX 调用后端，那么用 REST API 的形式比较好（因为无论如何也避不开 HTTP 这道坎）
从性能角度看，使用Http时，Http本身提供了丰富的状态功能与扩展功能，但也正由于Http提供的功能过多，导致在网络传输时，需要携带的信息更多（ HTTP 报头等一系列东西，Tcp就不要携带这些信息），从性能角度上讲，较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据，传输数据更小，性能更高。
