我的开源
其它资源
友链申请
为什么要在微服务中使用Grpc？ 置顶！
1、HTTP与Grpc的比较
gRPC与带有json的HTTP APIs对比。Grpc具备性能，严格的规范，流等优势，适合用于微服务的场景，但是浏览器支持受限切不可读，不适用于对外的服务提供。所以采用HTTP+Grpc方案。
2、Grpc优势
2.1、性能
gRPC消息使用一种有效的二进制消息格式protobuf进行序列化。Protobuf在服务器和客户机上的序列化非常快。Protobuf序列化后的消息体积很小，能够有效负载，在移动应用程序等有限带宽场景中显得很重要。
gRPC是为HTTP/2而设计的，它是HTTP的一个主要版本，与HTTP 1.x相比具有显著的性能优势：
- 二进制框架和压缩。HTTP/2协议在发送和接收方面都很紧凑和高效。
- 通过单个TCP连接复用多个HTTP/2调用。多路复用消除了线头阻塞。
2.2 、代码生成
所有gRPC框架都为代码生成提供了一流的支持。gRPC开发的核心文件是*.proto文件 ，它定义了gRPC服务和消息的约定。根据这个文件，gRPC框架将生成服务基类，消息和完整的客户端代码。
通过在服务器和客户端之间共享*.proto文件，可以从端到端生成消息和客户端代码。客户端的代码生成消除了客户端和服务器上的重复消息，并为您创建了一个强类型的客户端。无需编写客户端代码，可在具有许多服务的应用程序中节省大量开发时间。
2.3 、严格的规范
不存在具有JSON的HTTP API的正式规范。开发人员不需要讨论URL，HTTP动词和响应代码的最佳格式。（想想，是用Post还是Get好？使用Get还是用Put好？一想到有选择恐惧症的你是不是又开了纠结，然后浪费了大量的时间）
该gRPC规范是规定有关gRPC服务必须遵循的格式。gRPC消除了争论并节省了开发人员的时间，因为gPRC在各个平台和实现之间是一致的。
2.4、流
HTTP/2为长期的实时通信流提供了基础。gRPC通过HTTP/2为流媒体提供一流的支持。
gRPC服务支持所有流组合：
- 一元（没有流媒体）
- 服务器到客户端流
- 客户端到服务器流
- 双向流媒体
2.5 、截至时间/超时和取消
gRPC允许客户端指定他们愿意等待RPC完成的时间。该期限被发送到服务端，服务端可以决定在超出了限期时采取什么行动。例如，服务器可能会在超时时取消正在进行的gRPC / HTTP /数据库请求。
通过子gRPC调用截至时间和取消操作有助于实施资源使用限制。
3 、推荐使用gRPC的场景
gRPC非常适合以下场景：
- 微服务 - gRPC设计为低延迟和高吞吐量通信。gRPC非常适用于效率至关重要的轻型微服务。
- 点对点实时通信 - gRPC对双向流媒体提供出色的支持。gRPC服务可以实时推送消息而无需轮询。
- 多语言混合开发环境 - gRPC工具支持所有流行的开发语言，使gRPC成为多语言开发环境的理想选择。
- 网络受限环境 - 使用Protobuf（一种轻量级消息格式）序列化gRPC消息。gRPC消息始终小于等效的JSON消息。
4、gRPC的弱点
4.1、浏览器支持有限
当下，不可能直接从浏览器调用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功能。不支持客户端和双向流，并且对服务器流的支持有限。
4.2、不是人类可读的
HTTP API请求以文本形式发送，可以由人读取和创建。
默认情况下，gRPC消息使用protobuf编码。虽然protobuf的发送和接收效率很高，但它的二进制格式是不可读的。protobuf需要在*.proto文件中指定的消息接口描述才能正确反序列化。需要额外的工具来分析线路上的Protobuf有效负载，并手工编写请求。
存在诸如服务器反射和gRPC命令行工具等功能，以帮助处理二进制protobuf消息。另外，Protobuf消息支持与JSON之间的转换。内置的JSON转换提供了一种有效的方法，可以在调试时将Protobuf消息转换为可读的形式。
4.3、不建议使用gRPC的场景
在以下场景中，建议使用其他框架而不是gRPC：
- 浏览器可访问的API - 浏览器 不完全支持gRPC。gRPC-Web可以提供浏览器支持，但它有局限性并引入了服务器代理。
- 广播实时通信 - gRPC支持通过流媒体进行实时通信，但不存在向已注册连接广播消息的概念。例如，在应该将新聊天消息发送到聊天室中的所有客户端的聊天室场景中，需要每个gRPC呼叫以单独地将新的聊天消息流传输到客户端。对于这种场景，SignalR是这种情况的有用框架。SignalR具有持久连接的概念和对广播消息的内置支持。
- 进程间通信 - 进程必须承载HTTP/2服务才能接受传入的gRPC调用。对于Windows，进程间通信管道是一种快速，轻量级的通信方法。
5 、Grpc在K8S容器环境下的机制
Grpc客户端在K 8 S环境下使用consul进行服务发现 ：无需考虑配置地址等信息。
对于运行于非同一个K 8 S环境的下场景，例如当前生产环境调用中台的场景： 不使用consul，通过配置静态配置走NodePort方式进行访问，依旧具备高可用。
标题：为什么要在微服务中使用Grpc？
作者：mmzsblog
地址：https://www.mmzsblog.cn/articles/2022/03/28/1648447789035.html
如未加特殊说明，文章均为原创，转载必须注明出处。均采用CC BY-SA 4.0 协议！
本网站发布的内容（图片、视频和文字）以原创、转载和分享网络内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。若本站转载文章遗漏了原文链接，请及时告知，我们将做删除处理！文章观点不代表本网站立场，如需处理请联系首页客服。• 网站转载须在文章起始位置标注作者及原文连接，否则保留追究法律责任的权利。
• 公众号转载请联系网站首页的微信号申请白名单！
