Protocol Buffers

RPC(Remote Procedure Call,远程过程调用)框架是分布式服务的基石,实现RPC框架需要考虑方方面面。其对业务隐藏了底层通信过程(TCP/UDP、打包/解包、序列化/反序列化),使上层专注于功能实现;框架层面,提供各类可选架构(多进程/多线程/协程);应对设备故障(高负载/死机)、网络故障(拥塞/网络分化),提供相应容灾措施。

 

RPC节点间为了协同工作、实现信息交换,需要协商一定的规则和约定,例如字节序、压缩或加密算法、各字段类型。通信协议的应用随处可见,例如我们对可选信息或字段经常使用TLV进行编码,HTTP、FTP等协议基于可读文本的 "Field: Value" 格式,各种系统也经常使用json、XML格式完成相互间通信。

 

不同的通信协议适用于不同的应用场景,比如内部系统的交互我们选择json,一来可读性较好,二来各种语言都提供了解析json的库、方便编码。Google Protocol Buffers是生成环境中常用的通信协议,除了可以设定Client/Server间通信格式,Protocol Buffers还对数据进行压缩,节省传输流量、加快传输速度。下面我们来了解Google Protocol Buffers。

 

Protocol Buffers

我们看如何使用Protocol Buffers(以下简称PB),首先在.proto文件中定义数据格式,下面以Person.proto为例:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}
message类型内,可以定义int、string、bool、string等类型的字段,也可以嵌套定义messages类型。每个字段可以是required、optional或repeated类型,分别表示必须每次通信必须填充该字段、可选或可重复。每个message类型内的每个字段被赋值唯一的数字值,PB以二进制格式进行数据传输,数字值在二进制中作为该字段的标识。关于PB数据格式的更多内容可参考Protocol Buffers Language Guide

 

完成数据定义后,接下来可以使用protoc工具解析Person.proto文件,生成Person类:

protoc --cpp_out=/home/bangerlee/PB ./Person.proto

执行以上命令后,可以看到 /home/bangerlee/PB 目录下生成了两个文件:

person.pb.cc  person.pb.h

其中定义了操作(get/set)Person类各个字段的函数。

 

有了接口,我们就可以在代码中这样使用Person类,写入操作如下:

Person person;
person.set_name("bangerlee");
person.set_id(1234);
person.set_email("bangerlee@gmail.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);
读取操作如下:
fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

以上我们初步了解了如何使用PB,PB运用了一些编码规则,使得需要传输的数据(二进制格式)更小,下面我们就来了解PB如何对不同数据类型的编码规则。

 

编码(Encoding)

对整形int、字符串类型string等,PB有不同的编码方式。对整型int,PB使用了Varints编码方式,Varints编码的优势是使用了更少的bytes来表示很小的int类型值。

 

Varints编码方式中,每个byte的最高位bit有特殊含义,如果为1,表示后续的byte也是这个数字的一部分;如果为0,则表示结束。剩余的7个bit用于表示数据。数字300用Varints编码方式表示为:

1010 1100 0000 0010

由Varints编码规则,去掉第一个byte的最高位1,去掉第二个byte的最高位0,则有:

1010 1100 0000 0010
→ 010 1100  000 0010

Varints字节序使用little-endian,以上数字用big-endian并转换成10进制有:

000 0010  010 1100
→  000 0010 ++ 010 1100
→  100101100
→  256 + 32 + 8 + 4 = 300

以上了解了Varints对int整型的编码方式,我们再来看PB如何编码更多数据类型:

PB编码中,数据以key-value的形式表示,第一个byte即为key。以上表格中不同数据类型对应指定type值,假设message中各字段的数字标识为tag,则key、type和tag有以下对应关系:

key = tag << 3 | type

即key的最后3个bit用于存储type,有了这层关系,我们试着演算PB中对int和string的编码。

 

假设我们截获到以下PB数据:

08 96 01

这段数据具体表示什么?我们用以上对应关系演算一下,首先该数据key是08,二进制表示即:

0000 1000

最后3个bit表示type,即type为0(Varint格式数据),左移3位得到tag值为1。有了这些信息,我们可以知道这个数据应该是这样定义的:

message Test1 {
  xxx int32 a = 1;
}

继续地,我们用Varint格式来解析 96 01,有以下演算过程:

96 01 = 1001 0110  0000 0001
       → 000 0001  ++  001 0110 (丢弃最高位的bit并转为big-endian)
       → 10010110
       → 2 + 4 + 16 + 128 = 150

因此我们可以知道这段数据表示150这个数。

 

又假设我们截获到以下一段PB编码:

12 07 74 65 73 74 69 6e 67

同样套用以上关系,key是12,二进制表示即:

0001 0010

最后3个bit表示type,即type为2(Length-delimited),左移3位得到tag值为2。有了这些信息,我们知道这个数据可能是这样定义的:

message Test2 {
  xxx string b = 2;
}

数据类型具体是string、bytes或其他,这并不影响我们解析这段数据,对于Length-delimited格式数据,第2个byte表示数据长度(Len),对应以上编码即Len为7,这实质是TLV编码格式。

后续的7个bytes表示有效的传输数据,为UTF-8编码下的"testing"字符串。

 

小结

以上介绍了通信协议 - Google Protocol Buffers,了解了其基本使用方法和编码方式。PB支持前向兼容,可以在不修改Client/Server程序的情况下修改其中一端的数据格式,在各种RPC框架中经常可以看到它的身影。

Reference: Protocol Buffers Developer Guide

Protocol Buffers Encoding

此条目发表在rpc分类目录。将固定链接加入收藏夹。