RPC框架实现 - 通信协议篇

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 = ;
  required int32 id = ;
  optional string email = ;

  enum PhoneType {
    MOBILE = ;
    HOME = ;
    WORK = ;
  }

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

  repeated PhoneNumber phone = ;
}

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();
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编码方式表示为：

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

→     

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

→    ++
→
→   +  +  +  = 

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

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

key = tag <<  | type

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

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

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

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

message Test1 {
  xxx int32 a = ;
}

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

  =
       →    ++    （丢弃最高位的bit并转为big-endian）
       →
       →  +  +  +  = 

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

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

       6e 

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

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

message Test2 {
  xxx string b = ;
}

数据类型具体是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