本文選自“字節(jié)跳動基礎(chǔ)架構(gòu)實踐”系列文章。
“字節(jié)跳動基礎(chǔ)架構(gòu)實踐”系列文章是由字節(jié)跳動基礎(chǔ)架構(gòu)部門各技術(shù)團隊及專家傾力打造的技術(shù)干貨內(nèi)容，和大家分享團隊在基礎(chǔ)架構(gòu)發(fā)展和演進過程中的實踐經(jīng)驗與教訓(xùn)，與各位技術(shù)同學(xué)一起交流成長。
線上流量引流線下環(huán)境是一個通用需求，廣泛應(yīng)用于功能測試、壓測等場景。本文介紹了引流系統(tǒng)在字節(jié)跳動的發(fā)展過程和系統(tǒng)設(shè)計，希望能給大家?guī)硪稽c新的思考和收獲。
1. 背景
AB Test (diff 測試) 是在互聯(lián)網(wǎng)行業(yè)中比較常用的驗證方法，例如 google 通過 AB 實驗針對廣告和推薦的效果做驗證，Twitter 研發(fā)了 Diffy ，把 Diff 驗證能力應(yīng)用到了 API 接口的質(zhì)量保障上。通常 AB Test 有兩種形式，一種是線上多個服務(wù)版本，通過接入側(cè)分流 AB 來做實驗，但對于廣告這類場景，一旦某個模型有問題，就會造成資損。另外一個模式是通過線上的流量復(fù)制回放到內(nèi)部環(huán)境，這種方式對于生產(chǎn)是絕對安全的，例如 Twitter 的 AB 驗證服務(wù) diffy 就是走的這個模式。今天字節(jié)內(nèi)部推薦，廣告，等很多業(yè)務(wù)線都是通過線上流量實時回放的模式做 AB 實驗。為了滿足業(yè)務(wù)的需求，我們自研了一套線上流量錄制回放系統(tǒng) ByteCopy 來支撐業(yè)務(wù)的海量流量吞吐和不斷產(chǎn)生的對于流量錄制回放的新需求。
這篇文章會從業(yè)務(wù)場景、系統(tǒng)架構(gòu)、問題分析等幾個方面來介紹 ByteCopy 這套系統(tǒng)的演進過程。
2. 基于 TCPCopy 構(gòu)建第一代引流系統(tǒng)
2.1 業(yè)務(wù)需求
剛開始業(yè)務(wù)的需求還是比較簡單的，就是希望在業(yè)務(wù)方部署好了目標(biāo)服務(wù) (HTTP 和 RPC) 后，引流系統(tǒng)可以把對應(yīng)線上生產(chǎn)的流量復(fù)制一份并轉(zhuǎn)發(fā)過去，并且整個引流過程可以靈活管控，只在需要流量的時候開啟。
2.2 系統(tǒng)選型
從引流自身來看，主要分為 2 種類型，主路復(fù)制和旁路復(fù)制，我們分別來分析一下這兩種模式的優(yōu)劣。
2.2.1 主路復(fù)制
主路復(fù)制是指在調(diào)用鏈中進行流量復(fù)制：一種是在業(yè)務(wù)邏輯中進行流量復(fù)制，如在調(diào)用 API/RPC 過程中，由業(yè)務(wù)方編寫代碼邏輯，記錄 request / response 信息內(nèi)容；另外一種是在框架（如使用 Dubbo、Service Mesh 等網(wǎng)絡(luò)框架）處理邏輯中進行復(fù)制。
優(yōu)點
- 可以高度結(jié)合業(yè)務(wù)邏輯，實現(xiàn)細(xì)粒度定制化流量復(fù)制，比如可以只針對某個用戶的流量進行復(fù)制，可以最大程度上提升引流源上的有效流量采集比。
缺點
- 業(yè)務(wù)邏輯與引流邏輯耦合度較高，功能上相互影響。
- 每個請求都需要進行額外引流處理，對業(yè)務(wù)流程存在性能影響。
適用場景
- 對于流量有細(xì)粒度篩選要求的，或與業(yè)務(wù)邏輯有關(guān)，可以選擇主路復(fù)制；如 Service Mesh 中根據(jù)染色標(biāo)記，進行流量復(fù)制。
2.2.2 旁路復(fù)制
對比主路復(fù)制，旁路復(fù)制突出了業(yè)務(wù)無感知的特點，一般是由第三方服務(wù)在網(wǎng)絡(luò)協(xié)議棧中，監(jiān)聽復(fù)制流量
優(yōu)點
- 與業(yè)務(wù)解耦，可以獨立部署升級引流模塊，業(yè)務(wù)方無需關(guān)注引流功能實現(xiàn)；通過在協(xié)議棧底層進行流量復(fù)制，性能較好。
缺點
- 4 層網(wǎng)卡層面的網(wǎng)絡(luò)包抓取后，仍需要進行數(shù)據(jù)包的重組和解析，需要額外的消耗計算資源。
- 往往需要全量抓包解析再進行篩選，無法結(jié)合業(yè)務(wù)邏輯進行定制化的采樣。
開源方案 TCPCopy
雖然 linux 提供了 libpcap 這樣的底層 packet capture 庫，不過本著快速交付業(yè)務(wù)需求的目標(biāo)，我們選擇了開源的 TCPCopy 來作為整個引流系統(tǒng)的核心基礎(chǔ)。TCPCopy 在這里就不多介紹，只在下面附上一張簡單的架構(gòu)圖，其中 TCPCopy 和 Intercept 是 TCPCopy 的兩個組件，相關(guān)細(xì)節(jié)感興趣的同學(xué)可以自行查找資料。
TCPCopy 的主要優(yōu)勢：
- 協(xié)議無感知，可以透明轉(zhuǎn)發(fā)，能夠支持基于 TCP 的任意應(yīng)用層協(xié)議，如 MySQL，Kafka，redis 等
- 實時轉(zhuǎn)發(fā)，延時較低
- 可以保留原始請求 IP 端口信息，測試服務(wù)器可用于統(tǒng)計
同時，也具有以下不足：
- 無法動態(tài)添加多個下游服務(wù)器
- 由于透明轉(zhuǎn)發(fā)，不做協(xié)議解析，無法發(fā)現(xiàn)數(shù)據(jù)異常，如部分 TCP 包丟失，測試服務(wù)器將收到不完整的數(shù)據(jù)；此外，也無法對應(yīng)用層數(shù)據(jù)進行篩選和修改進行修改
- 核心組件設(shè)計時未進行多線程設(shè)計，處理能力存在瓶頸
- 需要修改 iptables 來丟棄下游服務(wù)的回包，用在生產(chǎn)或公共的測試環(huán)境存在較大風(fēng)險
為了滿足字節(jié)的需求，我們在整體架構(gòu)上引入了一些其他組件來彌補 TCPCopy 自身的不足。
2.3 系統(tǒng)架構(gòu)
為了解決 TCPCopy 存在的不足，我們在通過 TCPCopy 直接進行流量轉(zhuǎn)發(fā)的方案基礎(chǔ)上又進行了一些優(yōu)化。
首先，在 TCPCopy 和被測服務(wù)之間額外引入了七層代理進行數(shù)據(jù)轉(zhuǎn)發(fā)。七層代理本身可以校驗請求的完整性，避免不完整的請求被轉(zhuǎn)發(fā)到測試服務(wù)對干擾測試造成干擾。
此外，我們將七層代理和 TCPCopy 的 intercept 組件部署在一批專用于流量轉(zhuǎn)發(fā)的服務(wù)器上，進行轉(zhuǎn)發(fā)任務(wù)時只需要修改這批服務(wù)器的 iptables ，而被測服務(wù)只需在測試機上正常運行，不用進行額外配置，因此可以盡量避免修改 iptables 帶來的風(fēng)險。
為了能夠更好地融入公司的技術(shù)生態(tài)系統(tǒng)，同時支持更豐富的測試場景，我們還專門實現(xiàn)了一個用于測試的七層代理。具體加入了以下能力：
- 接入了公司的服務(wù)發(fā)現(xiàn)框架，被測實例只需注冊指定的服務(wù)名，就可以收到代理發(fā)送的流量。因此流量可以被同時轉(zhuǎn)發(fā)到多個被測實例，也可以動態(tài)地添加或刪除被測實例
- 支持流量過濾。從收到的流量中篩選出指定方法的流量進行轉(zhuǎn)發(fā)。比如可以過濾掉轉(zhuǎn)發(fā)流量中包含寫操作的流量，從而避免對存儲造成污染
- 引入流控機制。支持對轉(zhuǎn)發(fā)的流量進行限速，以及通過將收到的請求多次重復(fù)發(fā)送實現(xiàn)加壓，從而支持簡單的壓測場景
最后，為了讓引流功能變得易用，我們把 TCPCopy 的兩個組件，以及我們的七層代理進行了封裝，打包成了一個平臺提供給用戶。用戶只需要指定引流源和被測服務(wù)的 IP 和端口，以及引流任務(wù)的持續(xù)時間，即可進行一次引流測試。
線上的整體架構(gòu)大概如下圖所示，用戶提交任務(wù)后，我們會負(fù)責(zé)進行各個組件的調(diào)度、配置和部署，將流量從線上轉(zhuǎn)發(fā)到用戶的待測實例。
2.5 存在的問題
隨著規(guī)模的逐漸發(fā)展和更多用戶場景的提出，這套架構(gòu)也逐漸暴露出了一些問題。
2.5.1 TCPCopy 存在性能問題
TCPCopy 在實現(xiàn)上沒有進行多線程的設(shè)計，因此實際的轉(zhuǎn)發(fā)吞吐能力較為有限，對于一些高帶寬的測試場景無法很好地支持。
2.5.2 現(xiàn)有實現(xiàn)無法支持響應(yīng)錄制等更多場景
TCPCopy 定位只是請求復(fù)制轉(zhuǎn)發(fā)工具，只會復(fù)制線上流量的請求部分，而不會復(fù)制線上流量的響應(yīng)。我們接到了一些想要對線上流量進行分析的用戶的需求，他們希望能夠同時收集線上流量的請求和響應(yīng)，TCPCopy 沒法支持這類場景。
3. 自研 ByteCopy，開啟海量流量和復(fù)雜業(yè)務(wù)場景的支持
前面提到了第一代引流系統(tǒng)存在一些性能和靈活性的問題，與此同時業(yè)務(wù)也提出了一些新的需求，例如支持 MySQL 協(xié)議，支持歷史流量的存儲和回放等。考慮到在現(xiàn)有的 TCPCopy 的架構(gòu)上很難做擴展，所以我們考慮推翻現(xiàn)有架構(gòu)，重新構(gòu)建字節(jié)新一代的引流系統(tǒng) - ByteCopy (寓意是復(fù)制線上每一個字節(jié))
在以上演進的基礎(chǔ)上，我們可以按職責(zé)把七層流量復(fù)制大致分解為下面三個模塊
- 流量采集
- 流量解析
- 流量應(yīng)用
針對 3 個模塊我們分別展開介紹
3.1 流量采集
流量采集模塊會依據(jù)服務(wù)部署的平臺以不同方式拉起，如在 Kubernetes 會由 Mesh Agent 喚起，使用 libpcap 監(jiān)聽特定端口流量，在用戶態(tài)重組 TCP 層包，batch 發(fā)送至 Kafka。
默認(rèn)場景下，流量采集模塊只會對被采集的服務(wù)監(jiān)聽的 IP 和端口進行抓包。此外，為了提供出口流量采集（即采集某一服務(wù)對其下游依賴發(fā)的調(diào)用）的能力，流量采集模塊還對接了公司的服務(wù)發(fā)現(xiàn)框架。在需要對出口流量進行采集時，流量采集模塊會查詢下游依賴服務(wù)所有實例的 IP 和端口，對這部分流量也進行采集。（這一方案存在一定問題，后續(xù)會詳細(xì)介紹）
由于流量采集進程和應(yīng)用進程是部署在同個 Docker 實例或物理機里，業(yè)務(wù)會對流量采集模塊的資源占用比較敏感，我們除了在代碼層優(yōu)化，還會用 cgroups 對資源使用做硬性限制。
此外流量采集平臺是多租戶設(shè)計，對一個服務(wù)可能同時存在多個用戶的不同規(guī)格的采集需求，如用戶 A 希望采集 env1 環(huán)境 5% 實例流量，用戶 B 希望采集 env1 環(huán)境 1 個實例的流量及 env2 環(huán)境 1 個實例的流量，如果簡單地獨立處理用戶 A 和 B 的請求，會出現(xiàn) env1 環(huán)境部署 5%+1 實例 env2 部署 1 實例這種冗余部署。我們的做法是把用戶的請求規(guī)格和采集模塊的實際部署解耦，用戶提交一個規(guī)格請求后，會先和已有的規(guī)格合并，得到一個最小部署方案，然后更新部署狀態(tài)。
3.2 流量解析
引流源采集上來的原始流量還是第四層協(xié)議，為了支持一些更復(fù)雜的功能，比如過濾，多路輸出，歷史流量存儲，流量查詢及流量可視化等等，我們需要將四層流量解析到七層。字節(jié)跳動內(nèi)部服務(wù)使用得比較多的協(xié)議是 Thrift 和 HTTP ，這兩個根據(jù)協(xié)議規(guī)范即可很好地完成解析。
流量解析有一個難點是判斷流量的邊界，區(qū)別于 HTTP/2 等的 Pipeline 連接復(fù)用傳輸形式，Thrift 和 HTTP/1.X 在單條連接上嚴(yán)格按照請求-響應(yīng)對來進行傳輸，因此可以通過請求和響應(yīng)的切換分隔出完整的請求或響應(yīng)流量。
3.3 流量應(yīng)用
對于線上采集的流量，不同用戶會有不同的業(yè)務(wù)用途，如壓測平臺可能希望將流量先持久化到 Kafka，然后利用 Kafka 的高吞吐發(fā)壓；有些研發(fā)同學(xué)只是簡單從線上引一份流量轉(zhuǎn)發(fā)到自己的開發(fā)環(huán)境做新特性測試；有些同學(xué)希望轉(zhuǎn)發(fā) QPS 能達(dá)到一定水位以實現(xiàn)壓測的目的；還有的是特定流量會觸發(fā)線上 coredump ，他們希望把這段流量錄制下來線下 debug 等等。針對不同的場景，我們實現(xiàn)了若干流量輸出形式。
下面會著重介紹轉(zhuǎn)發(fā)和存儲。
3.3.1 轉(zhuǎn)發(fā)
結(jié)構(gòu)如上圖，emitter 會在 zookeeper 上注冊自身，scheduler 感知到 emitter 節(jié)點信息，將任務(wù)根據(jù)各個 emitter 節(jié)點的標(biāo)簽和統(tǒng)計信息過濾/打分，然后調(diào)度到最合適的節(jié)點上。這里有個問題是為什么不直接使用無狀態(tài)服務(wù)，由每個 emitter 實例均等地轉(zhuǎn)發(fā)，而采用 sharding 方案，主要是基于下面幾點考慮:
- 如果每個任務(wù)均攤到所有實例上執(zhí)行，那每個實例需要和全部下游 endpoint 建立連接，在海量任務(wù)下的 goroutine、連接、內(nèi)存等資源占用是不可接受的
- 通過將單個任務(wù)的處理收斂到少數(shù)實例上，提高了對單個 endpoint 的請求密度，從而避免因為連接 idle 時間過長被對端 close，復(fù)用了連接。
由于 emitter 對性能比較敏感，我們?yōu)榇艘沧隽撕芏鄡?yōu)化，比如使用了 fasthttp 的 goroutine 池避免頻繁申請 goroutine，對連接的 reader/writer 對象池化，動態(tài)調(diào)節(jié)每個 endpoint 的工作線程數(shù)量以自適應(yīng)用戶指定 QPS，避免 goroutine 浪費及閑置長連接退化成短連接，全程無鎖化，通過 channel+select 做線程同步和數(shù)據(jù)傳遞等等。
3.3.2 存儲
存儲分為了兩層，數(shù)據(jù)層和索引層，采用雙寫模型，并有定時任務(wù)從數(shù)據(jù)層糾錯索引層保證兩者的最終一致性。存儲需 要支持回放和查詢兩種語義，Data Layer 抽象成了一個支持 KV 查詢，按 Key 有序，大容量的存儲模型，Index Layer 是 Multi-index->Key 映射模型，通過這兩層即可滿足流量查詢+回放的需求。所以 Data Layer 和 Index Layer 底層實現(xiàn)是模塊化的，只需符合上述模型并實現(xiàn)模型定義 API。
Data Layer 的理想數(shù)據(jù)結(jié)構(gòu)是 LSM tree，寫入性能出色，對于流量回放場景，需要按 key 有序掃描流量記錄，因為 LSM 滿足按 key 的局部性和有序性，可以充分利用 page cache 和磁盤順序讀達(dá)到較高回放性能。分布式 LSM Tree 業(yè)界比較成熟的開源產(chǎn)品是 HBase，字節(jié)跳動內(nèi)部也有對標(biāo)產(chǎn)品 Bytable，我們同時實現(xiàn)了基于這兩個引擎的 Data Layer，經(jīng)過一系列性能 benchmark 我們選擇了 Bytable 作為 Data Layer 實現(xiàn)。
Index Layer 使用了 ES 的能力，因而可以支持用戶的復(fù)合條件查詢，我們會預(yù)先內(nèi)置一些查詢索引，如源服務(wù)，目標(biāo)服務(wù)，方法名，traceid 等等，流量查詢目前的使用場景一個是作為服務(wù) mock 的數(shù)據(jù)源，可以屏蔽掉功能測試或者 diff 中不必要的外部依賴，還有一個功能是流量可視化，用戶通過請求時間，traceid 等等，查看特定請求的內(nèi)容。其他場景功能還有待進一步發(fā)掘。
3.4 業(yè)務(wù)場景支持
3.4.1 支持通用的 diff 能力
Diff 驗證是互聯(lián)網(wǎng)公司在快速迭代下保持產(chǎn)品質(zhì)量的一個利器，類似 Twtiter 的 Diffy 項目，都是通過線上流量的錄制回放來實現(xiàn)。但是它的適用場景也很有限，因為是直接在生產(chǎn)環(huán)境上通過 AB 環(huán)境做回放，無法支持寫的流量。雖然阿里巴巴的 doom 平臺可以解決寫場景的回放隔離問題，但是它是在應(yīng)用程序中通過 AOP 來實現(xiàn)的，強綁定 JAVA 生態(tài)。
通過 ByteCopy 的無侵入引流和流量存儲回放能力，結(jié)合我們自研的 ByteMock 組件，我們提供了面向業(yè)務(wù)的無侵入 diff 解決方案，并解決了寫隔離的問題。
在一個生產(chǎn)環(huán)境下的 (A,B,C) 鏈路中，通過 ByteCopy 實現(xiàn)了針對每一跳 (request, response) 的采集，在做 A 的 diff 驗證的時候，通過 ByteCopy 實現(xiàn)對于 A 服務(wù)請求的回放，同時，基于 ByteMock 來實現(xiàn)對于服務(wù) B 的 mock，并支持針對一個 trace 的 response 回放 (依賴 ByteCopy 中流量存儲，實現(xiàn)精準(zhǔn)的回放)。因為 B 是 mock 的，即使是一個寫的請求，也可以做到對于線上沒有任何影響。
4. 未來展望
4.1 更精準(zhǔn)的流量采集
前面提到，在進行出口流量的采集時，會對下游依賴服務(wù)的所有實例的 IP:端口 進行抓包。而實際的生產(chǎn)環(huán)境中，同一臺服務(wù)器上，可能會部署具有相同下游依賴的多個服務(wù)，只依賴四層數(shù)據(jù)，無法判斷抓到的數(shù)據(jù)到底來自哪一個服務(wù)，會造成抓包、處理和轉(zhuǎn)發(fā)流程中都會存在資源浪費的問題。目前來看基于網(wǎng)卡抓包的方案應(yīng)該沒法很好地解決這個問題，我們也在嘗試探索一些其他的流量采集的方案，比如探索用 ebpf 進行進程級別的流量采集。
4.2 引流回放系統(tǒng)的重新定義
現(xiàn)階段我們的引流回放系統(tǒng)只會根據(jù)用戶的配置被動進行流量采集，而為了及時拿到流量進行測試，用戶一般都會選擇實時引流進行測試。而實際上并不是所有的場景都一定需要實時的流量進行測試，我們在規(guī)劃逐步將引流回放系統(tǒng)從一個按照用戶要求進行流量轉(zhuǎn)發(fā)回放的工具，轉(zhuǎn)變?yōu)橐粋€線上復(fù)制流量的取用的平臺。
在流量存儲能力的基礎(chǔ)上，對于有測試需求的服務(wù)，平臺主動錯峰、定時發(fā)起流量錄制任務(wù)，從而維護一個不斷更新的流量池，用戶需要流量時直接從流量池中取用，這樣一來，既可以盡量避免引流操作對和線上業(yè)務(wù)搶占計算資源，也可以使得流量的可用性更高。
4.3 特定場景下的流量存儲優(yōu)化
隨著基于流量錄制回放的上層應(yīng)用的完善，為了更多的業(yè)務(wù)方便接入試用，我們正在考慮朝著常態(tài)化的引流去演進。這個勢必對我們的流量存儲帶來新的挑戰(zhàn)，無論是的數(shù)據(jù)規(guī)模，存儲形態(tài)以及查詢性能。我們希望可以基于現(xiàn)有架構(gòu)的存儲系統(tǒng)，構(gòu)建流量存儲的解決方案，支持海量數(shù)據(jù)吞吐的同時，能夠支持點查(基于 TraceId )，和 time-range scan 等多種復(fù)雜的高性能查詢方式。另外我們也在積極和安全團隊合作，確保相關(guān)核心流量數(shù)據(jù)在存儲時候能夠?qū)崿F(xiàn)脫敏，同時不斷強化對于流量存儲使用的安全審計。
5. 總結(jié)
到今天為止，ByteCopy 系統(tǒng)已經(jīng)支撐了字節(jié)絕大部分業(yè)務(wù)線在不同場景下的各種引流需求， 我們一直在努力豐富 ByteCopy 的功能場景，不斷提升系統(tǒng)穩(wěn)定性和吞吐容量，此外我們也在積極構(gòu)建 ByteMock 等自研的研發(fā)組件，通過和 ByteCopy 形成組合拳，解鎖生產(chǎn)流量在研發(fā)活動中更多的使用場景，幫助業(yè)務(wù)團隊更好地去構(gòu)建各種有趣的產(chǎn)品。
字節(jié)跳動基礎(chǔ)架構(gòu)團隊
字節(jié)跳動基礎(chǔ)架構(gòu)團隊是支撐字節(jié)跳動旗下包括抖音、今日頭條、西瓜視頻、火山小視頻在內(nèi)的多款億級規(guī)模用戶產(chǎn)品平穩(wěn)運行的重要團隊，為字節(jié)跳動及旗下業(yè)務(wù)的快速穩(wěn)定發(fā)展提供了保證和推動力。
公司內(nèi)，基礎(chǔ)架構(gòu)團隊主要負(fù)責(zé)字節(jié)跳動私有云建設(shè)，管理數(shù)以萬計服務(wù)器規(guī)模的集群，負(fù)責(zé)數(shù)萬臺計算/存儲混合部署和在線/離線混合部署，支持若干 EB 海量數(shù)據(jù)的穩(wěn)定存儲。
文化上，團隊積極擁抱開源和創(chuàng)新的軟硬件架構(gòu)。我們長期招聘基礎(chǔ)架構(gòu)方向的同學(xué)，具體可參見 job.bytedance.com （文末“閱讀原文”），感興趣可以聯(lián)系郵箱 guoxinyu.0372@bytedance.com 。
