RPC(Remote Procedure Call)，通常翻译为远程过程调用，但我觉得翻译成远程程序调用比较方便理解。调用的程序在不同的内存空间,通过网络调用，而不需要了解底层的网络协议（函数调用网络化），它假定了某些传输协议的存在，以便为通信程序建携带信息数据。
RPC也是经典的C/S模式，传送请求，接收回应
RPC调用的流程：
- 客户端调用client stub,本地调用，将参数push进栈
- clinet stub 将参数打包成一个消息，然后发送这个消息。打包过程叫 marshaling
- client所在的系统将消息发送给server
- server系统将收到的包传给server stub
- server stub 解包得到参数，解包过程叫unmarshaling
- 最后server stub调用服务程序，返回结果按照相反的步骤传给client
与RESTful的对比
传输协议：
- RPC可基于TPC、UDP或HTTP
- RESTful基于HTTP
操作对象
- RPC操作的是对象与方法
- RESTful操作的是资源
功能
client与服务端的点对点调用
- stub
- 通信
- RPC消息序列化
服务治理
- 服务发现与注销
- 服务高可用
- 负载均衡
从RPC的功能延伸出来，可以比较下当前的RPC框架，发现这些RPC框架主要有两个方向
- 偏向于跨语言调用方面
- gRPC
- thrift（不支持服务治理）
- rpcx
- 偏向于服务治理方面
- Alibab Dubbo
- Motan
使用RPC，体会很深的的两个特性：
- 屏蔽了本地调用与远程调用的区别，我们调用别的机器上的程序方法就像调用本地方法一样。
- 屏蔽了网络通讯的复杂性，我们不用去处理复杂的网络编程相关的东西，能更专注于处理业务逻辑。