RPC（Remote procedure Call）之所以被称为"远程"，是因为在微服务架构下，当服务部署到不同的服务器上时，它可以实现远程服务之间的通信。从用户的角度来看，它的作用就像本地函数调用。
下图说明了gRPC的整体数据流。
步骤 1：从客户端发出 REST 调用。请求正文通常为 JSON 格式。
步骤 2 - 4：订单服务（gRPC 客户端）接收 REST 调用，对其进行转换，并对支付服务进行 RPC 调用。gRPC 将客户端存根编码为二进制格式并将其发送到低级传输层。
步骤 5：gRPC 通过 HTTP2 通过网络发送数据包。由于二进制编码和网络优化，gRPC 据说比 JSON 快 5 倍。
步骤 6 - 8：支付服务（gRPC 服务器）从网络接收数据包，对其进行解码，然后调用服务器应用程序。
步骤 9 - 11：结果从服务器应用程序返回，经过编码后发送到传输层。
步骤 12 - 14：订单服务接收数据包，对其进行解码，并将结果发送到客户端应用程序。
什么又是网络钩子呢？
下图显示了轮询和 Webhook 之间的比较。
假设我们运营一个电子商务网站。客户端通过API网关向订单服务发送订单，订单服务再到支付服务进行支付交易。然后，支付服务与外部支付服务提供商 (PSP) 对话以完成交易。
有两种方法可以处理与外部 PSP 的通信。
假设我们运营一个电子商务网站。客户端通过API网关向订单服务发送订单，订单服务再到支付服务进行支付交易。然后，支付服务与外部支付服务提供商 (PSP) 对话以完成交易。
有两种方法可以处理与外部 PSP 的通信。
1. 短轮询
支付服务向PSP发送支付请求后，不断向PSP询问支付状态。经过几轮之后，PSP终于返回状态。
短轮询有两个缺点：
- 持续轮询状态需要支付服务的资源。
- 外部服务直接与支付服务通信，从而产生安全漏洞。
2. 网络钩子
我们可以向外部服务注册一个 webhook。这意味着：当您有请求更新时，通过某个 URL 给我回电。当 PSP 完成处理后，它将调用 HTTP 请求来更新支付状态。
这样就改变了编程范式，支付服务不再需要浪费资源来轮询支付状态。
如果 PSP 不回电怎么办？我们可以设置一个内务工作来每小时检查付款状态。
Webhooks 通常称为反向 API 或推送 API，因为服务器向客户端发送 HTTP 请求。使用webhook时我们需要注意3件事：
- 我们需要设计一个合适的API供外部服务调用。
- 出于安全原因，我们需要在 API 网关中设置适当的规则。
- 我们需要在外部服务中注册正确的 URL。