关注小程序 找一找教程网-随时随地学编程

比较gRPC 服务和HTTP API

比较 gRPC 服务和 HTTP API

James 牛顿-k

本文介绍gRPC services如何与 HTTP api (包括 ASP.NET Core web api)进行比较。 用于为你的应用程序提供 API 的技术是一个重要的选择,gRPC 与 HTTP Api 相比具有独特的优势。 本文讨论 gRPC 的优势和劣势,并建议使用 gRPC 通过其他技术的方案。

高级别比较

下表提供了 gRPC 和 HTTP Api 与 JSON 之间功能的高级比较。

功能 gRPC 具有 JSON 的 HTTP Api
协定 必需(proto 可选(OpenAPI)
协议 HTTP/2 HTTP
Payload Protobuf (小,二进制) JSON (大、可读)
Prescriptiveness 严格规范 松散. 任何 HTTP 都有效。
流式传输 客户端、服务器、双向 客户端、服务器
浏览器支持 否(需要 grpc-web)
安全性 传输(TLS) 传输(TLS)
客户端代码生成 OpenAPI + 第三方工具

gRPC 强度

性能

使用Protobuf(一种高效的二进制消息格式)对 gRPC 消息进行序列化。 Protobuf 在服务器和客户端上的速度非常快。 Protobuf 序列化会导致小型消息负载,在有限的带宽方案(如移动应用)中非常重要。

gRPC 专用于 HTTP/2,这是一个主要的 HTTP 修订版,通过 HTTP 1.x 提供显著的性能优势:

  • 二进制组帧和压缩。 HTTP/2 协议在发送和接收时既简洁又高效。
  • 通过单个 TCP 连接对多个 HTTP/2 调用进行多路复用。 多路复用消除了行头阻塞

代码生成

所有 gRPC 框架都提供对代码生成的一流支持。 GRPC 开发的核心文件是一个proto 文件,用于定义 gRPC 服务和消息的协定。 从此文件 gRPC 框架将生成服务基类、消息和完整客户端。

通过在服务器和客户端之间共享proto文件,可以从端到端生成消息和客户端代码。 客户端代码生成将消除客户端和服务器上的重复消息,并为您创建一个强类型的客户端。 无需编写客户端,就可以在具有多个服务的应用程序中节省大量的开发时间。

严格规范

不存在具有 JSON 的 HTTP API 的正式规范。 开发人员会争论 Url、HTTP 谓词和响应代码的最佳格式。

GRPC 规范规定了 gRPC 服务必须遵循的格式。 gRPC 消除了对开发人员时间的争论,因为 gRPC 在平台和实现中保持一致。

流式传输

HTTP/2 为生存期较长的实时通信流奠定了基础。 gRPC 为通过 HTTP/2 进行流式处理提供一流支持。

GRPC 服务支持所有流式处理组合:

  • 一元(无流式处理)
  • 服务器到客户端流式处理
  • 客户端到服务器的流式处理
  • 双向流式处理

截止时间/超时和取消

gRPC 允许客户端指定它们等待 RPC 完成的时间。 截止时间发送到服务器,服务器可以决定在超过截止时间时要执行的操作。 例如,服务器可能会在超时时取消正在进行的 gRPC/HTTP/数据库请求。

通过子 gRPC 调用传播截止时间和取消有助于强制实施资源使用限制。

gRPC 适用于以下方案:

  • 微服务– gRPC 旨在实现低延迟和高吞吐量通信。 gRPC 非常适合轻型微服务,其中效率非常重要。
  • 点到点实时通信– gRPC 对双向流式处理提供了极佳支持。 gRPC services 无需轮询即可实时推送消息。
  • Polyglot 环境– gRPC 工具支持所有常用的开发语言,并为多语言环境提供 gRPC。
  • – gRPC 消息的网络约束环境使用 Protobuf (一种轻量消息格式)进行序列化。 GRPC 消息始终小于等效的 JSON 消息。

gRPC 弱点

受限制的浏览器支持

现在无法从浏览器直接调用 gRPC 服务。 gRPC 大量使用 HTTP/2 功能,并且没有浏览器提供 web 请求所需的控制级别,以支持 gRPC 客户端。 例如,浏览器不允许调用方要求使用 HTTP/2,或者提供对基础 HTTP/2 帧的访问。

gRPC是 gRPC 团队提供的一项额外技术,可在浏览器中提供有限的 gRPC 支持。 gRPC 由两部分组成:支持所有新式浏览器的 JavaScript 客户端和服务器上的 gRPC Web 代理。 GRPC 客户端调用代理,代理将在 gRPC 请求转发到 gRPC 服务器。

并非所有 gRPC 的功能都受 gRPC 支持。 不支持客户端和双向流式处理,并且对服务器流的支持是有限的。

用户不可读

HTTP API 请求以文本的形式发送,可由人读取和创建。

默认情况下,使用 Protobuf 对 gRPC 消息进行编码。 尽管 Protobuf 是发送和接收的高效,但其二进制格式不是用户可读的。 Protobuf 要求在proto文件中指定的消息接口说明正确地进行反序列化。 需要使用其他工具来分析线路上的 Protobuf 负载,并手动撰写请求。

诸如server 反射gRPC 命令行工具等功能可帮助进行二进制 Protobuf 消息。 此外,Protobuf 消息支持与 JSON 之间的转换 内置 JSON 转换提供了一种有效的方法,可在调试时将 Protobuf 消息转换为可读的形式。

备用框架方案

建议在以下情况中通过 gRPC 使用其他框架:

  • 浏览器不完全支持浏览器辅助功能 api – gRPC。 gRPC 可以提供浏览器支持,但它具有局限性并引入了服务器代理。
  • 广播实时通信– gRPC 支持通过流式处理进行实时通信,但将消息广播到注册连接的概念并不存在。 例如,在聊天室方案中,应将新的聊天消息发送到聊天室中的所有客户端,而每个 gRPC 调用都需要分别将新的聊天消息流式传输到客户端。 SignalR是此方案的有用框架。 SignalR 具有持续连接的概念和广播消息的内置支持。
  • 进程间的通信– 必须托管 HTTP/2 服务器以接受传入的 gRPC 调用。 对于 Windows,进程间通信管道是一种快速、轻量的通信方法。

其他资源