01

背景

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

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

02

設計與實現(xiàn)

對于 thrift 反射代理的使用場景，歸納起來有如下使用需求：

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

這里我們參考了 Go reflect 的設計思想，把通過IDL解析得到的準靜態(tài)類型描述（只需跟隨 IDL 更新一次）TypeDescriptor 和 原始數(shù)據(jù)單元 Node 打包成一個完全自描述的結構——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ù)單元長度
}
//Node+類型描述descriptor
typeValuestruct{
Node
Descthrift.TypeDescriptor
}

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

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

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

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

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

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

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

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

要用 DOM 來描述一個 Thrift 結構體，首先需要一個能準確描述數(shù)據(jù)節(jié)點之間的關系的定位方式—— Path。其類型應該包括 list index、map key 以及 struct field id等。

typePathTypeuint8

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

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

在 Path 的基礎上，我們組合對應的數(shù)據(jù)單元Node，然后再通過一個Next 數(shù)組動態(tài)存儲子節(jié)點，便可以組裝成一個類似于BTree的泛型結構。

圖2 thrift DOM 數(shù)據(jù)結構

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

03

性能測試

這里我們分別定義簡單（Small)、復雜（Medium) 兩個基準結構體分別在比較 不同數(shù)據(jù)量級 下的性能，同時添加簡單部分（SmallPartial）、復雜部分（MediumPartial） 兩個對應子集，用于【反射-裁剪】場景的性能比較：

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

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

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è)務場景劃分為 反射、協(xié)議轉(zhuǎn)換、全量序列化/反序列化 三套 API，并以代碼生成庫kitex/FastAPI、泛化調(diào)用庫kitex/generic、JSON 庫sonic為基準進行性能測試。其它測試環(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個數(shù)據(jù)字段
• GetMany：查找前中后5個數(shù)據(jù)字段
• MarshalMany：將 GetMany 中的結果進行二次序列化
• SetOne：設置最后一個數(shù)據(jù)字段
• SetMany：設置前中后3個節(jié)點數(shù)據(jù)
• MarshalTo：將大 Thrift 數(shù)據(jù)包裁剪為小 thrift 數(shù)據(jù)包 （Small -> SmallPartial 或 Medium -> MediumParital）
• UnmarshalAll+MarshalPartial：代碼生成/泛化調(diào)用方式裁剪——先反序列化全量數(shù)據(jù)再序列化部分數(shù)據(jù)。效果等同于 MarshalTo。

3. 結果

• 簡單（ns/OP）

• 復雜（ns/OP）

4. 結論

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

協(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)換為等價結構的 thrift 數(shù)據(jù)
• thrift2JSON：將 thrift 數(shù)據(jù)轉(zhuǎn)換為等價結構的 JSON 數(shù)據(jù)
• sonic + kitex-fast：表示通過 sonic 處理 json 數(shù)據(jù)（有結構體），通過kitex代碼生成處理thrift數(shù)據(jù)

3. 結果

• 簡單（ns/OP）

• 復雜（ns/OP）

4. 結論

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

全量序列化/反序列化

1. 代碼

dynamicgo/testdata/baseline_tg_test.go#BenchmarkThriftGetAll

2. 用例

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

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

• MarshalAll：序列化所有字段。

3. 結果

• 簡單（ns/OP）

• 復雜（ns/OP）

4. 結論

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

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

04

應用與展望

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

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

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

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

也歡迎感興趣的個人或團隊參與進來，共同開發(fā)！

GitHub：https://github.com/cloudwego

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