zoukankan      html  css  js  c++  java
  • 【转载】 进行API开发选gRPC还是HTTP APIs

    https://www.cnblogs.com/yilezhu/p/10645804.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 有兴趣的小伙伴可以阅读原文进行查看。

  • 相关阅读:
    [JSOI2007][BZOJ1031] 字符加密Cipher|后缀数组
    leetcode Flatten Binary Tree to Linked List
    leetcode Pascal's Triangle
    leetcode Triangle
    leetcode Valid Palindrome
    leetcode Word Ladder
    leetcode Longest Consecutive Sequence
    leetcode Sum Root to Leaf Numbers
    leetcode Clone Graph
    leetcode Evaluate Reverse Polish Notation
  • 原文地址:https://www.cnblogs.com/exmyth/p/14771037.html
Copyright © 2011-2022 走看看