【通讯协议】gRPC和Webhook

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 的通信。

1. 短轮询

支付服务向PSP发送支付请求后，不断向PSP询问支付状态。经过几轮之后，PSP终于返回状态。

短轮询有两个缺点：

2. 网络钩子

我们可以向外部服务注册一个 webhook。这意味着：当您有请求更新时，通过某个 URL 给我回电。当 PSP 完成处理后，它将调用 HTTP 请求来更新支付状态。

这样就改变了编程范式，支付服务不再需要浪费资源来轮询支付状态。

如果 PSP 不回电怎么办？我们可以设置一个内务工作来每小时检查付款状态。

Webhooks 通常称为反向 API 或推送 API，因为服务器向客户端发送 HTTP 请求。使用webhook时我们需要注意3件事：