【微服务架构】Protocol Buffer序列化原理解析

已于 2023-10-14 21:48:04 修改
阅读量2.5k 收藏 7
点赞数
分类专栏： 架构 后端开发 文章标签： 微服务 架构
于 2022-11-14 16:19:01 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43746433/article/details/127849767
版权

文章目录

protobuf定义

Protocol Buffer是Google出品的数据传输协议，目前已经广泛用于客户端和服务器之间的数据交互

作用

通过将 结构化的数据 进行 串行化（序列化），从而实现 数据存储 / RPC 数据交换的功能

序列化： 将 数据结构或对象 转换成 二进制串 的过程
反序列化：将在序列化过程中所生成的二进制串 转换成 数据结构或者对象 的过程

在这里插入图片描述

特点

在这里插入图片描述

protobuffer 为什么高效

  • 序列化数据时，不序列化key的name，使用key的编号替代，减小数据
    例如定义如下数据结构：

    message SearchRequest {
  string query = 1;
  int32 page_number = 2;
  int32 result_per_page = 3;
}

    在这里插入图片描述

    上述数据在序列化时，query,page_number以及result_per_page的key不会参与，由编号1,2,3替代，这样在反序列的时候可以直接通过编号找到对应的key，这样做确实可以减小传输数据，但是编号一旦确定就不可更改

  • 没有赋值的key，不参与序列化
    序列化时只会对赋值的key进行序列化，没有赋值的不参与，在反序列化的时候直接给默认值即可

  • 可变长度编码
    可变长度编码，主要缩减整数占用字节实现，例如java中int占用4个字节，但是大多数情况下，我们使用的数字都比较小，使用1个字节就够了，这就是可变长度编码完成的事

  • TLV
    TLV全称为Tag_Length_Value，其中Tag表示后面数据的类型，Length不一定有，根据Tag的值确定，Value就是数据了，TLV表示数据时，减少分隔符的使用，更加紧凑
    在这里插入图片描述

http rpc对比

编（解）码层

HTTP/1.1

  • 序列化协议：JSON
    • 额外空间开销大，没有类型，开发时需要通过反射统一解决。
      在这里插入图片描述

RPC

  • 序列化协议：以 gRPC 为代表的 Protobuf，其他也类似
    • 序列化后的体积比 JSON 小 ⇒ 传输效率高
    • 序列化、反序列化速度快，开发时不需要通过反射 ⇒ 性能消耗低
    • IDL 描述语义比较清晰。

通信协议约定

基于 TCP 传输，都会有消息头和消息体，区别在于消息头

HTTP/1.1

  • 优点是灵活，可以自定义很多字段。
  • 缺点是包含许多为了适应浏览器的冗余字段，这些是内部服务用不到的。

RPC

  • 可定制化，自定义必要字段即可。
  • 可摒弃很多 HTTP Header 中的字段，比如各种浏览器行为。

网络传输层

  • HTTP/1.1
    • 建立一个 TCP 长连接，设置 keep-alive 长时间复用这个连接。
    • 框架中会引入成熟的网络库，给 HTTP 加连接池，保证不只有一个 TCP 连接可用。
  • RPC
    • 建立 TCP 连接池，框架也会引入成熟网络库来提高传输性能。
    • gRPC 基于 HTTP/2，拥有多路复用、优先级控制、头部压缩等优势。

序列化速度 & 反序列化速度快

Protocol Buffer 反序列化直接读取二进制字节数据流，反序列化就是 encode
的反过程，同样是一些二进制操作。

RPC 的优势和不足

优势

  • 相较于 HTTP/1.1，数据包更小、序列化更快，所以传输效率很高。
  • 基于 TCP 或 HTTP/2 的自定义 RPC 协议，网络传输性能比 HTTP/1.1 更快。
  • 适用于微服务架构，微服务集群下，每个微服务职责单一，有利于多团队的分工协作。

不足

  • RPC 协议本身无法解决微服务集群的问题，例如：服务发现、服务治理等，需要工具来保障服务的稳定性。
  • 调用方对服务端的 RPC 接口有强依赖关系，需要有自动化工具、版本管理工具来保证代码级别的强依赖关系。例如，stub 桩文件需要频繁更新，否则接口调用方式可能出错。

https://zhuanlan.zhihu.com/p/101783606

在这里插入图片描述
序列化 / 反序列化 属于 TCP/IP模型 应用层 和 OSI`模型 展示层的主要功能：

（序列化）把 应用层的对象 转换成 二进制串
（反序列化）把 二进制串 转换成 应用层的对象
所以， Protocol Buffer属于 TCP/IP模型的应用层 & OSI模型的展示层

pb二进制数据流 实现原理

Protocol Buffer 序列化采用 Varint、Zigzag 方法，压缩 int 型整数和带符号的整数。对浮点型数字不做压缩(这里可以进一步的压缩，Protocol Buffer 还有提升空间)。编码 .proto 文件，会对 option 和 repeated 字段进行检查，若 optional 或 repeated 字段没有被设置字段值，那么该字段在序列化时的数据中是完全不存在的，即不进行序列化（少编码一个字段）。

上面这两点做到了压缩数据，序列化工作量减少。

序列化的过程都是二进制的位移，速度非常快。数据都以 tag - length - value (或者 tag -value)的形式存在二进制数据流中。采用了 TLV 结构存储数据以后，也摆脱了 JSON 中的 {、}、;、这些分隔符，没有这些分隔符也算是再一次减少了一部分数据。

数据结构

Protocol Buffer的数据组成方式为TLV，数据结构图如下：

在这里插入图片描述

其中Length不一定有，依据Tag确定，例如int类型的数据就只有Tag-Value，string类型的数据就必须是Tag-Length-Value

数据类型

在这里插入图片描述

tag

Tag块包含两块内容：数据编号、数据类型，Tag的生成规则如下：

(field_number << 3) | wire_type

其中Tag块的后3位表示数据类型，其他位表示数据编号

如00001｜010,

file_num = 0001 = 1
type = 010 = 2

type=2，则后面有Length

可变长度编码

Java中整数类型的长度都是确定的，如int类型的长度为4个字节，可表示的整数范围为-231——231-1，但是实际开发中用到的数字均比较小，会造成字节浪费，可变长度编码就能很好的解决这个问题，可变长度编码规则如下：

字节最高位表示数据是否结束，如果最高位为1，则表示后面的字节也是该数据的一部分, 如果最高位为0，则表示数据计算终止

举个例子：

在这里插入图片描述

其中第一个字节由于最高位为1，则后面的字节也是前面的数据的一部分，第二个字节最高位为0，则表示数据计算终止，由于Protocol Buffer是低位在前，整体的转换过程如下：
在这里插入图片描述

10000001 00000011 ——> 00000110000001
表示的10进制数为：2^0 + 2^7 + 2^8 = 385

通过上面的例子可以知道一个字节表示的数的范围0-128，上面介绍的Tag生成算法中由于后3位表示数据类型，所以Tag中1-15编号只占用1个字节，所以确保编号中1-15为常用的，减少数据大小

可变长度编码唯一的缺点就是当数很大的时候int32需要占用5个字节，但是从统计学角度来说，一般不会有这么大的数

案例分析

https://juejin.cn/post/6844903997292150791

总结：

  • 序列化的时候，不序列化key的name，只序列化key的编号
  • 序列化的时候，没有赋值的key，不参与序列化，反序列化的时候直接使用默认值填充
  • 可变长度编码，减小字节占用
  • TLV编码，去除没有的符号，使数据更加紧凑

Protocol Buffers 生成pb.go都有什么？

syntax = "proto3";

package proto;

service SearchService {
    rpc Search(SearchRequest) returns (SearchResponse) {}
}

message SearchRequest {
    string request = 1;
}

message SearchResponse {
    string response = 1;
}

$ protoc --go_out=plugins=grpc:. *.proto
执行完毕命令后，将得到一个 .pb.go 文件，文件内容如下：

type SearchRequest struct {
    Request              string   `protobuf:"bytes,1,opt,name=request" json:"request,omitempty"`
    XXX_NoUnkeyedLiteral struct{} `json:"-"`
    XXX_unrecognized     []byte   `json:"-"`
    XXX_sizecache        int32    `json:"-"`
}

func (m *SearchRequest) Reset()         { *m = SearchRequest{} }
func (m *SearchRequest) String() string { return proto.CompactTextString(m) }
func (*SearchRequest) ProtoMessage()    {}
func (*SearchRequest) Descriptor() ([]byte, []int) {
    return fileDescriptor_search_8b45f79ee13ff6a3, []int{0}
}

func (m *SearchRequest) GetRequest() string {
    if m != nil {
        return m.Request
    }
    return ""
}

通过阅读这一部分代码，可以知道主要涉及如下方面：

  • 字段名称从小写下划线转换为大写驼峰模式（字段导出）
  • 生成一组 Getters 方法，能便于处理一些空指针取值的情况
  • ProtoMessage 方法实现 proto.Message 的接口
  • 生成 Rest 方法，便于将 Protobuf 结构体恢复为零值
  • Repeated 转换为切片
type SearchRequest struct {
    Request              string   `protobuf:"bytes,1,opt,name=request" json:"request,omitempty"`
}

func (*SearchRequest) Descriptor() ([]byte, []int) {
    return fileDescriptor_search_8b45f79ee13ff6a3, []int{0}
}

type SearchResponse struct {
    Response             string   `protobuf:"bytes,1,opt,name=response" json:"response,omitempty"`
}

func (*SearchResponse) Descriptor() ([]byte, []int) {
    return fileDescriptor_search_8b45f79ee13ff6a3, []int{1}
}

...

func init() { proto.RegisterFile("search.proto", fileDescriptor_search_8b45f79ee13ff6a3) }

var fileDescriptor_search_8b45f79ee13ff6a3 = []byte{
    // 131 bytes of a gzipped FileDescriptorProto
    0x1f, 0x8b, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0xff, 0xe2, 0xe2, 0x29, 0x4e, 0x4d, 0x2c,
    0x4a, 0xce, 0xd0, 0x2b, 0x28, 0xca, 0x2f, 0xc9, 0x17, 0x62, 0x05, 0x53, 0x4a, 0x9a, 0x5c, 0xbc,
    0xc1, 0x60, 0xe1, 0xa0, 0xd4, 0xc2, 0xd2, 0xd4, 0xe2, 0x12, 0x21, 0x09, 0x2e, 0xf6, 0x22, 0x08,
    0x53, 0x82, 0x51, 0x81, 0x51, 0x83, 0x33, 0x08, 0xc6, 0x55, 0xd2, 0xe1, 0xe2, 0x83, 0x29, 0x2d,
    0x2e, 0xc8, 0xcf, 0x2b, 0x4e, 0x15, 0x92, 0xe2, 0xe2, 0x28, 0x82, 0xb2, 0xa1, 0x8a, 0xe1, 0x7c,
    0x23, 0x0f, 0x98, 0xc1, 0xc1, 0xa9, 0x45, 0x65, 0x99, 0xc9, 0xa9, 0x42, 0xe6, 0x5c, 0x6c, 0x10,
    0x01, 0x21, 0x11, 0x88, 0x13, 0xf4, 0x50, 0x2c, 0x96, 0x12, 0x45, 0x13, 0x85, 0x98, 0xa3, 0xc4,
    0x90, 0xc4, 0x06, 0x16, 0x37, 0x06, 0x04, 0x00, 0x00, 0xff, 0xff, 0xf3, 0xba, 0x74, 0x95, 0xc0,
    0x00, 0x00, 0x00,
}

而这一部分代码主要是围绕 fileDescriptor 进行，在这里 fileDescriptor_search_8b45f79ee13ff6a3 表示一个编译后的 proto 文件，而每一个方法都包含 Descriptor 方法，代表着这一个方法在 fileDescriptor 中具体的 Message Field

golang pb.go 为什么要生成 fileDescriptor？

在 Golang 中使用 Protocol Buffers (PB) 进行编解码时，使用的是 proto 编译器将 .proto 文件编译为对应语言的源代码。在 Golang 中，生成的源代码中会包含 pb.go 文件，它是由 proto 编译器生成的。

pb.go 文件中包含了与 .proto 文件对应的结构体、接口、函数等信息。而 fileDescriptor 是 pb.go 文件中的一部分，它是一个包含了 pb.go 中所有消息、服务、枚举等定义的描述符，它可以让程序在运行时动态地获取这些信息，以便进行消息的编解码、RPC 调用等操作。

具体来说，fileDescriptor 的生成过程包括以下几个步骤：

  • 将 .proto 文件解析为内存中的数据结构。
  • 根据数据结构生成描述符，包括文件描述符、消息描述符、服务描述符等。
  • 将描述符序列化为二进制格式，并嵌入到 pb.go 文件中。

因此，fileDescriptor 是在 pb.go 文件中嵌入的一个二进制数据块，它是由 proto 编译器自动生成的，用于提供消息编解码和 RPC 调用等运行时支持。

https://eddycjy.gitbook.io/golang/di-4-ke-grpc/client-and-server

其他

Go是如何实现protobuf的编解码的(2): 源码

https://cloud.tencent.com/developer/beta/article/1500958

curd_boy
关注
专栏目录
Go语言中的序列化：原理、实现和应用
AI天才研究院
07-22 1888
作者：禅与计算机程序设计艺术 随着互联网web服务的发展，数据层面的需求也越来越复杂，这就要求开发者对数据的存储和交换进行更好的处理。数据存储方案无疑成为影响系统性能和可靠性的一大关键因素。在分布式系统中，数据需要在不同节点间进行传输，因此数据传输方案不可避免地涉及到序列化和反序列化过程。 序列化即将对象转化为字节流或者字符
Spring Cloud OpenFeign集成Protocol Buffer
aoho求索
10-07 1996
本文作者张天，著有《Spring Cloud 微服务架构进阶》一书。 背景  在之前的文章中，我们介绍过基于Spring Cloud微服务架构，其中，微服务实例之间的交互方式一般为RESTful HTTP请求或RPC调用。Spring Cloud已经为开发者提供了专门用于RESTful HTTP请求处理的OpenFeign组件，但是并没有相关的RPC调用组件。今天，我们就要定制OpenFeig...
gRPC快速入门（二）——Protobuf序列化原理解析
weixin_34293059的博客
12-18 4302
gRPC快速入门（二）——Protobuf序列化原理解析 一、Protobuf序列化原理简介 1、序列化 序列化是将数据结构或对象转换成二进制字节流的过程。Protobuf对于不同的字段类型采用不同的编码方式和数据存储方式对消息字段进行序列化，以确保得到高效紧凑的数据压缩。Protobuf序列化过程如下： （1）判断每个字段是否有设置值，有值才进行编码。（2）根据字段标识号与数据类型将字段值通过不...
Protocol buffer序列化及其在微信蓝牙协议中的应用
嵌入式企鹅圈
08-13 7081
微信和蓝牙外设的通信协议采用了Protocol buffer对消息包体进行打包。在时间和空间性能上，Protocol buffe比XML更具优势。本文对Protocol buffe打包的微信蓝牙消息体进行分析。
Protobuf详解以及入门指南
最新发布
weixin_42125125的博客
08-26 1098
Protobuf（Protocol Buffers）协议是由 Google 开发的二进制序列化格式技术它提供了一种高效、简洁和可扩展的方式来序列化和交换数据
Google Protocol Buffer
rongrong0206的专栏
12-06 1184
什么是 Google Protocol Buffer？ 假如您在网上搜索，应该会得到类似这样的文字介绍：Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准，目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC 数据交
Protocol Buffer 四 整数序列化
编程资料大全
06-01 157
varints用于正整数 (无符号整数） varints 是 一个很不错的技术。将一个整数序列化成1或者多个字节。想起以前我们总是使用4字节表示整数，真的很浪费啊。只有真正追求完美的人才会重视每个细节。 我的本篇介绍是https://developers.google.com/protocol-buffers/docs/encoding中的Base 128 Varints一节的逆过程。这么好的站点...
Protobuf序列化
猴子哥哥的博客
05-17 5666
Protobuf是Google出品的一款编解码框架。 1、优点：   1）谷歌内部长期使用，成熟度高   2）跨语言，支持C++、Java、Python、JavaScript、PHP、Ruby、C#、Objective-C等   3）码流小   4）性能高 2、缺点：   1）pojo生成方式增加额外复杂度   2）灵活性差，定义数据格式后不可修改，需要重新生成pojo   3）pojo不支持json操作 综上所述：Protobuf序列化方式适用于跨语言通信、对码流大小和性能要求高、且pojo不经常变化的场
Protocol Buffer 序列化原理大揭秘
xupeng1644的博客
03-13 1609
前言 习惯用 Json、XML 数据存储格式的你们，相信大多都没听过Protocol Buffer Protocol Buffer 其实 是 Google出品的一种轻量 & 高效的结构化数据存储格式，性能比 Json、XML 真的强！太！多！ 由于 Google出品，我相信Protocol Buffer已经具备足够的吸引力 今天，我将讲解为什么Protocol Buffer的性能如此...
Protocol Buffer中文指南：定义与编码解析
Protocol Buffer的使用可以显著提升数据交换的效率和便捷性，它是现代分布式系统和微服务架构中数据交换的标准工具之一。理解和掌握Protocol Buffer的使用对于进行跨平台的系统设计和开发具有重要意义。
全网最详细最齐全的序列化技术及深度解析与应用实战
qigeminghao的博客
11-16 339
序列化是网络通信中非常重要的一个机制，好的序列化方式能够直接影响数据传输的性能。 序列化# 所谓的序列化，就是把一个对象，转化为某种特定的形式，然后以数据流的方式传输。 比如把一个对象直接转化为二进制数据流进行传输。当然这个对象可以转化为其他形式之后再转化为数据流。 比如XML、JSON等格式。它们通过另外一种数据格式表达了一个对象的状态，然后再把这些数据转化为二进制数据流进行网络传输。 反序列化# 反序列化是序列化的逆向过程，把字节数组反序列化为对象，把字节序列恢复为对象的过程成为对象的反序
protocol Buffer
01-04
谷歌公司开发的protocol序列化文件时使用，目前大数据hadoop中用来序列化保存数据
ProtocolBuffer
06-15
Vs2008,vs2017一级Qt都能够编译通过的谷歌Protocol Buffer动态库
微服务间通信
m0_67394002的博客
07-31 1328
微服务架构以进程为一等公民，也就是说每个微服务实例都是一个独立的进程。微服务间通信就是进程间通信。有很多进程间通信技术可供选择。服务间可以使用基于同步请求/响应的通信机制，如HTTPREST或gRPC。另外，也可以使用异步的基于消息的通信机制，常见的消息通信协议有AMRP或STOMP等。本文将从服务的交互方式、API定义、消息的格式等方面来介绍微服务间通信。API或接口是软件开发的中心。一个设计良好的接口会在暴露有用功能的同时隐藏实现细节。API设计优先模式"。。。...
protobuf序列化
cyt涛的博客
12-26 1180
Protocol Buffers (protobuf) 是一种轻量级、高效的数据序列化格式，由 Google 开发。它被设计用于高效地在不同平台和语言之间进行数据通信和存储。protobuf 提供了一种结构化的方式来定义数据模型，并生成用于序列化和反序列化数据的代码。protobuf是一种比json和xml等序列化工具更加轻量和高效的结构化数据存储格式。
使用 protobuf 进行数据序列化
编程猿来如此
07-30 5037
使用 protobuf 进行数据序列化
Protobuf 序列化
程序员小潘
08-14 349
不管是服务还是消息，均通过.proto第一行指定了proto文件的版本号。第二行开始定义了一个Person消息类，它由2个字段组成，整形id和字符串name。笔者使用Java语言，Maven引入Compiler插件，就可以把proto文件编译成Java类。编译后的代码很长就不贴了，这里给出编译后的Person类图：实现了MessageLite接口，方法可以把对象序列化成字节数组。方法可以把字节数组反序列化成对象。
protobuf 序列化和反序列化
小洁洁
03-14 5002
Protocol Buffers（protobuf）是一种轻量级的数据交换格式，可以用于结构化数据的序列化和反序列化。它使用二进制格式来编码数据，以提高传输效率和数据压缩比。在protobuf中，我们可以使用.proto文件来定义消息类型，并使用编译器生成针对各种编程语言的序列化和反序列化代码。序列化是将结构化数据转换为一系列字节的过程，反序列化则是将字节流解析为结构化数据的过程。序列化的过程通常涉及以下步骤：定义消息类型：使用.proto文件定义消息类型和字段。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值