01

背景

1. 動(dòng)態(tài)反射：動(dòng)態(tài)地 讀取、修改、裁剪 數(shù)據(jù)包中某些字段，如隱私合規(guī)場(chǎng)景中字段屏蔽；
2. 數(shù)據(jù)編排：組合多個(gè)子數(shù)據(jù)包進(jìn)行 排序、過(guò)濾、位移、歸并 等操作，如某些 BFF (Backend For Frontent) 服務(wù)；
3. 協(xié)議轉(zhuǎn)換：作為代理將某種協(xié)議的數(shù)據(jù)轉(zhuǎn)換另一種協(xié)議，如 http-rpc 協(xié)議轉(zhuǎn)換網(wǎng)關(guān)。
4. 泛化調(diào)用：需要秒級(jí)熱更新或迭代非常頻繁的 RPC 服務(wù)，如大量 Kitex 泛化調(diào)用（generic-call）用戶

不難發(fā)現(xiàn)，這些業(yè)務(wù)場(chǎng)景都具有難以統(tǒng)一定義靜態(tài)IDL的特點(diǎn)。即使可以通過(guò)分布式 sidecar 技術(shù)規(guī)避這個(gè)問(wèn)題，也往往因?yàn)闃I(yè)務(wù)需要?jiǎng)討B(tài)更新而放棄傳統(tǒng)代碼生成方式，訴諸某些自研或開(kāi)源的 Thrift 泛型編解碼庫(kù)進(jìn)行泛化 RPC 調(diào)用。我們經(jīng)過(guò)性能分析發(fā)現(xiàn)，目前這些庫(kù)相比代碼生成方式有巨大的性能下降。以字節(jié)某 BFF 服務(wù)為例，僅僅 Thrift 泛化調(diào)用產(chǎn)生的 CPU 開(kāi)銷占比就將近 40%，這幾乎是正常 Thrift RPC 服務(wù)的4到8倍。因此，我們自研了一套能動(dòng)態(tài)處理 RPC 數(shù)據(jù)（不需要代碼生成）同時(shí)保證高性能的 Go 基礎(chǔ)庫(kù) —— dynamicgo。

02

設(shè)計(jì)與實(shí)現(xiàn)

對(duì)于 thrift 反射代理的使用場(chǎng)景，歸納起來(lái)有如下使用需求：

1. 有一套完整結(jié)構(gòu)自描述能力，可表達(dá) scalar 數(shù)據(jù)類型， 也可表達(dá)嵌套結(jié)構(gòu)的映射、序列等關(guān)系；
2. 支持增刪查改（Get/Set/Index/Delete/Add）與遍歷（ForEach）；
3. 保證數(shù)據(jù)可并發(fā)讀，但是不需要支持并發(fā)寫(xiě)。等價(jià)于 map[string]interface{} 或 []interface{}

這里我們參考了 Go reflect 的設(shè)計(jì)思想，把通過(guò)IDL解析得到的準(zhǔn)靜態(tài)類型描述（只需跟隨 IDL 更新一次）TypeDescriptor 和 原始數(shù)據(jù)單元 Node 打包成一個(gè)完全自描述的結(jié)構(gòu)——Value，提供一套完整的反射 API。

//IDL類型描述
typeTypeDescriptorinterface{
Type()Type//數(shù)據(jù)類型
Name()string//類型名稱
Key()*TypeDescriptor//formapkey
Elem()*TypeDescriptor//forsliceormapelement
Struct()*StructDescriptor//forstruct
}
//純TLV數(shù)據(jù)單元
typeNodestruct{
tType//數(shù)據(jù)類型
vunsafe.Pointer//buffer起始位置
lint//數(shù)據(jù)單元長(zhǎng)度
}
//Node+類型描述descriptor
typeValuestruct{
Node
Descthrift.TypeDescriptor
}

這樣，只要保證 TypeDescriptor 包含的類型信息足夠豐富，以及對(duì)應(yīng)的 thrift 原始字節(jié)流處理邏輯足夠健壯，甚至可以實(shí)現(xiàn)數(shù)據(jù)裁剪、聚合等各種復(fù)雜的業(yè)務(wù)場(chǎng)景。

協(xié)議轉(zhuǎn)換

協(xié)議轉(zhuǎn)換的過(guò)程可以通過(guò)有限狀態(tài)機(jī)（FSM）來(lái)表達(dá)。以 JSON->Thrift 流程為例，其轉(zhuǎn)換過(guò)程大致為：

1. 預(yù)加載用戶 IDL，轉(zhuǎn)換為運(yùn)行時(shí)的動(dòng)態(tài)類型描述 TypeDescriptor；
2. 從輸入字節(jié)流中讀取一個(gè) json 值，并判斷其具體類型（object/array/string/number/bool/null)：
3. 如果是 object 類型，繼續(xù)讀取一個(gè) key，再通過(guò)對(duì)應(yīng)的 STRUCT 類型描述找到匹配字段的子類型描述；
4. 如果是 array 類型，遞歸查找類型描述的子元素類型描述；
5. 其它類型，直接使用當(dāng)前類型描述。
6. 基于得到的動(dòng)態(tài)類型描述信息，將該值轉(zhuǎn)換為等價(jià)的 Thrift 字節(jié)，寫(xiě)入到輸出字節(jié)流中 ；
7. 更新輸入和輸出字節(jié)流位置，跳回2進(jìn)行循環(huán)處理，直到輸入終止（EOF）。

圖1 JSON2Thrift 數(shù)據(jù)轉(zhuǎn)換流程

整個(gè)過(guò)程可以完全做到 in-place 進(jìn)行，僅需為輸出字節(jié)流分配一次內(nèi)存即可。

數(shù)據(jù)編排

與前面兩個(gè)場(chǎng)景稍微有所不同，數(shù)據(jù)編排場(chǎng)景下可能涉及數(shù)據(jù)位置的改變（異構(gòu)轉(zhuǎn)換），并且往往會(huì)訪問(wèn)大量數(shù)據(jù)節(jié)點(diǎn)（最壞復(fù)雜度O(N) )。在與抖音隱私合規(guī)團(tuán)隊(duì)的合作研發(fā)中我們就發(fā)現(xiàn)了類似問(wèn)題。它們的一個(gè)重要業(yè)務(wù)場(chǎng)景：要橫向遍歷某一個(gè) array 的子節(jié)點(diǎn)，查找是否有違規(guī)數(shù)據(jù)并進(jìn)行整行擦除。這種場(chǎng)景下，直接基于原始字節(jié)流進(jìn)行查找和插入可能會(huì)帶來(lái)大量重復(fù)的skip 定位、數(shù)據(jù)拷貝開(kāi)銷，最終導(dǎo)致性能劣化。因此我們需要一種高效的反序列化（帶有指針）結(jié)構(gòu)表示來(lái)處理數(shù)據(jù)。根據(jù)以往經(jīng)驗(yàn)，我們想到了DOM（Document Object Model），這種結(jié)構(gòu)被廣泛運(yùn)用在 JSON 的泛型解析場(chǎng)景中（如 rappidJSON、sonic/ast），并且性能相比 map+interface 泛型要好很多。

要用 DOM 來(lái)描述一個(gè) Thrift 結(jié)構(gòu)體，首先需要一個(gè)能準(zhǔn)確描述數(shù)據(jù)節(jié)點(diǎn)之間的關(guān)系的定位方式—— Path。其類型應(yīng)該包括 list index、map key 以及 struct field id等。

typePathTypeuint8

const(
PathFieldIdPathType=1+iota//STRUCT下字段ID
PathFieldName//STRUCT下字段名稱
PathIndex//SET/LIST下的序列號(hào)
PathStrKey//MAP下的stringkey
PathIntkey//MAP下的integerkey
PathObjKey//MAP下的objectkey
)

typePathNodestruct{
Path//相對(duì)父節(jié)點(diǎn)路徑
Node//原始數(shù)據(jù)單元
Next[]PathNode//存儲(chǔ)子節(jié)點(diǎn)
}

在 Path 的基礎(chǔ)上，我們組合對(duì)應(yīng)的數(shù)據(jù)單元Node，然后再通過(guò)一個(gè)Next 數(shù)組動(dòng)態(tài)存儲(chǔ)子節(jié)點(diǎn)，便可以組裝成一個(gè)類似于BTree的泛型結(jié)構(gòu)。

圖2 thrift DOM 數(shù)據(jù)結(jié)構(gòu)

這種泛型結(jié)構(gòu)比 map+interface 要好在哪呢？首先，底層的數(shù)據(jù)單元 Node 都是對(duì)原始 thrift data 的引用，沒(méi)有轉(zhuǎn)換 interface 帶來(lái)的二進(jìn)制編解碼開(kāi)銷；其次，我們的設(shè)計(jì)保證所有樹(shù)節(jié)點(diǎn) PathNode 的內(nèi)存結(jié)構(gòu)是完全一樣，并且由于父子關(guān)系的底層核心容器是 slice， 我們又可以更進(jìn)一步采用內(nèi)存池技術(shù)，將整個(gè) DOM 樹(shù)的子節(jié)點(diǎn)內(nèi)存分配與釋放都進(jìn)行池化從而避免調(diào)用 go 堆內(nèi)存管理。測(cè)試結(jié)果表明，在理想場(chǎng)景下（后續(xù)反序列化的DOM樹(shù)節(jié)點(diǎn)數(shù)量小于等于之前反序列化節(jié)點(diǎn)數(shù)量的最大值——這由于內(nèi)存池本身的緩沖效應(yīng)基本可以保證），內(nèi)存分配次數(shù)可為0，性能提升200%?。ㄒ?jiàn)【性能測(cè)試-全量序列化/反序列化】部分）。

03

性能測(cè)試

這里我們分別定義簡(jiǎn)單（Small)、復(fù)雜（Medium) 兩個(gè)基準(zhǔn)結(jié)構(gòu)體分別在比較 不同數(shù)據(jù)量級(jí) 下的性能，同時(shí)添加簡(jiǎn)單部分（SmallPartial）、復(fù)雜部分（MediumPartial） 兩個(gè)對(duì)應(yīng)子集，用于【反射-裁剪】場(chǎng)景的性能比較：

• Small：114B，6個(gè)有效字段
• SmallPartial：small 的子集，55B，3個(gè)有效字段
• Medium: 6455B，284個(gè)有效字段

• MediumPartial: medium 的子集，1922B，132個(gè)有效字段

Small：https://github.com/cloudwego/dynamicgo/blob/main/testdata/idl/baseline.thrift#L3

Medium：https://github.com/cloudwego/dynamicgo/blob/main/testdata/idl/baseline.thrift#L12

SmallPartial：https://github.com/cloudwego/dynamicgo/blob/main/testdata/idl/baseline.thrift#L12

MediumPartial：https://github.com/cloudwego/dynamicgo/blob/main/testdata/idl/baseline.thrift#L36

其次，我們依據(jù)上述業(yè)務(wù)場(chǎng)景劃分為 反射、協(xié)議轉(zhuǎn)換、全量序列化/反序列化 三套 API，并以代碼生成庫(kù)kitex/FastAPI、泛化調(diào)用庫(kù)kitex/generic、JSON 庫(kù)sonic為基準(zhǔn)進(jìn)行性能測(cè)試。其它測(cè)試環(huán)境均保持一致：

• Go 1.18.1
• CPU intel i9-9880H 2.3GHZ
• OS macOS Monterey 12.6

kitex/FastAPI：https://github.com/cloudwego/kitex/blob/aed28371eb88b2668854759ce9f4666595ebc8de/pkg/remote/codec/thrift/thrift.go

kitex/generic：https://github.com/cloudwego/kitex/tree/develop/pkg/generic

sonic：https://github.com/bytedance/sonic

反射

1. 代碼

dynamicgo/testdata/baseline_tg_test.go

2. 用例

• GetOne：查找字節(jié)流中最后1個(gè)數(shù)據(jù)字段
• GetMany：查找前中后5個(gè)數(shù)據(jù)字段
• MarshalMany：將 GetMany 中的結(jié)果進(jìn)行二次序列化
• SetOne：設(shè)置最后一個(gè)數(shù)據(jù)字段
• SetMany：設(shè)置前中后3個(gè)節(jié)點(diǎn)數(shù)據(jù)
• MarshalTo：將大 Thrift 數(shù)據(jù)包裁剪為小 thrift 數(shù)據(jù)包 （Small -> SmallPartial 或 Medium -> MediumParital）
• UnmarshalAll+MarshalPartial：代碼生成/泛化調(diào)用方式裁剪——先反序列化全量數(shù)據(jù)再序列化部分?jǐn)?shù)據(jù)。效果等同于 MarshalTo。

3. 結(jié)果

• 簡(jiǎn)單（ns/OP）

• 復(fù)雜（ns/OP）

4. 結(jié)論

• dynamicgo 一次查找+寫(xiě)入 開(kāi)銷大約為代碼生成方式的 2 ~ 1/3、為泛化調(diào)用方式的 1/12 ~ 1/15，并隨著數(shù)據(jù)量級(jí)增大優(yōu)勢(shì)加大；
• dynamicgo thrift 裁剪 開(kāi)銷接近于代碼生成方式、約為泛化調(diào)用方式的 1/10～1/6，并且隨著數(shù)據(jù)量級(jí)增大優(yōu)勢(shì)減弱。

協(xié)議轉(zhuǎn)換

1. 代碼

• JSON2Thrift:dynamicgo/testdata/baseline_j2t_test.go
• ThriftToJSON:dynamicgo/testdata/baseline_t2j_test.go

2. 用例

• JSON2thrift：JSON 數(shù)據(jù)轉(zhuǎn)換為等價(jià)結(jié)構(gòu)的 thrift 數(shù)據(jù)
• thrift2JSON：將 thrift 數(shù)據(jù)轉(zhuǎn)換為等價(jià)結(jié)構(gòu)的 JSON 數(shù)據(jù)
• sonic + kitex-fast：表示通過(guò) sonic 處理 json 數(shù)據(jù)（有結(jié)構(gòu)體），通過(guò)kitex代碼生成處理thrift數(shù)據(jù)

3. 結(jié)果

• 簡(jiǎn)單（ns/OP）

• 復(fù)雜（ns/OP）

4. 結(jié)論

• dynamicgo 協(xié)議轉(zhuǎn)換開(kāi)銷約為代碼生成方式的 1～2/3、泛化調(diào)用方式的 1/4～1/9，并且隨著數(shù)據(jù)量級(jí)增大優(yōu)勢(shì)加大；

全量序列化/反序列化

1. 代碼

dynamicgo/testdata/baseline_tg_test.go#BenchmarkThriftGetAll

2. 用例

• UnmarshalAll：反序列化所有字段。其中對(duì)于 dynamicgo 有兩種模式：

  • new：每次重新分配 DOM 內(nèi)存；
  • reuse：使用內(nèi)存池復(fù)用 DOM 內(nèi)存。

• MarshalAll：序列化所有字段。

3. 結(jié)果

• 簡(jiǎn)單（ns/OP）

• 復(fù)雜（ns/OP）

4. 結(jié)論

• dynamicgo 全量序列化 開(kāi)銷約為代碼生成方式的 6～3倍、泛化調(diào)用方式的 1/4～1/2，并且隨著數(shù)據(jù)量級(jí)增大優(yōu)勢(shì)減弱；

• Dynamigo 全量反序列化+內(nèi)存復(fù)用 場(chǎng)景下開(kāi)銷約為代碼生成方式的 1.8～0.7、泛化調(diào)用方式的 1/13～1/8，并且隨著數(shù)據(jù)量級(jí)增大優(yōu)勢(shì)加大。

04

應(yīng)用與展望

當(dāng)前，dynamicgo 已經(jīng)應(yīng)用到許多重要業(yè)務(wù)場(chǎng)景中，包括：

1. 業(yè)務(wù)隱私合規(guī) 中間件（thrift 反射）；
2. 抖音某 BFF 服務(wù)下游數(shù)據(jù)按需下發(fā)（thrift 裁剪）；
3. 字節(jié)跳動(dòng)某 API 網(wǎng)關(guān)協(xié)議轉(zhuǎn)換（JSON<>thrift 協(xié)議轉(zhuǎn)換）。

并且逐步上線并取得收益。目前 dynamic 還在迭代中，接下來(lái)的工作包括：

1. 集成到 Kitex 泛化調(diào)用模塊中，為更多用戶提供高性能的 thrift 泛化調(diào)用模塊；
2. Thrift DOM 接入 DSL（GraphQL）組件，進(jìn)一步提升 BFF 動(dòng)態(tài)網(wǎng)關(guān)性能；
3. 支持 Protobuf 協(xié)議。

也歡迎感興趣的個(gè)人或團(tuán)隊(duì)參與進(jìn)來(lái)，共同開(kāi)發(fā)！

GitHub：https://github.com/cloudwego

官網(wǎng)：www.cloudwego.io