IM通讯协议专题学习(十)：初识 Thrift 序列化协议

Posted on 2023-12-28 10:52 Jack Jiang 阅读(59) 评论(0) 编辑收藏

本文由字节跳动技术团队杨晨曦分享，本文有修订和改动。

1、引言

本文将带你一起初步认识Thrift的序列化协议，包括Binary协议、Compact协议（类似于Protobuf)、JSON协议，希望能为你的通信协议格式选型带来参考。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4576-1-1.html）

2、系列文章

本文是系列文章中的第 10 篇，本系列总目录如下：

《IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！》

《IM通讯协议专题学习(二)：快速理解Protobuf的背景、原理、使用、优缺点》

《IM通讯协议专题学习(三)：由浅入深，从根上理解Protobuf的编解码原理》

《IM通讯协议专题学习(四)：从Base64到Protobuf，详解Protobuf的数据编码原理》

《IM通讯协议专题学习(五)：Protobuf到底比JSON快几倍？全方位实测！》

《IM通讯协议专题学习(六)：手把手教你如何在Android上从零使用Protobuf》

《IM通讯协议专题学习(七)：手把手教你如何在NodeJS中从零使用Protobuf》

《IM通讯协议专题学习(八)：金蝶随手记团队的Protobuf应用实践(原理篇)》

《IM通讯协议专题学习(九)：手把手教你如何在iOS上从零使用Protobuf》

《IM通讯协议专题学习(十)：初识 Thrift 序列化协议》（* 本文）

另外：如果您还打算系统地学习IM开发，建议阅读《新手入门一篇就够：从零开发移动端IM》。

3、概述

Thrift 是 Facebook 开源的一个高性能，轻量级 RPC 服务框架，是一套全栈式的 RPC 解决方案，包含序列化与服务通信能力，并支持跨平台/跨语言。

Thrift整体架构如图所示：

Thrift 软件栈定义清晰，各层的组件松耦合、可插拔，能够根据业务场景灵活组合。

如图所示：

Thrift 本身是一个比较大的话题，本篇文章不会涉及到Thrift的全部内容，只会涉及到其中的序列化协议。

4、 Binary协议

4.1消息格式

这里通过一个示例对 Binary 消息格式进行直观的展示。

IDL 定义如下：

//接口
service SupService {
    SearchDepartmentByKeywordResponse SearchDepartmentByKeyword(
        1: SearchDepartmentByKeywordRequest request)
}

//请求
struct SearchDepartmentByKeywordRequest {
    1: optional string Keyword
    2: optional i32 Limit
    3: optional i32 Offset
}

//假设request的payload如下：
{
    Keyword: "lark",
    Limit: 50,
    Offset: nil,
}

4.2编码简图

4.3编码具体内容

抓包拿到编码后的字节流（转成了十进制，方便大家看）。

/* 接口名长度 */         0   0   0    25
/* 接口名 */            83 101 97 114 99 104 68 101 112 97 114 116
                       109 101 110 116 66 121 75 101 121 119 111
                       114 100
/* 消息类型 */           1
/* 消息序号 */           0   0   0   1
/* keyword 字段类型 */   11
/* keyword 字段ID*/     0   1
/* keyword len */      0   0   0   4
/* keyword value */    108   97   114   107
/* limit 字段类型 */     8
/* limit 字段ID*/       0   2
/* limit value */      0   0   0   50
/* 字段终止符 */         0

4.4编码含义

1）消息头：

msg_type（消息类型），包含四种类型：

1）Call：客户端消息。调用远程方法，并且期待对方发送响应；
2）OneWay：客户端消息。调用远程方法，不期待响应；
3）Reply：服务端消息。正常响应；
4）Exception：服务端消息。异常响应。

msg_seq_id（消息序号）：

1）客户端使用消息序号来处理响应的失序到达，实现请求和响应的匹配；
2）服务端不需要检查该序列号，也不能对序列号有任何的逻辑依赖，只需要响应的时候将其原样返回即可。

2）消息体：

消息体分为两种编码模式：

1）定长类型 -> T-V 模式，即：字段类型 + 字段序号 + 字段值；
2）变长类型 -> T-L-V 模式，即：字段类型 + 字段序号 + 字段长度 + 字段值。

具体是：

1）field_type：字段类型，包括 String、I64、Struct、Stop 等；
2）fied_id：字段序号，解码时通过序号确定字段；
3）len：字段长度，用于变长类型，如 String；
4）value：字段值。

字段类型有两个作用：

1）Stop 类型用于停止嵌套解析；
2）非 Stop 类型用于 Skip（Skip 操作是跳过当前字段，会在「常见问题 - 兼容性」进行讲解）。

4.5数据格式

定长数据类型：

变长数据类型：

5、Compact 协议

5.1概述

Compact 协议是二进制压缩协议，在大部分字段的编码方式上与 Binary 协议保持一致。

区别在于整数类型（包括变长类型的长度）采用了先 zigzag 编码，再 varint 压缩编码实现，最大化节省空间开销。

那么问题来了，varint 和 zigzag 是什么？

5.2varint 编码

解决的问题：定长存储的整数类型绝对值较小时空间浪费大。

据统计，RPC 通信时大部分时候传递的整数值都很小，如果使用定长存储会很浪费。

举个 🌰，对 i32 类型的 7 进行编码，可以说前面 3 个字节都浪费了：

00000000 00000000 00000000 00000111

解决思路：将整数类型由定长存储转为变长存储（能用 1 个字节存下就坚决不用 2 个字节）

原理并不复杂，就是将整数按 7bit 分段，每个字节的最高位作为标识位，标识后一个字节是否属于该数据。1 代表后面的字节还是属于当前数据，0 代表这是当前数据的最后一个字节。

以 i32 类型，数值 955 为例，可以看出，由原来的 4 字节压缩到了 2 字节：

binary编码：       00000000 00000000 00000011 10111011
切分：        0000 0000000   0000000   0000111   0111011
compact编码：                          00000111 10111011

当然，varint 编码同样存在缺陷，那就是存储大数的时候，反而会比 binary 的空间开销更大：本来 4 个字节存下的数可能需要 5 个字节，8 个字节存下的数可能需要 10 个字节。

5.3zigzag 编码

解决的问题：绝对值较小的负数经过 varint 编码后空间开销较大举个 🌰，i32 类型的负数（-11）

原码：         10000000 00000000 00000000 00001011
反码：         11111111 11111111 11111111 11110100
补码：         11111111 11111111 11111111 11110101
varint编码：   00001111 11111111 11111111 11111111 11110101

显然，对于绝对值较小的负数，用 varint 编码以后前导 1 过多，难以压缩，空间开销比 binary 编码还大。

解决思路：负数转正数，从而把前导 1 转成前导 0，便于 varint 压缩

算法公式 & 步骤 & 示范：

//算法公式
32位： (n << 1) ^ (n >> 31)
64位： (n << 1) ^ (n >> 63)

/*
* 算法步骤：
* 1. 不分正负：符号位后置，数值位前移
* 2. 对于负数：符号位不变，数值位取反
*/

//示例
负数(-11）
  补码：                     11111111 11111111 11111111 11110101
  符号位后置，数值位前移：      11111111 11111111 11111111 11101011
  符号位不变，数值位取反(21)： 00000000 00000000 00000000 00010101

正数(11）
  补码：                     00000000 00000000 00000000 00010101
  符号位后置，数值位前移(22)： 00000000 00000000 00000000 00101010

奇怪的知识：为什么取名叫 zigzag？

因为这个算法将负数编码成正奇数，正数编码成偶数。最后效果是正负数穿插向前。

就像这样：

编码前       编码后
  0           0
  -1          1
  1           2
  -2          3
  2           4

6、Json 协议

Thrift 不仅支持二进制序列化协议，也支持 Json 这种文本协议。

数据格式：

/* bool、i8、i16、i32、i64、double、string */
"编号": {
  "类型": "值"
}
//示例
"1": {
  "str": "keyword"
}

/* struct */
"编号": {
  "rec": {
    "成员编号": {
      "成员类型": "成员值"
    },
    ...
  }
}
//示例
"1": {
  "rec": {
    "1": {
      "i32": 50
    }
  }
}

/* map */
"编号": {
  "map": [
    "键类型",
    "值类型",
    元素个数,
      "键1",
      "值1",
      ...
      "键n",
      "值n"
   ]
}
//示例
"6": {
  "map": [
    "i64",
    "str",
    1,
    666,
    "mapValue"
  ]
}

/* List */
"编号": {
  "set/lst": [
    "值类型",
    元素个数,
    "ele1",
    "ele2",
    "elen"
  ]
}
//示例
"2": {
  "lst": [
    "str",
    2,
    "lark","keyword"]
}