作者｜ 楊晨曦

背景

Thrift 是 Facebook 開源的一個高性能，輕量級 RPC 服務(wù)框架，是一套全棧式的 RPC 解決方案，包含序列化與服務(wù)通信能力，并支持跨平臺/跨語言。整體架構(gòu)如圖所示：

Thrift 軟件棧定義清晰，各層的組件松耦合、可插拔，能夠根據(jù)業(yè)務(wù)場景靈活組合，如圖所示：

Thrift 本身是一個比較大的話題，這篇文章不會涉及到全部內(nèi)容，只會涉及到其中的序列化協(xié)議。

協(xié)議原理

Binary 協(xié)議

消息格式

這里通過一個示例對 Binary 消息格式進行直觀的展示，IDL 定義如下：

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

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

// 假設(shè)request的payload如下：
{
    Keyword: "lark",
    Limit: 50,
    Offset: nil,        
}

編碼簡圖

編碼具體內(nèi)容

抓包拿到編碼后的字節(jié)流（轉(zhuǎn)成了十進制，方便大家看）

/* 接口名長度 */         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：客戶端消息。調(diào)用遠程方法，并且期待對方發(fā)送響應(yīng)。
• OneWay：客戶端消息。調(diào)用遠程方法，不期待響應(yīng)。
• Reply：服務(wù)端消息。正常響應(yīng)。
• Exception：服務(wù)端消息。異常響應(yīng)。

• msg_seq_id：消息序號?？蛻舳耸褂孟⑿蛱杹硖幚眄憫?yīng)的失序到達，實現(xiàn)請求和響應(yīng)的匹配。服務(wù)端不需要檢查該序列號，也不能對序列號有任何的邏輯依賴，只需要響應(yīng)的時候?qū)⑵湓瓨臃祷丶纯伞?/li>

消息體

消息體分為兩種編碼模式：

1. 定長類型 -> T-V 模式，即：字段類型 + 序號 + 字段值
2. 變長類型 -> T-L-V 模式，即：字段類型 + 序號 + 字段長度 + 字段值

• field_type：字段類型，包括 String、I64、Struct、Stop 等。字段類型有兩個作用：

• Stop 類型用于停止嵌套解析
• 非 Stop 類型用于 Skip（Skip 操作是跳過當前字段，會在「常見問題 - 兼容性」進行講解）

• fied_id：字段序號，解碼時通過序號確定字段
• len：字段長度，用于變長類型，如 String
• value：字段值

數(shù)據(jù)格式

1. 定長數(shù)據(jù)類型

2. 變長數(shù)據(jù)類型

其他協(xié)議

Compact 協(xié)議

Compact 協(xié)議是二進制壓縮協(xié)議，在大部分字段的編碼方式上與 Binary 協(xié)議保持一致。區(qū)別在于整數(shù)類型（包括變長類型的長度）采用了【先 zigzag 編碼 ，再 varint 壓縮編碼】實現(xiàn)，最大化節(jié)省空間開銷。

那么問題來了，varint 和 zigzag 是什么？

varint 編碼

解決的問題：定長存儲的整數(shù)類型絕對值較小時空間浪費大

據(jù)統(tǒng)計，RPC 通信時大部分時候傳遞的整數(shù)值都很小，如果使用定長存儲會很浪費。

舉個 ??，對 i32 類型的 7 進行編碼，可以說前面 3 個字節(jié)都浪費了：

00000000 00000000 00000000 00000111

解決思路：將整數(shù)類型由定長存儲轉(zhuǎn)為變長存儲（能用 1 個字節(jié)存下就堅決不用 2 個字節(jié)）

原理并不復(fù)雜，就是將整數(shù)按 7bit 分段，每個字節(jié)的最高位作為標識位，標識后一個字節(jié)是否屬于該數(shù)據(jù)。1 代表后面的字節(jié)還是屬于當前數(shù)據(jù)，0 代表這是當前數(shù)據(jù)的最后一個字節(jié)。

以 i32 類型，數(shù)值 955 為例，可以看出，由原來的 4 字節(jié)壓縮到了 2 字節(jié)：

binary編碼：       00000000  00000000  00000011  10111011
切分：        0000  0000000   0000000   0000111   0111011
compact編碼：                          00000111  10111011

當然，varint 編碼同樣存在缺陷，那就是存儲大數(shù)的時候，反而會比 binary 的空間開銷更大：本來 4 個字節(jié)存下的數(shù)可能需要 5 個字節(jié)，8 個字節(jié)存下的數(shù)可能需要 10 個字節(jié)。

zigzag 編碼

解決的問題：絕對值較小的負數(shù)經(jīng)過 varint 編碼后空間開銷較大 舉個 ??，i32 類型的負數(shù)（-11）

原碼：         10000000  00000000  00000000  00001011
反碼：         11111111  11111111  11111111  11110100
補碼：         11111111  11111111  11111111  11110101
varint編碼：   00001111  11111111  11111111  11111111  11110101

顯然，對于絕對值較小的負數(shù)，用 varint 編碼以后前導(dǎo) 1 過多，難以壓縮，空間開銷比 binary 編碼還大。

解決思路：負數(shù)轉(zhuǎn)正數(shù)，從而把前導(dǎo) 1 轉(zhuǎn)成前導(dǎo) 0，便于 varint 壓縮

算法公式 & 步驟 & 示范：

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


/*
 * 算法步驟：
 * 1. 不分正負：符號位后置，數(shù)值位前移
 * 2. 對于負數(shù)：符號位不變，數(shù)值位取反
 */


// 示例
負數(shù)(-11）
  補碼：                     11111111  11111111  11111111  11110101
  符號位后置，數(shù)值位前移：      11111111  11111111  11111111  11101011
  符號位不變，數(shù)值位取反(21)：  00000000  00000000  00000000  00010101

正數(shù)(11）
  補碼：                     00000000  00000000  00000000  00010101
  符號位后置，數(shù)值位前移(22)：  00000000  00000000  00000000  00101010

【奇怪的知識】為什么取名叫 zigzag？

因為這個算法將負數(shù)編碼成正奇數(shù)，正數(shù)編碼成偶數(shù)。最后效果是正負數(shù)穿插向前，就像這樣：

編碼前       編碼后
  0           0
  -1          1
  1           2
  -2          3
  2           4

Json 協(xié)議

Thrift 不僅支持二進制序列化協(xié)議，也支持 Json 這種文本協(xié)議

數(shù)據(jù)格式

/* bool、i8、i16、i32、i64、double、string */
"編號": {
  "類型": "值"
}
// 示例
"1": {
  "str": "keyword"
}


/* struct */
"編號": {
  "rec": {
    "成員編號": {
      "成員類型": "成員值"
    },
    ...
  }
}
// 示例
"1": {
  "rec": {
    "1": {
      "i32": 50
    }
  }
}


/* map */
"編號": {
  "map": [
    "鍵類型",
    "值類型",
    元素個數(shù),
      "鍵1",
      "值1",
      ...
      "鍵n",
      "值n"
   ]
}
// 示例
"6": {
  "map": [
    "i64",
    "str",
    1,
    666,
    "mapValue"
  ]
}


/* List */
"編號": {
  "set/lst": [
    "值類型",
    元素個數(shù),
    "ele1",
    "ele2",
    "elen"
  ]
}
// 示例
"2": {
  "lst": [
    "str",
    2,
    "lark","keyword"]
}

case 分析

修改字段類型導(dǎo)致 RPC 超時

現(xiàn)象：A 服務(wù)訪問 B 服務(wù)，業(yè)務(wù)邏輯短時間處理完，但整個請求 15s 超時，必現(xiàn)。

直接原因：IDL 類型被修改；并且只升級了服務(wù)端（B 服務(wù)），沒升級客戶端（A 服務(wù)）

本質(zhì)原因：string 是變長編碼，i64 是定長編碼。由于客戶端沒有升級，所以反序列化的時候，會把 signTime 當做 string 類型來解析。而變長編碼是 T-L-V 模式，所以解析的時候會把 signTime 的低位 4 字節(jié)翻譯成 string 的 length。

signTime 是時間戳，大整數(shù)，比如：1624206147902，轉(zhuǎn)成二進制為：

00000000 00000000 00000001 01111010 00101010 00111011 00000001 00111110

低位 4 字節(jié)轉(zhuǎn)成十進制為：378

也就是要再讀 378 個字節(jié)作為 SignTime 的值，這已經(jīng)超過了整個 payload 的大小，最終導(dǎo)致 Socket 讀超時。

【注】修改類型不一定就會導(dǎo)致超時，如果 value 的值比較小，解析到的 length 也比較小，能夠保證讀完。但是錯誤的解析可能會導(dǎo)致各種預(yù)期之外的情況，包括：

1. 亂碼
2. 空值
3. 報錯：unknown data type xxx （skip 異常）

常見問題

兼容性

增加字段

通過 skip 來跳過增加的字段，從而保證兼容性

刪除字段

編譯生成的解析代碼是基于 field_id 的 switch-case 結(jié)構(gòu)，語法結(jié)構(gòu)上直接具備兼容性。

修改字段名

不破壞兼容性，因為 binary 協(xié)議不會對 name 進行編碼

Exception

Thrift 有兩種 Exception，一種是框架內(nèi)置的異常，一種是 IDL 自定義的異常。

框架內(nèi)置的異常包括：「方法名錯誤」、「消息序列號錯誤」、「協(xié)議錯誤」，這些異常由框架捕獲并封裝成 Exception 消息，反序列化時會轉(zhuǎn)成 error 并拋給上層，邏輯如下：

另一種異常是由用戶在 IDL 中自定義的，關(guān)鍵字是 exception，用法上跟 struct 沒有太大區(qū)別。

optional、require 實現(xiàn)原理

optional 表示字段可填，require 表示必填

字段被標識為 optional 之后：

• 基本類型會被編譯為指針類型
• 序列化代碼會做空值判斷，如果字段為空，則不會被編碼

字段被標識為 require 之后：

• 基本類型會被編譯為非指針類型（復(fù)合類型 optional 和 require 沒區(qū)別）
• 序列化不會做空值判斷，字段一定會被編碼。如果沒有顯式賦值，就編碼默認值（默認空值，或者 IDL 顯式指定的默認值）?