网站gzip压缩,网站建设维护报价,创新建设资金网站,wordpress 社区插件gRPC
gRPC 是一个高性能、通用的开源 RPC 框架#xff0c;其由 Google 2015 年主要面向移动应用开发并基于 HTTP/2 协议标准而设计#xff0c;基于 ProtoBuf 序列化协议开发#xff0c;且支持众多开发语言。
由于是开源框架#xff0c;通信的双方可以进行二次开发#x…gRPC
gRPC 是一个高性能、通用的开源 RPC 框架其由 Google 2015 年主要面向移动应用开发并基于 HTTP/2 协议标准而设计基于 ProtoBuf 序列化协议开发且支持众多开发语言。
由于是开源框架通信的双方可以进行二次开发所以客户端和服务器端之间的通信会更加专注于业务层面的内容减少了对由 gRPC 框架实现的底层通信的关注。
如下图DATA 部分即业务层面内容下面所有的信息都由 gRPC 进行封装。 gRPC 的特点
跨语言使用支持 C、Java、Go、Python、Ruby、C#、Node.js、Android Java、Objective-C、PHP 等编程语言基于 IDL 文件定义服务通过 proto3 工具生成指定语言的数据结构、服务端接口以及客户端 Stub通信协议基于标准的 HTTP/2 设计支持双向流、消息头压缩、单 TCP 的多路复用、服务端推送等特性这些特性使得 gRPC 在移动端设备上更加省电和节省网络流量序列化支持 PBProtocol Buffer和 JSONPB 是一种语言无关的高性能序列化框架基于 HTTP/2 PB, 保障了 RPC 调用的高性能安装简单扩展方便用该框架每秒可达到百万个RPC。
gRPC调用模型 1、客户端gRPC Stub调用 A 方法发起 RPC 调用。
2、对请求信息使用 Protobuf 进行对象序列化压缩IDL。
3、服务端gRPC Server接收到请求后解码请求体进行业务逻辑处理并返回。
4、对响应结果使用 Protobuf 进行对象序列化压缩IDL。
5、客户端接受到服务端响应解码请求体。回调被调用的 A 方法唤醒正在等待响应阻塞的客户端调用并返回响应结果。 客户端与服务端是如何交互的 在建立连接之前客户端/服务端都会发送连接前言MagicSETTINGS确立协议和配置项。在传输数据时是会涉及滑动窗口WINDOW_UPDATE等流控策略的。传播 gRPC 附加信息时是基于 HEADERS 帧进行传播和设置而具体的请求/响应数据是存储的 DATA 帧中的。请求/响应结果会分为 HTTP 和 gRPC 状态响应两种类型。客户端发起 PING服务端就会回应 PONG反之亦可。 浅谈使用理解
RPC 流
在 RPC 架构下服务端Server定义了一组对外暴露的远程方法Remote Procedures。客户端Client通过生成对应的存根Stub来实现这些远程方法的本地代理。存根内包含与服务端远程方法相对应的函数签名从而使客户端能够通过本地调用来触发远程操作。操作流程如下
客户端通过存根Stub调用 getProduct 方法。客户端存根对传入的消息Message执行序列化操作并构建一个 HTTP POST 请求。在 gRPC 框架中这一请求遵application/grpc 的 content-type规范并将目标远程方法/ProductInfo/getProduct标记在 HTTP HeaderPath中。经构建的 HTTP POST 请求随后通过网络传输到服务端。服务端接收到消息后从 HTTP Header 解析出待调用的远程方法并将消息交由服务端存根Server Stub处理。服务端存根对收到的消息执行反序列化恢复为原始的数据结构。服务端本地执行 getProduct 方法其中反序列化后的消息作为输入参数。方法执行后服务端对返回结果进行序列化并以 HTTP 响应的形式返回给客户端。该响应的构建过程与客户端的请求构建过程相对应。客户端收到服务端的响应消息后进行反序列化操作并将解码后的数据提供给等待的客户端进程。 这些步骤与大多数 RPC 系统如 CORBA、Java RMI 等非常相似。gRPC 与它们之间的主要区别在于它对 message 进行编码的方式它使用 protocol buffer 进行编码。
Protocol Buffers Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. Protocol Buffers 是 Google 的一种语言中立、平台中立和可扩展的结构化数据序列化机制可以视为是更小、更快、更简单的 XML。您只需一次性定义数据结构然后可以使用特殊生成的源代码轻松地将结构化数据写入和读取出各种数据流并且支持多种编程语言。 你可以理解 ProtoBuf 是一种更加灵活、高效的数据格式与 XML、JSON 类似在一些高性能且对响应速度有要求的数据传输场景非常适用。
ProtoBuf 在 gRPC 的框架中主要有三个作用定义数据结构、定义服务接口通过序列化和反序列化方式提升传输效率。
为什么 ProtoBuf 会提高传输效率呢
我们知道使用 XML、JSON 进行数据编译时数据文本格式更容易阅读但进行数据交换时设备就需要耗费大量的 CPU 在 I/O 动作上自然会影响整个传输速率。Protocol Buffers 不像前者它会将字符串进行序列化后再进行传输即二进制数据。 接下来我们看下如何使用 protocol buffer 对消息进行编码。
使用 protocol buffer 定义服务包括定义服务中的远程方法和定义我们希望通过网络发送的消息。
仍以 ProductInfo 服务中的 getProduct 函数为例。该 getProduct 函数接受一个 ProductID 消息作为输入参数并返回一个 Product 消息。protocol buffer 定义如下
syntax proto3;package ecommerce;service ProductInfo {rpc getProduct(ProductID) returns (Product);
}message Product {string id 1;string name 2;string description 3;float price 4;
}message ProductID {string value 1;
}假设我们需要获取产品 ID 为 15 的产品详细信息我们创建一个值为 15 的 ProductID 消息并将其传递给 getProduct 函数。
product, err : c.GetProduct(ctx, pb.ProductID{Value: “15”})在下面的 ProductID 消息结构中有一个 value 字段其索引为 1。当我们创建一个 value 等于 15 的消息实例时生成的字节内容为该字段的字段标识符field identifiervalue 具体的编码值。字段标识符有时也称为标签tag
message ProductID {string value 1;
}字节内容结构如下图所示其中每个消息字段由一个标签值Tag和其编码值Value组成。
在 Protocol Buffers通常简称为 Protobuf中标签值Tag具有非常重要的作用它用于标识序列化数据流中的各个字段。
字段索引: 在 .proto 文件中每个字段都会有一个唯一的数字标识通常称为字段索引Field Index。这个数字是用于在序列化和反序列化过程中快速识别字段的。类型编号: 类型编号Type Identifier表明了该字段的数据类型例如int32, string等。这有助于解析器理解如何解码或解析这个字段。
标签值组合了这两部分信息字段索引和类型编号来生成一个唯一的标识符用于在序列化数据流中定位和解析字段。
在给定的 message ProductID { string value 1; } 示例中字段 value 的字段索引是 1。字符串类型string在 Protocol Buffers 中对应的类型标识符Wire Type是 2。为了生成标签值首先需要将字段索引左移 3 位然后将类型标识符添加到其中。 下表显示了字段类型如何映射到类型编号的 计算标签值
标签值 (字段索引 3) | 类型标识符 (1 3) | 2 8 | 2 10为什么使用左移 3 位 3这个设计选择允许 3 位用于类型标识符Wire Type。左移 3 位是为了在标签值中留出空间来存储类型标识符。类型标识符是一个 0 到 7 的值正好可以用 3 位二进制数来表示。这样通过字段索引左移 3 位后最低的 3 位就可以用来存储类型标识符。这种设计方式实现了一个紧凑、高效的编码方案同时也提供了足够的信息来解析序列化后的数据。 在Protocol Buffers中变长整数Varints采用一种特殊的编码方式使得较小的数值可以用较少的字节表示。具体来说每个字节的最低7位用于存储整数的实际数值而最高位第8位用于标记是否还有更多字节。如果最高位是1那么表示该整数还有后续字节如果最高位是0那么表示这是该整数的最后一个字节。 字符串通常使用一种称为Length-delimited的编码方式。这种方法也适用于字节串byte arrays和嵌套消息。
前缀长度:在实际的字符串内容之前会有一个变长整数Varint来表示接下来的字符串或字节串或嵌套消息的长度。这个变长整数是使用Protocol Buffers的Varint编码方式进行编码的。字符串内容:紧接着前缀长度的是字符串的实际内容它是以原始字节形式存在的。这些字节的数量与前缀长度中指定的数值相匹配。解码:在解码阶段首先会读取前缀长度它本身是一个Varint可以用一个或多个字节表示。解码器然后会知道接下来要读取多少字节来获取完整的字符串或字节串。
当然让我给出一个简单的例子以说明如何使用Length-delimited编码方式来编码字符串。假设我们有一个字符串hello。计算长度: 字符串hello包含5个字符因此其长度是5。编码长度: 使用Protocol Buffers的Varint编码方式我们将这个长度数字即5编码为一个变长整数。在这个特定的情况下5是一个小的数值所以它可以用单个字节来表示0b00000101。字符串内容: hello的ASCII编码分别是0x68 0x65 0x6C 0x6C 0x6F组合: 最后我们将编码后的长度和实际的字符串内容组合起来0b00000101 0x68 0x65 0x6C 0x6C 0x6F所以按照Length-delimited编码方式字符串hello将被编码为05 68 65 6C 6C 6F以十六进制表示。从上面的介绍我们得出在编码方面 Protocol Buffers 对比 JSON、XML 的优点
标准的 IDL 和 IDL 编译器这使得其对工程师非常友好序列化数据非常简洁紧凑与 XML 相比其序列化之后的数据量约为 1/3 到 1/10解析速度非常快比对应的 XML 快约 20-100 倍提供了非常友好的动态库使用非常简单反序列化只需要一行代码。
Protobuf 也有其局限性
二进制格式导致可读性差不具备自描述能力
Protobuf 适用场景
Protobuf 具有广泛的用户基础空间开销小以及高解析性能是其亮点非常适合于公司内部的对性能要求高的 RPC 调用由于 Protobuf 提供了标准的 IDL 以及对应的编译器其 IDL 文件是参与各方的非常强的业务约束Protobuf 与传输层无关采用 HTTP 具有良好的跨***的访问属性所以 Protobuf 也适用于公司间对性能要求比较高的场景由于其解析性能高序列化后数据量相对少非常适合应用层对象的持久化场景 长度前缀消息帧
在 gRPC 通信协议中采用了长度前缀消息帧Length-Prefixed Message Framing机制来进行数据打包和传输。具体来说每个编码后的消息体前会附加一个 4 字节的字段用于标识接下来的消息体的字节长度。
这种机制提供了一种有效的方式来界定消息的边界从而允许接收方进行准确和高效的消息解析。由于长度字段由 4 字节表示因此理论上最大可支持的消息体尺寸为 2 32 − 1 2^{32} - 1 232−1 字节即近 4 GB。
这样的设计旨在实现高效的流解析和处理同时也支持消息体的动态长度进一步提升了通信协议的灵活性和可扩展性。 假设我们有一个简单的 gRPC 服务其中有一个名为 GetUserInfo 的远程调用用于获取用户信息。当客户端要获取用户 ID 为 123 的用户信息时该调用的消息体已序列化和编码可能是一个二进制字符串例如 0x12 0x07 0x55 0x73 0x65 0x72 0x31 0x32 0x33这只是一个假设的二进制表示。在这种情况下消息体的长度为 9 字节。 长度前缀添加在这个二进制消息体前gRPC 会添加一个 4 字节的长度字段。假设长度用大端字节序表示则该字段可能是 0x00 0x00 0x00 0x09。 完整的消息帧添加了长度前缀后完整的消息帧将变为 0x00 0x00 0x00 0x09 0x12 0x07 0x55 0x73 0x65 0x72 0x31 0x32 0x33。 发送到服务器这个长度为 13 字节的消息帧将通过网络发送到 gRPC 服务器。 服务器解析服务器首先读取前 4 字节0x00 0x00 0x00 0x09解析出消息体的长度为 9 字节。然后服务器会读取接下来的 9 字节作为完整的消息体进行解码和处理。 这样通过使用长度前缀消息帧gRPC 能够准确地界定每个消息体的开始和结束从而实现高效和准确的消息解析。 除了消息大小之外消息帧还会预留一个 1 字节的无符号整数来指示数据是否被压缩。Compressed-Flag 值为 1 表示二进制数据使用 Message-Encoding 标头中声明的压缩方式进行压缩值 0 表示没有对消息字节进行压缩。
现在消息已装帧并准备好通过网络发送给对应的处理方。对于 client 端请求消息接收者是 server。对于响应消息接收者是 client 端。在接收端一旦收到一条消息首先需要读取第一个字节检查消息是否被压缩。然后读取接下来的四个字节以获取二进制消息的大小。一旦知道大小就可以从消息流中读取具体的消息了。对于简单消息我们只需处理一条带长度前缀的消息而对于流式消息我们需要处理多条带长度前缀的消息。
在gRPC和Protocol Buffers的上下文中长度前缀消息帧Length-Prefixed Message Framing与字段的三部分字段编号Tag、类型、编码值是两个在不同层次上应用的编码机制它们不会互相矛盾。长度前缀消息帧这是一种更为底层的打包方式通常用在gRPC的传输层。这里的4字节长度前缀用于标识接下来整个消息体即一个完整的Protocol Buffers消息的长度。这不仅包括字段的编码值还包括每个字段的标签和类型信息。这样收到消息的一方知道要读取多少字节来获取完整的消息。字段的三部分编码这是Protocol Buffers内部的编码机制。在这里每个字段都被编码为标签、类型和值。这三者都包含在上面提到的长度前缀消息帧内。由于这两个机制作用在不同的层次因此不会有矛盾。具体来说长度前缀消息帧为整个Protocol Buffers消息提供一个“外壳”而字段的三部分编码则是这个“外壳”内部的内容。关于顺序性的问题实际上字段的三部分标签、类型、编码值总是作为一个整体连续存储和传输的。也就是说一个字段的标签、类型和值会连续出现在数据流中然后才是下一个字段的标签、类型和值。这种连续性由Protocol Buffers的编码和解码算法来保证。综上所述长度前缀消息帧和字段的三部分编码各自在不同的层面起作用两者可以和谐共存不会出现顺序或界定的问题。长度前缀是针对整个消息体而字段的标签、类型和编码值是针对消息体内部的各个字段。这样设计确保了数据传输的高效和准确。思考下长度前缀消息帧是否会失序
在gRPC和大多数基于TCP的通信协议中数据的顺序性是由底层的TCP协议保证的。TCP是一个面向连接的、可靠的、字节流协议它确保所有的字节都会按照发送的顺序到达接收端。
长度前缀消息帧在这种上下文中是作为一个整体发送的即4字节的长度前缀和跟随的消息体由长度前缀指定的长度会作为一个整体在网络上传输。由于TCP保证了数据的顺序性和完整性因此不会出现长度前缀和消息体之间、或不同消息之间的失序问题。
这样的设计确保了在从底层TCP流中读取数据并解析成gRPC消息时能够正确地识别每个消息的边界并按照正确的顺序处理它们。
简言之长度前缀消息帧在gRPC通信中不会失序这是由底层的TCP协议保证的。这也是为什么gRPC可以作为一个高性能、可靠的RPC框架被广泛使用的原因之一。 基于 HTTP/2 的 gRPC
除了 Protocol Buffers 之外从交互图中和分层框架可以看到 gRPC 还有另外一个优势——它是基于 HTTP 2.0 协议的。由于 gRPC 基于 HTTP 2.0 标准设计带来了更多强大功能如多路复用、二进制帧、头部压缩、推送机制。 这些功能给设备带来重大益处如节省带宽、降低 TCP 连接次数、节省 CPU 使用等gRPC 既能够在客户端应用也能够在服务器端应用从而以透明的方式实现两端的通信和简化通信系统的构建。 HTTP 1.X 定义了四种与服务器交互的方式分别为 GET、POST、PUT、DELETE这些在 HTTP 2.0 中均保留我们看看 HTTP 2.0 的新特性双向流、多路复用、二进制帧、头部压缩。
跟其他的相比
XML序列化Xstream无论在性能和简洁性上比较差。Thrift 与 Protobuf 相比在时空开销方面都有一定的劣势。Protobuf 和 Avro 在两方面表现都非常优越。
如下图所示gRPC Channel 表示 client 端与 server 端之间的连接即 HTTP/2 连接。当 client 端创建 gRPC Channel 时它会在后台创建与 server 端的 HTTP/2 连接。创建好 Channel 后我们可以重用它来向 server 端发送多个远程调用这些远程调用会映射到 HTTP/2 的流中。在远程调用中发送的消息以 HTTP/2 帧的形式发送。一个帧可能携带一个 gRPC 长度前缀消息如果一个 gRPC 消息非常大它可能跨越多个数据帧。 在gRPC中Channel是一个抽象概念它代表了客户端client与服务端server之间的一个连接。具体来说它封装了底层的HTTP/2连接以及其他与连接相关的状态信息。Channel负责管理底层连接的建立、维护以及关闭并提供了一种简单的方式来进行远程过程调用RPC。 在上一节中我们讨论了如何将我们的消息帧转为以长度为前缀的消息。当我们通过网络将它们作为请求或响应消息发送时我们需要随消息一起发送额外的 HTTP 头。下面我们看看如何构造请求 / 响应消息以及需要为每条消息传递哪些标头。
请求消息
请求消息是发起远程调用的消息。在 gRPC 中请求消息总是由 client 端应用程序触发它由三个主要部分组成请求头、长度前缀消息和流结束标志如下图所示。client 端首先发送请求头之后是长度前缀消息最后是 EOS标识消息发送完毕。
下面仍以 ProductInfo 服务中的 getProduct 函数为例来解释请求消息是如何在 HTTP/2 帧中发送的。 当我们调用该 getProduct 函数时client 端会发送以下请求头
HEADERS (flags END_HEADERS):method POST
:scheme http
:path /ProductInfo/getProduct
:authority abc.com
te trailers
grpc-timeout 1S
content-type application/grpc
grpc-encoding gzip
authorization Bearer xxxxxx :method设置 HTTP 方法。对于 gRPC:method 标头始终为 POST.
:scheme设置 HTTP 协议。如果启用了 TLS则协议设置为 “https”否则为 “http”。
:path设置终端路径。对于 gRPC此值构造为 “/{服务名称}/{方法名称}”。
:authority设置目标 URI 的虚拟主机名。
te设置不兼容代理的检测。对于 gRPC该值必须是 “trailers”。
grpc-timeout设置调用超时时常。如果未指定server 端应假定无限超时。
content-type设置内容类型。对于 gRPC内容类型应以 application/grpc. 如果没有gRPC server 会响应 HTTP 状态 415不支持的媒体类型。
grpc-encoding设置消息压缩方式。可能的值为 identity、gzip、deflate、snappy 及自定义压缩方式。
authorization这是可选的请求头用于访问又安全限制的终端服务。
一旦 client 端发起与 server 端的调用client 端就会以 HTTP/2 数据帧的形式发送带有长度前缀的消息。如果一个数据帧无法放下长度前缀消息它可以跨越多个数据帧。通过在最后一个数据帧上添加一个 END_STREAM 标志来标识请求消息的结束。当没有数据要发送但我们需要关闭请求流时我们需要发送一个带有 END_STREAM 标志的空数据帧
DATA (flags END_STREAM)响应消息
响应消息由 server 端响应 client 端的请求而生成。与请求消息类似在大多数情况下响应消息也由三个主要部分组成响应标头、带长度前缀的消息和尾部。当响应中没有以长度为前缀的消息需要发送给 client 端时响应消息仅包含响应标头和尾部。 继续回到上一个例子。当 server 端向 client 端发送响应时它首先发送响应头如下所示
HEADERS (flags END_HEADERS):status 200
grpc-encoding gzip
content-type application/grpc :status标识 HTTP 请求的状态。
grpc-encoding设置消息压缩类型。可能的值包括 identity、gzip、deflate、snappy 和自定义类型。
content-type设置内容类型。对于 gRPCcontent-type 应该设置为 application/grpc。
一旦 server 端发送完响应标头就会以 HTTP/2 数据帧的形式发送带有长度前缀的消息。与请求消息类似如果一个数据帧无法放下长度前缀消息它可以跨越多个数据帧
DATA
与请求消息不同的是END_STREAM 标志不随数据帧一起发送它作为一个单独的响应头发送被称作 Trailers通知 client 端我们完成了响应消息的发送。Trailers 还会携带请求的状态码和状态消息
HEADERS (flags END_STREAM, END_HEADERS)
grpc-status 0 # OK
grpc-message xxxxxx grpc-status gRPC 状态代码。可以参考 gRPC 官方文档查找状态码的定义。 grpc-message错误描述。这是可选的仅在处理请求出现错误时设置。
在某些情况下请求调用可能会立即失败。在这些情况下server 端需要在没有数据帧的情况下发回响应。此时server 端只会发送 Trailers 作为响应。
关于gRPC的通信方式在下一个章节中会介绍。
