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

protobuf定义

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

作用

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

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

特点

protobuffer 为什么高效

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

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

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

序列化 / 反序列化属于 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位表示数据类型，其他位表示数据编号

00001010

file_num = 0001 = 1
type = 010 = 2

type=2，则后面有Length

可变长度编码

Java中整数类型的长度都是确定的，如int类型的长度为4个字节，可表示的整数范围为-2^31——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个字节，但是从统计学角度来说，一般不会有这么大的数

案例分析

总结：

序列化的时候，不序列化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

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 调用等运行时支持。

其他

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

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