RPC英文全称remote procedure call 翻译成中文的意思就是远程过程调用。RPC的出现其实主要是为了解决分布式系统间的通信透明性的问题。
那什么是分布式系统的通信透明性问题？这个问题就是指分布式系统间的相互调用其实是基本进程间的显式消息交换，然而，消息的发送和接收过程无法隐藏。而通信的隐藏对于分布式中实现访问的透明性是极为重要的。试想一下比如你要想查看一个订单详情，然后订单系统部署了三台机器。假设没有RPC，其它系统想通过调订单系统查询订单详情的信息，就必须知道订单系统部署机器的ip和端口，每个调用者必须关注订单系统新加或者下线和换机器部署等情景。试想这对调用者来说是有多蛋疼。换言之分布式系统通信就应该是透明的，这样调用者就不需要关心调用的是那台机器上面的服务。在调用者的角度这个远程服务应该和调用本地服务一样是一个单一稳定可靠的服务。
基于这样的背景有人就提出了一种与传统方法截然不同的通信手段：不同机器上的进程是允许相与调用的，当机器A上的进程调用机器B上的进程时，A上的调用进程被挂起，而B上的被调用进程开始执行。调用方可以通过使用参数将信息传送给被调用方，然后可以通过传回的结果得到信息。编程人员看不到任何消息传递过程。这个方法就被程为远程过程调用RPC.
在介绍RPC之前我们先来看常规过程调用。比如我们定义一个c语言的方法
count = read(fd,buf,nbytes); 这里fd为一个整形数，表示一个文件，buf为一个字符数组，用于存储读入的数据,nbytes为另一个整数，用于记录实际读入的字节数。当在主程序调用这个方法时实际的执行过程是先把参数压入堆栈中
然后程序读取堆栈里面的参数，执行系统的库函数，其中还包括执行线程从用户态到内核态的切换，执行完毕后又从内核态到用户态的转换过程。这些于调用者来说都是不可见和不用关心的。
RPC的设计思想其实与常规过程调用类似，屏蔽底层的细节使程序不知道调用的业务逻辑是在另一台机器上面处理的使其专注于自身业务逻辑处理。正常的RPC调用过程
举一个远程调用两个数求和的详细调用过程
这里面出现了两个名词客户端存根、服务端存根。 其实客户端存根指的就是我们现在RPC框架中的client端，服务端存根就是server端，只是不叫法而已。客户端存根的作用是把请求的参数以约定的通讯协议打包好发送给服务端然后解析服务端返回消息，服务端存根就是根据收到的请求信息执行相应的业务逻辑调用并把结果返回客户端。要定义一个RPC框架首先要定义好通讯格式,因为最络从网络层解析出来的数据都是以字符串的形式解析出来的.我们需要从这一串字符中解析出调用哪个服务，服务入参是什么。
一般来说客户端存根会把调用类名称传给服务端，服务端存根根据这个名称找到对应的service的映射，就知道调哪个服务了。所以服务端存根要保存一份service的映射关系。同样客户端存根收到响应后会唤醒之前调用的线程或者等待之前的线程运行处理返回的结果。
解决了RPC的调用问题，现在还要解决的一个关键问题是，客户端怎么知道调用哪一台机器上的服务。这就需要引入一个中间的第三者目标服务器。
服务提供者向目标服务器注册服务，客户机从目标服务器（一种叫法叫服务注册中心）中获取可调用的机器列表。如果有用过类似dubbo这样的RPC框架是不是对这个图很熟悉？因为所有的RPC架构的原理大多都是类似的。服务提供者往目标服务器里面通常会注册机器的ip和端口信息。
下面我们来谈下RPC的好处和注意的地方。
好处：屏蔽了底层通讯的复杂性，在分布式系统中提供了通讯的透明性。
需要注意的地方：RPC是点对点的通讯方式，要求通讯两端必须同时运行，当其中一端挂了就会导致通常异常，并且调用者一般会阻塞住等待结果的返回，性能相对不是很高，当然也有异步RPC，超时重试情况下服务端提供者需要做好服务幂等性处理。相对于RPC而言采用了面向消息通讯模型的架构比如MQ则不要求通讯两端同时运行，发送消息时也不需要阻塞等待处理结果的返回通讯性能就高出很多。
最后我们总结一下：RPC调用是指不同机器间的进程通讯。程序不需要关心某个远程服务是在哪台机器上执行的，远程服务调用就和调用本地服务一样。要在不同机器间进行通讯我们需要知道通讯机器的ip和端口号。ip帮助我们定位是哪一台机器，端口号帮我们定位是机器上的哪一个进程。RPC的出现使用得机器的进程通讯透明化，这在分布式系统中是很重要的。RPC调用架构中客户端和服务端都和一个叫服务注册中心的第三方通讯。
随时随地看视频
