什么是 RPC？
我们先来聊聊 RPC 到底是什么。
它的全称是 Remote Procedure Call Protocol，中文翻译过来就是“远程过程调用协议”。
不妨从两个维度来理解：
- 首先，它本质上是一种协议；
- 其次，它是一种 Client/Server 的传输模式。
官方定义说得更直白一点：它是一种通过网络从远程计算机程序上请求服务的协议，关键就在于——你不需要了解底层的网络技术细节。也就是说，服务调用方无需关心数据怎么打包、怎么传、怎么解包，这些事儿 RPC 全都替你兜底了。
再展开一点说，RPC 的分层设计还挺清晰的，大致可以分为三层：
- 用户端和服务端：负责处理业务逻辑，调用本地的 Stub；
- Stub 层：处理客户端和服务端之间约定好的语法、语义的封装与解封装；
- RPCRuntime 层：负责最底层的网络传输。
下面这张图看起来是不是挺眼熟的？其实就和咱们平时开发中“前端请求后端接口”的流程差不多。
RPC 解决了什么问题？
RPC 的存在，其实是为了解决几个非常实际的问题：
- 协议约定问题：比如你用 0 表示“是”，1 表示“否”，怎么让前端和后台共同遵守这个约定？这需要一套清晰的规范。
- 传输协议问题：网络环境并不总是稳定，出现错误、重传、丢包或者性能瓶颈时，该怎么办？RPC 需要处理这些“脏活”。
- 服务发现问题：你怎么知道服务端到底提供哪些远程服务可以调用？从哪个端口访问？服务端可能会同时实现多个远程调用，分布在不同的进程上，每个进程监听的端口也可能是随机的。客户端怎么知道该连哪个？这个问题解决了，远程调用的“门槛”才算真正降下来。
RPC 的应用场景
一般来说，RPC 主要用在两个场景上：
- 实时聊天：比如即时通讯场景下，消息的收发高频且要求低延迟；
- 微服务系统：这也是目前最主流的用法，微服务架构下各个服务之间的“内部通信”，RPC 几乎是标配。
RPC 的传输过程是怎么样的？
整个传输过程其实可以拆解成几个清晰的步骤：
- 调用者（也就是 Client）以本地调用的方式发起远程调用；
- Client stub（客户端存根）收到调用后，负责将方法名、参数等信息打包、编码成特定格式的网络传输消息体；
- Client stub 通过网络把消息体发送给服务端；
- Server stub（服务端存根）收到消息后，按照相应格式拆包解码，提取出方法名和参数；
- Server stub 根据方法名和参数，执行对应的本地调用；
- 被调用者（Server）执行业务逻辑后，将结果返回给 Server stub；
- Server stub 将返回值打包编码成消息，并通过网络传回给客户端；
- Client stub 收到消息后，拆包解码，将最终结果返回给 Client；
- 至此，Client 拿到了本次 RPC 调用的最终结果，一次完整的远程调用就结束了。
RPC 与 HTTP 的对比
其实 RPC 和 HTTP 并不是一个层级的东西。如果真的要比较，应该是拿“RPC”和“HTTP + RestFul”来比，才更有意义。
传输协议
RPC 可以基于 HTTP 或者 TCP 进行传输，而 HTTP 协议只能基于 HTTP，灵活性上就有差距了。
传输效率
RPC 的一大优势在于它可以“吃掉”HTTP2 的红利，比如二进制分帧、多路复用这些特性，所以传输效率天然比 HTTP1 高出一截。
性能消耗
同样因为 HTTP2 的特性——二进制传输、头部压缩等——RPC 在性能消耗上也更低。
负载均衡
RPC 框架基本都内置了负载均衡策略，直接用就行。而 HTTP 的话，往往得额外配一个 Nginx 或者 HAProxy 才能搞定。
服务治理
在服务治理方面，RPC 能做到自动通知、不影响上游服务。而 HTTP 环境下，通常需要人工事先通知，然后再去改 Nginx/HAProxy 配置，效率和协调成本高不少。
什么是 gRPC
是什么
你可以把 gRPC 理解成基于 RPC 封装出来的一个开源框架，它的底层通信是基于 HTTP2 设计的。所以，gRPC 自然也继承并放大了 HTTP2 的优势：
- 数据传输采用二进制分帧；
- 多路复用；
- 服务端推送；
- 头部压缩。
是怎么传输的？
结合这张图来看会更直观：在 gRPC 的架构下，客户端的调用方只需要持有 gRPC Stub（为什么叫“存根”？其实就是一个本地袋里，帮你做编解码和网络调用），通过 Proto Request 向 gRPC Server 发起服务调用，然后 Server 端通过 Proto Response(s) 把结果返回给调用方。整个过程对客户端来说，和调用本地方法几乎没有区别。
JSON-RPC 接口
JSON-RPC 是一种非常轻量级的 RPC 协议。它使用 HTTP 作为传输层协议，数据格式则用 JSON。因为简单直接，所以配合像 Postman 这样的工具来测试和调用会非常顺手。
使用 Postman 发送 JSON-RPC 接口
具体操作步骤其实不复杂：
- 第一步：打开 Postman，创建一个新的 HTTP 请求；
- 第二步：在请求面板中，选择 HTTP 方法为 POST；
- 第三步：输入 JSON-RPC 接口的 URL 地址；
- 第四步：在 Body 中选择 raw - JSON，然后按以下格式输入请求数据：
{ "jsonrpc": "2.0", "method": {{要调用的方法名称}}, "params": {{方法所需的参数}}, "id": {{请求的唯一标识符}}}
- 第五步：单击 Send 按钮发送请求。如果一切正常，响应面板中就会看到返回的 JSON 数据。
上面这个例子中，我们调用了一个名为 echo 的方法，并传入了一个对象作为参数，请求的唯一标识符设为 123。
使用 Apifox 调试 gRPC
Apifox 支持基于 .proto 文件的 gRPC 调试，包括一元调用和流式调用。创建项目时选择“gRPC 项目”，然后导入 .proto 文件，不需要写任何代码就能直接调用 gRPC 接口，对开发者来说非常友好。
当然，在调试 gRPC 接口之前，得先把作为 API 定义的 .proto 文件导入进来。如果有文件依赖关系，也不要紧，Apifox 支持手动添加依赖关系目录。
一元调用
一元调用的操作很简单：在地址栏填好 URL，直接点击“调用”按钮就行了。
流式调用
流式调用则涵盖了服务端流、客户端流和双向流几种模式。
发起调用之后，你可以在 Message 标签下撰写消息并发出去。Apifox 提供的时间线视图会按时间顺序集中展示调用状态、发送的消息以及收到的消息。点击某条消息后，可以很方便地查看完整的详情信息。
