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的区别（关键点）

1. 数据体积：

• protobuf：二进制格式，数据体积更小，传输效率更高。
• JSON：文本格式，可读性较好，但数据体积较大。

1. 解析效率：

• protobuf：二进制编码，解析效率高。
• JSON：文本格式，涉及解析和转换，效率低。

1. 可读性：

• JSON：明文字符表示数据，可读性好
• protobuf：二进制格式，不可读，需要通过专门的工具或库来解析和查看数据。

1. 类型系统：

• protobuf：强类型定义，可以在IDL文件中明确定义消息结构和字段类型，并且生成对应的代码。确保数据的一致性和类型安全。
• JSON：动态类型的格式，不强制要求定义数据结构和类型。

1. 兼容性：

• protobuf：版本升级困难，因为使用预定义的消息结构和字段，需要重新生成代码并进行升级。
• JSON：兼容性好，因为是动态格式，可以适应字段的增删改。

最后

需要注意的是，选择了gRPC，那么意味着开发和部署的复杂性也提高了。所以，在评估选择时，请慎重哈！