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