RESTful API和gRPC是两种常用的远程调用方式，但在某些对性能要求较高的场景，我还是选择了gRPC，本篇简单聊聊。
为什么是gRPC
选择gRPC作为远程调用方式，在对性能要求高的场景中是一个非常不错的选择。gRPC在性能方面，我梳理了以下几点优势：
1. 高性能的通信协议：
gRPC使用HTTP/2作为底层通信协议，相对于传统的HTTP/1.1协议，HTTP/2具有更低的延迟和更高的吞吐量。它支持多路复用、头部压缩、服务器推送等特性，可以更有效地利用网络资源，提高传输效率。
2. 二进制数据序列化：
gRPC使用Protocol Buffers（protobuf）作为默认的数据序列化机制，它是一种高效的二进制格式。相对于文本格式（比如我们非常熟悉的JSON），二进制格式在传输和解析时更快，数据体积更小，节省了带宽和CPU资源。
3. 强类型定义：
gRPC使用IDL文件定义服务和消息类型，生成对应的代码，提供了强类型的接口和数据结构。这可以确保数据的一致性和类型安全，避免了因为数据格式不一致而引起的错误。
4. 支持流式数据传输：
gRPC支持基于流的数据传输，即客户端和服务器可以建立双向流，实现流式的数据交换。这在需要实时数据传输、流式处理或长连接场景下非常有用。
序列化格式：protobuf和JSON的区别（关键点）
-
数据体积：
-
protobuf：二进制格式，数据体积更小，传输效率更高。 -
JSON：文本格式，可读性较好，但数据体积较大。
-
解析效率：
-
protobuf：二进制编码，解析效率高。 -
JSON：文本格式，涉及解析和转换，效率低。
-
可读性：
-
JSON：明文字符表示数据，可读性好 -
protobuf：二进制格式，不可读，需要通过专门的工具或库来解析和查看数据。
-
类型系统：
-
protobuf：强类型定义，可以在IDL文件中明确定义消息结构和字段类型，并且生成对应的代码。确保数据的一致性和类型安全。 -
JSON：动态类型的格式，不强制要求定义数据结构和类型。
-
兼容性：
-
protobuf：版本升级困难，因为使用预定义的消息结构和字段，需要重新生成代码并进行升级。 -
JSON：兼容性好，因为是动态格式，可以适应字段的增删改。
最后
需要注意的是，选择了gRPC，那么意味着开发和部署的复杂性也提高了。所以，在评估选择时，请慎重哈！
原文始发于微信公众号（不背锅运维）：为什么是gRPC
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/149384.html
