RPC (Remote Procedure Call)是远程过程调用，比如说现在有两台服务器A, B，一个在A服务器上的应用想要调用B服务器上的应用提供的某个，由于不在两个方法不在一个内存空间，不能直接调用，需要通过网络表达调用的语义和传达调用的数据。常存在于分布式系统中。
在分布式计算，远程过程调用（RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
为何有http协议之后，还要RPC调用？
RPC跟HTTP不是对立面，RPC中可以使用HTTP作为通讯协议。RPC是一种设计、实现框架，通讯协议只是其中一部分。
RPC的本质是提供了一种轻量无感知的跨进程通信的方式，在分布式机器上调用其他方法与本地调用无异（远程调用的过程是透明的，你并不知道这个调用的方法是部署在哪里，通过RPC能够解耦服务）RPC是根据语言的API来定义的，而不是基于网络的应用来定义的，调用更方便，协议私密更安全、内容更小效率更高。
RPC模式分为三层，
①用户和服务器(负责处理业务逻辑，调用本地 Stub)
②Stub处理客户端和服务端约定好的语法、语义的封装和解封装
③RPCRuntime负责最底层的网络传输
简单的说，RPC就是从一台机器(客户端)上通过参数传递的方式调用另一台机器(服务器)上的一个函数或方法(可以统称为服务)并得到返回的结果。
RPC架构组件：
一个基本的RPC架构里面应该至少包含以下4个组件：
1 客户端Client:服务调用方（服务消费者）
2 客户端存根Client Stub:存放服务端地址信息，将客户端的请求参数数据信息打包成网络消 息，再通过网络传输发送给服务端
3 服务端存根Server Stub:接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理
4 服务端Server:服务的真正提供者
具体调用过程：
1 服务消费者（client客户端）通过调用本地服务的方式调用需要消费的服务；
2 客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体；
3 客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；
4 服务端存根（server stub）收到消息后进行解码（反序列化操作）；
5 服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；
6 本地服务执行具体业务逻辑并将处理结果返回给服务端存根（ server stub ）；
7 服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方；
8 客户端存根（client stub）接收到消息，并进行解码（反序列化）；
9 服务消费方得到最终结果；
而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务
RPC解决的三大问题:
①协议约定问题(Stub)指的是怎么规定远程调用的语法，怎么传参数等。用上面的类比，你怎么告诉你的朋友要玩什么游戏？是直接说游戏的名字，王者荣耀，绝地求生，还是说简称，王者，吃鸡，或者用 1 代表王者，2 代表吃鸡，只说 1 或 2。
②传输协议问题(RPCRuntime)指的是在网络发生错误、重传、丢包或者有性能问题时怎么办？用上面的类比，你打电话时，刚说了打什么游戏，但是还没有收到对方回复，电话信号不好断了，这时候怎么处理？
③服务发现问题(插件比如:etcd)指的是如何知道服务端有哪些服务可以调用，从哪个端口访问？服务端可能实现多个远程调用，在不同的进程上，随机监听端口，客户端要怎么才能知道这些端口呢？
gRPC是谷歌开源的一个RPC框架，面向移动和HTTP/2设计，产自 Google，基于ProtoBuf序列化协议进行开发，支持多种语言（Golang、Python、Java等）。因为gRPC 对HTTP/2 协议的支持使其在 Android、IOS 等客户端后端服务的开发领域具有良好的前景。gRPC 提供了一种简单的方法来定义服务，同时客户端可以充分利用 HTTP/2 stream 的特性，从而有助于节省带宽、降低 TCP 的连接次数、节省CPU的使用等。
内容交换格式采用ProtoBuf(Google Protocol Buffers)，开源已久，提供了一种灵活、高效、自动序列化结构数据的机制，作用与XML，Json类似，但使用二进制，（反）序列化速度快，压缩效率高。
传输协议 采用http2，性能比http1.1好了很多
和很多RPC系统一样，服务端负责实现定义好的接口并处理客户端的请求，客户端根据接口描述直接调用需要的服务。客户端和服务端可以分别使用gPRC支持的不同语言实现。
rpc是一种协议，grpc是基于rpc协议实现的一种框架。
grpc的解决rpc三大问题：
①协议约定。gRPC 的协议是 Protocol Buffers，是一种压缩率极高的序列化协议，Google 在 2008 年开源了 Protocol Buffers，支持多种编程语言，所以gRPC支持客户端与服务端可以用不同语言实现。
②传输协议。gRPC的数据传输用的是Netty Channel，Netty是一个高效的基于异步IO的网络传输架构。Netty Channel中，每个gRPC 请求封装成 HTTP 2.0的Stream。
③服务发现。gRPC本身没有提供服务发现的机制，需要通过其他组件.
grpc是一种实现了rpc协议的框架，并且分别通过protocol buffer、netty channel以及服务发现组件解决rpc的协议约定、传输协议、服务发现三大问题。