写点什么

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

作者:JackJiang
  • 2023-12-29
    江苏
  • 本文字数:4861 字

    阅读完需:约 16 分钟

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

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

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   0111011compact 编码:                          00000111  10111011

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

5.3zigzag 编码

解决的问题:绝对值较小的负数经过 varint 编码后空间开销较大 举个 🌰,i32 类型的负数(-11)

原码:         10000000  00000000  00000000  00001011 反码:         11111111  11111111  11111111  11110100 补码:         11111111  11111111  11111111  11110101varint 编码:   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"]}

7、修改字段类型导致协议解析不一致的通信问题

现象:A 服务访问 B 服务,业务逻辑短时间处理完,但整个请求 15s 超时,必现。

直接原因:IDL 类型被修改;并且只升级了服务端(B 服务),没升级客户端(A 服务)。

本质原因:string 是变长编码,i64 是定长编码。由于客户端没有升级,所以反序列化的时候,会把 signTime 当做 string 类型来解析。而变长编码是 T-L-V 模式,所以解析的时候会把 signTime 的低位 4 字节翻译成 string 的 length。

signTime 是时间戳,大整数,比如:1624206147902,转成二进制为:

100000000 00000000 00000001 01111010 00101010 00111011 00000001 00111110

低位 4 字节转成十进制为:378 。

也就是要再读 378 个字节作为 SignTime 的值,这已经超过了整个 payload 的大小,最终导致 Socket 读超时。

注:修改类型不一定就会导致超时,如果 value 的值比较小,解析到的 length 也比较小,能够保证读完。

但是错误的解析可能会导致各种预期之外的情况,包括:

  • 1)乱码;

  • 2)空值;

  • 3)报错:unknown data type xxx (skip 异常)。

8、通信协议带来的常见问题

8.1 兼容性

1)增加字段:

通过 skip 来跳过增加的字段,从而保证兼容性。

2)删除字段:

编译生成的解析代码是基于 field_id 的 switch-case 结构,语法结构上直接具备兼容性。

3)修改字段名:

不破坏兼容性,因为 binary 协议不会对 name 进行编码。

8.2Exception

Thrift 有两种 Exception:

  • 1)一种是框架内置的异常;

  • 2)一种是 IDL 自定义的异常。

框架内置的异常包括:

  • 1)方法名错误;

  • 2)消息序列号错误;

  • 3)协议错误。

这些异常由框架捕获并封装成 Exception 消息,反序列化时会转成 error 并抛给上层。

逻辑如下:

另一种异常是由用户在 IDL 中自定义的,关键字是 exception,用法上跟 struct 没有太大区别。

8.3optional、require 实现原理

optional 表示字段可填,require 表示必填。

字段被标识为 optional 之后:

  • 1)基本类型会被编译为指针类型;

  • 2)序列化代码会做空值判断,如果字段为空,则不会被编码。

字段被标识为 require 之后:

  • 1)基本类型会被编译为非指针类型(复合类型 optional 和 require 没区别);

  • 2)序列化不会做空值判断,字段一定会被编码。如果没有显式赋值,就编码默认值(默认空值,或者 IDL 显式指定的默认值)。

9、参考资料

[1] Protobuf从入门到精通,一篇就够!

[2] 如何选择即时通讯应用的数据传输格式

[3] 强列建议将Protobuf作为你的即时通讯应用数据传输格式

[4] APP与后台通信数据格式的演进:从文本协议到二进制协议

[5] 面试必考,史上最通俗大小端字节序详解

[6] 移动端IM开发需要面对的技术问题(含通信协议选择)

[7] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[8] 理论联系实际:一套典型的IM通信协议设计详解

[9] 58到家实时消息系统的协议设计等技术实践分享

[10] 金蝶随手记团队的Protobuf应用实践(原理篇)

[11] 新手入门一篇就够:从零开发移动端IM


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

用户头像

JackJiang

关注

还未添加个人签名 2019-08-26 加入

开源IM框架MobileIMSDK、BeautyEye的作者。

评论

发布
暂无评论
IM通讯协议专题学习(十):初识 Thrift 序列化协议_网络编程_JackJiang_InfoQ写作社区
vConsole