动手点关注干货不迷路 👆
背景
Thrift 是 Facebook 开源的一个高性能,轻量级 RPC 服务框架,是一套全栈式的 RPC 解决方案,包含序列化与服务通信能力,并支持跨平台/跨语言。整体架构如图所示:
![a95143545440a121a86c76fe7be1d20f.png](https://i-blog.csdnimg.cn/blog_migrate/3bd58ce85baa7414e2be227ad894769c.png)
Thrift 软件栈定义清晰,各层的组件松耦合、可插拔,能够根据业务场景灵活组合,如图所示:
![f84661298658b7ede8e8ae340fac5c63.jpeg](https://i-blog.csdnimg.cn/blog_migrate/8902643e2d038dd3c67e288d18a13048.jpeg)
Thrift 本身是一个比较大的话题,这篇文章不会涉及到全部内容,只会涉及到其中的序列化协议。
![7a6423591143e3b33294e88e949af8c2.jpeg](https://i-blog.csdnimg.cn/blog_migrate/804c17c21ad2ba4613f18456d6c4d39b.jpeg)
协议原理
Binary 协议
消息格式
这里通过一个示例对 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,
}
编码简图
![71adc43c040efec8cbe9c9a1440f1138.png](https://i-blog.csdnimg.cn/blog_migrate/5276c1d3ed5a4e7dc4762150eec4291c.png)
编码具体内容
抓包拿到编码后的字节流(转成了十进制,方便大家看)
/* 接口名长度 */ 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
编码含义
消息头
msg_type:消息类型,包含四种类型
Call:客户端消息。调用远程方法,并且期待对方发送响应。
OneWay:客户端消息。调用远程方法,不期待响应。
Reply:服务端消息。正常响应。
Exception:服务端消息。异常响应。
msg_seq_id:消息序号。客户端使用消息序号来处理响应的失序到达,实现请求和响应的匹配。服务端不需要检查该序列号,也不能对序列号有任何的逻辑依赖,只需要响应的时候将其原样返回即可。
消息体
消息体分为两种编码模式:
定长类型 -> T-V 模式,即:字段类型 + 序号 + 字段值
变长类型 -> T-L-V 模式,即:字段类型 + 序号 + 字段长度 + 字段值
field_type:字段类型,包括 String、I64、Struct、Stop 等。字段类型有两个作用:
Stop 类型用于停止嵌套解析
非 Stop 类型用于 Skip(Skip 操作是跳过当前字段,会在「常见问题 - 兼容性」进行讲解)
fied_id:字段序号,解码时通过序号确定字段
len:字段长度,用于变长类型,如 String
value:字段值
数据格式
1. 定长数据类型
数据类型 | 类型标识(8 位) | 类型尺寸(单位:字节) |
---|---|---|
bool | 2 | 1 |
byte | 3 | 1 |
double | 4 | 8 |
i16 | 6 | 2 |
i32 | 8 | 4 |
i64 | 10 | 8 |
2. 变长数据类型
数据类型 | 类型标识(8 位) | 类型尺寸(长度 + 值) |
---|---|---|
string | 11 | 4 + N |
struct | 12 | 嵌套数据 + 一个字节停止符(0) |
map | 13 | 1 + 1 + 4 + N*(X+Y) 【key 类型 + val 类型 + 长度 + 值】 |
set | 14 | 1 + 4 + N 【val 类型 + 长度 + 值】 |
list | 15 | 1 + 4 + N 【val 类型 + 长度 + 值】 |
其他协议
Compact 协议
Compact 协议是二进制压缩协议,在大部分字段的编码方式上与 Binary 协议保持一致。区别在于整数类型(包括变长类型的长度)采用了【先 zigzag 编码 ,再 varint 压缩编码】实现,最大化节省空间开销。
那么问题来了,varint 和 zigzag 是什么?
varint 编码
解决的问题:定长存储的整数类型绝对值较小时空间浪费大
据统计,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 个字节。
zigzag 编码
解决的问题:绝对值较小的负数经过 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
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"]
}
case 分析
修改字段类型导致 RPC 超时
现象:A 服务访问 B 服务,业务逻辑短时间处理完,但整个请求 15s 超时,必现。
直接原因:IDL 类型被修改;并且只升级了服务端(B 服务),没升级客户端(A 服务)
![a2144fdaf0bc59a3c66e893c524b4847.png](https://i-blog.csdnimg.cn/blog_migrate/b575b6bf14ac5b11ea8c43e7f347acd2.png)
本质原因:string 是变长编码,i64 是定长编码。由于客户端没有升级,所以反序列化的时候,会把 signTime 当做 string 类型来解析。而变长编码是 T-L-V 模式,所以解析的时候会把 signTime 的低位 4 字节翻译成 string 的 length。
signTime 是时间戳,大整数,比如:1624206147902,转成二进制为:
00000000 00000000 00000001 01111010 00101010 00111011 00000001 00111110
低位 4 字节转成十进制为:378
也就是要再读 378 个字节作为 SignTime 的值,这已经超过了整个 payload 的大小,最终导致 Socket 读超时。
【注】修改类型不一定就会导致超时,如果 value 的值比较小,解析到的 length 也比较小,能够保证读完。但是错误的解析可能会导致各种预期之外的情况,包括:
乱码
空值
报错:unknown data type xxx (skip 异常)
常见问题
兼容性
增加字段
通过 skip 来跳过增加的字段,从而保证兼容性
![e01696a53ab7d76b59c99e884312bfab.png](https://i-blog.csdnimg.cn/blog_migrate/f3cd97e67973156257762e7b146df6a3.png)
删除字段
编译生成的解析代码是基于 field_id 的 switch-case 结构,语法结构上直接具备兼容性。
![4809c7a1d48fd7ca043b31b1752bab75.png](https://i-blog.csdnimg.cn/blog_migrate/2ecc7d313c83df69ee42a9c1b9af82a0.png)
修改字段名
不破坏兼容性,因为 binary 协议不会对 name 进行编码
Exception
Thrift 有两种 Exception,一种是框架内置的异常,一种是 IDL 自定义的异常。
框架内置的异常包括:「方法名错误」、「消息序列号错误」、「协议错误」,这些异常由框架捕获并封装成 Exception 消息,反序列化时会转成 error 并抛给上层,逻辑如下:
![e24be12e1a8c6fd56c1fe47ab9821f17.png](https://i-blog.csdnimg.cn/blog_migrate/ec3d542c1e90ca62e9d53fa8458a577c.png)
另一种异常是由用户在 IDL 中自定义的,关键字是 exception,用法上跟 struct 没有太大区别。
![65680691f2cdc8eeabb27136bb029d0d.png](https://i-blog.csdnimg.cn/blog_migrate/51a4abbd4820e06e5f1fefb539dfb685.png)
optional、require 实现原理
optional 表示字段可填,require 表示必填
字段被标识为 optional 之后:
基本类型会被编译为指针类型
序列化代码会做空值判断,如果字段为空,则不会被编码
字段被标识为 require 之后:
基本类型会被编译为非指针类型(复合类型 optional 和 require 没区别)
序列化不会做空值判断,字段一定会被编码。如果没有显式赋值,就编码默认值(默认空值,或者 IDL 显式指定的默认值)