gRPC 为什么比 REST 快 5 倍？原理与 RPC 局限解析

在现代微服务架构中，RPC 的高效通信是许多开发者关注的重点。云栈社区 为你提供了关于 RPC 和 gRPC 的丰富讨论和资源。

RPC（Remote Procedural Call, 远程过程调用）之所以被称为 remote，因为在微服务架构下，RPC 可以实现远程服务之间的通信。从服务调用者的角度来看，它就像一个本地函数调用。

下图说明了 gRPC 的数据流。

1. 步骤 1：客户前端发出 REST 调用。请求体通常为 JSON 格式。
2. 步骤 2-4：订单服务（gRPC 客户端）接收 REST 调用，对其进行转换，然后向支付服务发出 RPC 调用。gRPC 将 client stub 编码为二进制格式，并将其发送到底层传输层。
3. 步骤 5：gRPC 通过 HTTP2 在网络上发送数据包。由于采用了二进制编码和网络优化，gRPC 据说比 JSON 快 5 倍。
4. 步骤 6 - 8：支付服务（gRPC 服务器）接收来自网络的数据包，解码后调用服务器应用程序。
5. 步骤 9 - 11：结果从服务器应用程序返回，经过编码后发送到传输层。
6. 步骤 12 - 14：订单服务接收数据包、解码并将结果发送给客户端应用程序。

和广泛用于前后端通信的 REST 相比，gRPC 普遍用于服务间通信。并且，REST 不是一个协议，它只是一个基于 HTTP 协议的设计范式。gRPC 针对传输层和数据编解码都进行了优化，使得它的效率更高。

虽然 RPC 调用在微服务中被广泛采用，神书 DDIA (Designing Data‑Intensive Applications) 中列举了一些 RPC 的局限性：

1. 本地函数调用的结果是可预测的，而 RPC 需要经过网络传输，数据在中途可能因为各种原因丢失。
2. RPC 调用有可能超时，编写程序时需要考虑该情况。
3. 重试一个失败的 RPC 调用有可能造成数据重复，需要考虑幂等。
4. 由于传输数据时需要序列化和反序列化，RPC 在传输复杂对象时会不太方便。

正是因为这些原因，让远程调用看上去像是一个本地调用的编程思想值得商榷。开发者在使用 RPC 时需要有针对性地进行容错处理。