进行API开发选gRPC仍是HTTP APIs?

上一篇文章我带着你们体验了一把《ASP.NET Core 3.0 上的gRPC服务模板初体验(多图)》，若是有兴趣的能够点击连接进行查看，相信跟着作的你，也是能够跑起来的。这篇文章咱们将一块儿来探讨下gRPC服务如何与HTTP APIs进行比较。用于为应用程序提供API的技术是一个重要的选择，与HTTP API相比，gRPC提供了独特的优点。本文从gRPC的优缺点出发，并推荐了一些建议使用gRPC服务以及不建议使用gRPC服务的场景。

做者：依乐祝
原文连接：http://www.javashuo.com/article/p-vfomifku-kp.html

开始以前先看一下gRPC与带有j'son的HTTP APIs对比表格

gRPC的优点

性能

gRPC消息使用一种有效的二进制消息格式protobuf进行序列化。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动词和响应代码的最佳格式。（想一想，是用Post仍是Get好？使用Get仍是用Put好？一想到有选择恐惧症的你是否是又开了纠结，而后浪费了大量的时间）

该gRPC规范是规定有关gRPC服务必须遵循的格式。gRPC消除了争论并节省了开发人员的时间，由于gPRC在各个平台和实现之间是一致的。

流

HTTP/2为长期的实时通讯流提供了基础。gRPC经过HTTP/2为流媒体提供一流的支持。

gRPC服务支持全部流组合：

• 一元（没有流媒体）
• 服务器到客户端流
• 客户端到服务器流
• 双向流媒体

截至时间/超时和取消

gRPC容许客户端指定他们愿意等待RPC完成的时间。该期限被发送到服务端，服务端能够决定在超出了限期时采起什么行动。例如，服务器可能会在超时时取消正在进行的gRPC / HTTP /数据库请求。

经过子gRPC调用截至时间和取消操做有助于实施资源使用限制。

推荐使用gRPC的场景

gRPC很是适合如下场景：

• 微服务 - gRPC设计为低延迟和高吞吐量通讯。gRPC很是适用于效率相当重要的轻型微服务。
• 点对点实时通讯 - gRPC对双向流媒体提供出色的支持。gRPC服务能够实时推送消息而无需轮询。
• 多语言混合开发环境 - gRPC工具支持全部流行的开发语言，使gRPC成为多语言开发环境的理想选择。
• 网络受限环境 - 使用Protobuf（一种轻量级消息格式）序列化gRPC消息。gRPC消息始终小于等效的JSON消息。

gRPC的弱点

浏览器支持有限

当下，不可能直接从浏览器调用gRPC服务。gRPC大量使用HTTP/2功能，没有浏览器提供支持gRPC客户机的Web请求所需的控制级别。例如，浏览器不容许调用者要求使用的HTTP/2，或者提供对底层HTTP/2框架的访问。

gRPC Web是gRPC团队的一项附加技术，它在浏览器中提供有限的gRPC支持。gRPC Web由两部分组成：支持全部现代浏览器的JavaScript客户端和服务器上的gRPC Web代理。gRPC Web客户端调用代理，代理将在gRPC请求上转发到gRPC服务器。

gRPC Web并不是支持全部gRPC功能。不支持客户端和双向流，而且对服务器流的支持有限。

不是人类可读的

HTTP API请求以文本形式发送，能够由人读取和建立。

默认状况下，gRPC消息使用protobuf编码。虽然protobuf的发送和接收效率很高，但它的二进制格式是不可读的。protobuf须要在*.proto文件中指定的消息接口描述才能正确反序列化。须要额外的工具来分析线路上的Protobuf有效负载，并手工编写请求。

存在诸如服务器反射和gRPC命令行工具等功能，以帮助处理二进制protobuf消息。另外，Protobuf消息支持与JSON之间的转换。内置的JSON转换提供了一种有效的方法，能够在调试时将Protobuf消息转换为可读的形式。

不建议使用gRPC的场景

在如下场景中，建议使用其余框架而不是gRPC：

• 浏览器可访问的API - 浏览器不彻底支持gRPC。gRPC-Web能够提供浏览器支持，但它有局限性并引入了服务器代理。
• 广播实时通讯 - gRPC支持经过流媒体进行实时通讯，但不存在向已注册链接广播消息的概念。例如，在应该将新聊天消息发送到聊天室中的全部客户端的聊天室场景中，须要每一个gRPC呼叫以单独地将新的聊天消息流传输到客户端。对于这种场景，SignalR是这种状况的有用框架。SignalR具备持久链接的概念和对广播消息的内置支持。
• 进程间通讯 - 进程必须承载HTTP/2服务才能接受传入的gRPC调用。对于Windows，进程间通讯管道是一种快速，轻量级的通讯方法。

总结

继上一篇介绍了《ASP.NET Core 3.0 上的gRPC服务模板初体验(多图)》后，咱们又一块儿来探讨了一下gRPC服务的优缺点并给出了gRPC的一些使用场景以及非适用场景，但愿对你们的使用有所帮助。最后感谢你们的阅读。另外，文中大多内容来自于https://docs.microsoft.com/en-us/aspnet/core/gRPC/comparison?view=aspnetcore-3.0 有兴趣的小伙伴能够阅读原文进行查看。