RPC框架实现 - 通信协议篇

Dear 丶 2022-03-27 09:48 311阅读 0赞

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如何编码更多数据类型：

![072258385328423.png][]

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][]

[Protocol Buffers Language Guide]: https://developers.google.com/protocol-buffers/docs/proto
[072258385328423.png]: /images/20220327/f172da47785f4bd080f7f884a37e94aa.png
[Protocol Buffers Developer Guide]: https://developers.google.com/protocol-buffers/docs/overview
[Protocol Buffers Encoding]: https://developers.google.com/protocol-buffers/docs/encoding