我正在学习gRPC。我知道当使用协议缓冲区发送消息时,消息的大小会减小。
// JSON - 55 bytes
{
"age": 35,
"first_name": "Stephane",
"last_name": "Marrek"
}协议缓冲区中的相同消息,
// Binary - 20 bytes
message Person {
int32 age = 1;
string first_name = 2;
string last_name = 3;
}发布于 2021-07-18 16:52:30
让我们从一个基本的角度来理解这一点。
gRPC是一种通过HTTP2.0协议实现RPC (远程过程调用) API的技术。这被广泛地用于构建微型服务,其中两个服务可以以更有效的方式相互交谈。协议缓冲区是一个IDL(接口定义语言),gRPC框架使用它来利用这个基础结构。这与我们在SOAP世界中看到的WSDL类似。
对于服务间的通信,我们通过有线传递消息.在更传统的情况下,我们遇到JSON、XML来在服务之间传输消息。这些类型的消息可以以基于文本的形式通过任何支持的HTTP协议传输。这些消息包含一个有效负载和一个标题。
在gRPC的情况下,它的协议缓冲区定义了消息格式和对这些消息进行编码和解码的机制。此消息是通过HTTP2.0传递的,这是一种二进制协议,意味着数据以二进制格式传输。是HTTP2.0下协议以二进制格式传输这些消息。在这里,消息不需要所有繁重的模式(与基于文本的JSON不同),所有的头都被压缩,这反过来减少了开销,减少了延迟,并提高了性能/吞吐量。
而gRPC为它奠定了所有的基础。它提供了编码和解码这些消息的机制。
摘要:因此,在gRPC的情况下,这些消息是通过HTTP2.0以二进制格式传输的,而对于JSON,这些消息是通过任何基于文本的HTTP协议传输的。
相比如何减小协议缓冲区的大小
正如我所解释的,在gRPC消息通信中,我们不需要与JSON不同的模式。这样就节省了所有的字节。您只需发送数据字节,在另一端,如果需要,gRPC框架将负责反序列化它。
gRPC具有二进制序列化/反序列化。这可真快。简单地说,你可以这样理解它。在基于文本的编码中,解码器首先将消息翻译成机器可读的格式,然后进行处理。在二进制数据的情况下,这种开销可以大大减少。
发布于 2021-07-18 14:34:13
JSON文档以某种UTF编码方式传输。通常UTF-8,但UTF16 BE和LE,以及UTF32 BE和LE是允许的.JSON是人类可读的文本。
由于字段名(age、first_name、last_name)是用JSON传输的,所以数据大小大多减少了。一个由10,000个字符串组成的数组的大小将非常小。
我有一个发布应用程序,在启动时读取大约10 MB的JSON数据。这在几年前的iPhone 4上是可以接受的。在现代iPhone上,一点汗水也没有。
Pro for JSON:无需使用任何工具,将任何第三方代码添加到应用程序中。没有计划的扩展非常灵活,因为JSON字面上描述了它包含的内容。使用JSON,除非您有证据表明使用协议缓冲区可以提高销售或节省您的钱。
https://stackoverflow.com/questions/68429813
复制相似问题