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、参考资料
[3] 强列建议将Protobuf作为你的即时通讯应用数据传输格式
[4] APP与后台通信数据格式的演进:从文本协议到二进制协议
[7] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端
[10] 金蝶随手记团队的Protobuf应用实践(原理篇)
[11] 新手入门一篇就够:从零开发移动端IM
(本文已同步发布于:http://www.52im.net/thread-4576-1-1.html)
评论