共计 1115 个字符，预计需要花费 3 分钟才能阅读完成。
很久很久以前经常听到同事提到RPC，因为对工程的了解没那么多，所以也没去纠结RPC，最近自己也在着手写一写工程代码，用到了dubbo，顺便了解了RPC。
RPC(Remote Produce Call)指的是进程间通信。就是允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，且不需要显式编码这个远程调用的细节。
RPC解决的问题：
- 解决分布式系统中，服务之间的调用问题。
- 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
以下一段描述转载自知乎，加上自己一点乱写（红字标出）。
因为如今大公司内部系统由大大小小的许多服务组成，服务部署在不同的机器上，如果服务间的调用都是走网络通信，未免也太过复杂，服务消费方没调用一个服务都要写一部分网络通信的代码，太过繁琐且容易出错。如果能像本地调用一个去调用远程连接这样该多好啊，这种方式就是RPC远程调用。
那么问题又来了。
远程问题如何通信？
客户端如何寻址服务端？
客户端服务端之间以何种形式传输的信息？
客户端与服务端建立TCP链接，相比于HTTP通信协议少去应用层的许多东西。数据的传输就是通过这个TCP的链接。
如果使用HTTP，那么每一个客户端都要协议对请求和解析响应一整套的东西，很麻烦，任何一个客户端都要重复相应的操作，这个也是可以说明为什么不适用HTTP作为交互的协议方式。
客户端寻址主要是通过事先写入地址，也就类似于服务注册，注册服务后，调用对应的方法也就是自动通过TCP链接传输到对应的地址。
客户端服务端传输信息首先都是通过网络二进制，那么也就是涉及到序列化和反序列化的问题。
所以需要在传输的时候需要对数据进行序列化和反序列化，现在的RPC框架都是帮我们处理好这块。
RPC远程调用目的：通过像调用本地服务一样远程调用另一台服务器上的服务来完成需求。（核心）
最终问题：如何才能不需要显式编码远程调用的细节去远程调用服务呢？
RPC原理
上图就是提供一个RPC调用关系图，两个角色服务提供者/服务消费者，消费者负责不断的消费获取想要的数据。现有的RPC框架都会将中间的部分全部封装起来，所以我们只要关注服务接口的编写，调用者只要调用接口就好，关于中间的数据传输以及服务发现等等都不需要自己去关注。所以刚才提到的调用者就像调用本地程序一样，说的就是这点，调用者只需要实现接口的调用即可。
分布式
在面对高性能的要求下，实现分布式处理负载均衡以及HA高可用等性能要求时，这个时候凸显的优势就明显了。RPC在内部服务中间调用居多，由于使用量的庞大，所以对性能的要求很高。关于分布式RPC你需要知道zookeeper、dubbo 等之间的协作，剩下的就是堆机器就可以解决了。
