RPC，也就是远程过程调用，是分布式系统中不同节点调用的方式（进程间通信），属于 C/S 模式。RPC 由客户端发起，调用服务端的方法进行通信，然后服务端把结果返回给客户端。
RPC的核心有两个：通信协议和序列化。在 HTTP 2 之前，一般采用自定义 TCP 协议的方式进行通信，HTTP 2 出来后，也有采用该协议的，比如流行的gRPC。
序列化和反序列化是一种把传输内容编码和解码的方式，常见的编解码方式有 JSON、Protobuf 等。
在大多数 RPC的架构设计中，都有Client、Client Stub、Server、Server Stub这四个组件，Client 和 Server 之间通过 Socket 进行通信。RPC 架构如下图所示：
下面我为你总结下 RPC 调用的流程：
- 客户端（Client）调用客户端存根（Client Stub），同时把参数传给客户端存根；
- 客户端存根将参数打包编码，并通过系统调用发送到服务端；
- 客户端本地系统发送信息到服务器；
- 服务器系统将信息发送到服务端存根（Server Stub）；
- 服务端存根解析信息，也就是解码；
- 服务端存根调用真正的服务端程序（Sever）；
- 服务端（Server）处理后，通过同样的方式，把结果再返回给客户端（Client）。
RPC 调用常用于大型项目，也就是我们现在常说的微服务，而且还会包含服务注册、治理、监控等功能，是一套完整的体系。
RPC 框架基本都是直接基于 TCP 协议自研数据结构和编解码方式
RPC 的全称是 Remote Procedure Call，即远程过程调用。简单解读字面上的意思，远程 肯定是指要跨机器而非本机，所以需要用到网络编程才能实现，但是不是只要通过网络通信 访问到另一台机器的应用程序，就可以称之为 RPC
调用了？显然并不够.
我理解的 RPC 是帮助我们屏蔽网络编程细节，实现调用远程方法就跟调用本地（同一个项 目中的方法）一样的体验，我们不需要因为这个方法是远程调用就需要编写很多与业务无关 的代码。
这就好比建在小河上的桥一样连接着河的两岸，如果没有小桥，我们需要通过划船、绕道等 其他方式才能到达对面，但是有了小桥之后，我们就能像在路面上一样行走到达对面，并且 跟在路面上行走的体验没有区别。所以我认为，RPC
的作用就是体现在这样两个方面：
屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法； 隐藏底层网络通信的复杂性，让我们更专注于业务逻辑。
RPC 在架构中的位置
围绕 RPC 我们讲了这么多，那 RPC 在架构中究竟处于什么位置呢？ 如刚才所讲，RPC 是解决应用间通信的一种方式，而无论是在一个大型的分布式应用系统 还是中小型系统中，应用架构最终都会从“单体”演进成“微服务化”，整个应用系统会被
拆分为多个不同功能的应用，并将它们部署在不同的服务器中，而应用之间会通过 RPC 进 行通信，可以说 RPC 对应的是整个分布式应用系统，就像是“经络”一样的存在。
RPC 和 REST 对比
