本文選自“字節(jié)跳動基礎(chǔ)架構(gòu)實(shí)踐”系列文章。

 

“字節(jié)跳動基礎(chǔ)架構(gòu)實(shí)踐”系列文章是由字節(jié)跳動基礎(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)用于功能測試、壓測等場景。本文介紹了引流系統(tǒng)在字節(jié)跳動的發(fā)展過程和系統(tǒng)設(shè)計(jì)，希望能給大家?guī)硪稽c(diǎn)新的思考和收獲。

1. 背景

AB Test (diff 測試) 是在互聯(lián)網(wǎng)行業(yè)中比較常用的驗(yàn)證方法，例如 google 通過 AB 實(shí)驗(yàn)針對廣告和推薦的效果做驗(yàn)證，Twitter 研發(fā)了 Diffy ，把 Diff 驗(yàn)證能力應(yīng)用到了 API 接口的質(zhì)量保障上。通常 AB Test 有兩種形式，一種是線上多個(gè)服務(wù)版本，通過接入側(cè)分流 AB 來做實(shí)驗(yàn)，但對于廣告這類場景，一旦某個(gè)模型有問題，就會造成資損。另外一個(gè)模式是通過線上的流量復(fù)制回放到內(nèi)部環(huán)境，這種方式對于生產(chǎn)是絕對安全的，例如 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)生的對于流量錄制回放的新需求。

這篇文章會從業(yè)務(wù)場景、系統(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)可以把對應(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ù)制，比如可以只針對某個(gè)用戶的流量進(jìn)行復(fù)制，可以最大程度上提升引流源上的有效流量采集比。

缺點(diǎn)

• 業(yè)務(wù)邏輯與引流邏輯耦合度較高，功能上相互影響。
• 每個(gè)請求都需要進(jìn)行額外引流處理，對業(yè)務(wù)流程存在性能影響。

適用場景

• 對于流量有細(xì)粒度篩選要求的，或與業(yè)務(wù)邏輯有關(guān)，可以選擇主路復(fù)制；如 Service Mesh 中根據(jù)染色標(biāo)記，進(jìn)行流量復(fù)制。

2.2.2 旁路復(fù)制

對比主路復(fù)制，旁路復(fù)制突出了業(yè)務(wù)無感知的特點(diǎn)，一般是由第三方服務(wù)在網(wǎng)絡(luò)協(xié)議棧中，監(jiān)聽復(fù)制流量

優(yōu)點(diǎn)

• 與業(yè)務(wù)解耦，可以獨(dú)立部署升級引流模塊，業(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)勢：

• 協(xié)議無感知，可以透明轉(zhuǎn)發(fā)，能夠支持基于 TCP 的任意應(yīng)用層協(xié)議，如 MySQL，Kafka，redis 等
• 實(shí)時(shí)轉(zhuǎn)發(fā)，延時(shí)較低
• 可以保留原始請求 IP 端口信息，測試服務(wù)器可用于統(tǒng)計(jì)

同時(shí)，也具有以下不足：

• 無法動態(tài)添加多個(gè)下游服務(wù)器
• 由于透明轉(zhuǎn)發(fā)，不做協(xié)議解析，無法發(fā)現(xiàn)數(shù)據(jù)異常，如部分 TCP 包丟失，測試服務(wù)器將收到不完整的數(shù)據(jù)；此外，也無法對應(yīng)用層數(shù)據(jù)進(jìn)行篩選和修改進(jìn)行修改
• 核心組件設(shè)計(jì)時(shí)未進(jìn)行多線程設(shè)計(jì)，處理能力存在瓶頸
• 需要修改 iptables 來丟棄下游服務(wù)的回包，用在生產(chǎn)或公共的測試環(huán)境存在較大風(fēng)險(xiǎn)

為了滿足字節(jié)的需求，我們在整體架構(gòu)上引入了一些其他組件來彌補(bǔ) TCPCopy 自身的不足。

2.3 系統(tǒng)架構(gòu)

為了解決 TCPCopy 存在的不足，我們在通過 TCPCopy 直接進(jìn)行流量轉(zhuǎn)發(fā)的方案基礎(chǔ)上又進(jìn)行了一些優(yōu)化。

首先，在 TCPCopy 和被測服務(wù)之間額外引入了七層代理進(jìn)行數(shù)據(jù)轉(zhuǎn)發(fā)。七層代理本身可以校驗(yàn)請求的完整性，避免不完整的請求被轉(zhuǎn)發(fā)到測試服務(wù)對干擾測試造成干擾。

此外，我們將七層代理和 TCPCopy 的 intercept 組件部署在一批專用于流量轉(zhuǎn)發(fā)的服務(wù)器上，進(jìn)行轉(zhuǎn)發(fā)任務(wù)時(shí)只需要修改這批服務(wù)器的 iptables ，而被測服務(wù)只需在測試機(jī)上正常運(yùn)行，不用進(jìn)行額外配置，因此可以盡量避免修改 iptables 帶來的風(fēng)險(xiǎn)。

為了能夠更好地融入公司的技術(shù)生態(tài)系統(tǒng)，同時(shí)支持更豐富的測試場景，我們還專門實(shí)現(xiàn)了一個(gè)用于測試的七層代理。具體加入了以下能力：

• 接入了公司的服務(wù)發(fā)現(xiàn)框架，被測實(shí)例只需注冊指定的服務(wù)名，就可以收到代理發(fā)送的流量。因此流量可以被同時(shí)轉(zhuǎn)發(fā)到多個(gè)被測實(shí)例，也可以動態(tài)地添加或刪除被測實(shí)例
• 支持流量過濾。從收到的流量中篩選出指定方法的流量進(jìn)行轉(zhuǎn)發(fā)。比如可以過濾掉轉(zhuǎn)發(fā)流量中包含寫操作的流量，從而避免對存儲造成污染
• 引入流控機(jī)制。支持對轉(zhuǎn)發(fā)的流量進(jìn)行限速，以及通過將收到的請求多次重復(fù)發(fā)送實(shí)現(xiàn)加壓，從而支持簡單的壓測場景

最后，為了讓引流功能變得易用，我們把 TCPCopy 的兩個(gè)組件，以及我們的七層代理進(jìn)行了封裝，打包成了一個(gè)平臺提供給用戶。用戶只需要指定引流源和被測服務(wù)的 IP 和端口，以及引流任務(wù)的持續(xù)時(shí)間，即可進(jìn)行一次引流測試。

線上的整體架構(gòu)大概如下圖所示，用戶提交任務(wù)后，我們會負(fù)責(zé)進(jìn)行各個(gè)組件的調(diào)度、配置和部署，將流量從線上轉(zhuǎn)發(fā)到用戶的待測實(shí)例。

2.5 存在的問題

隨著規(guī)模的逐漸發(fā)展和更多用戶場景的提出，這套架構(gòu)也逐漸暴露出了一些問題。

2.5.1 TCPCopy 存在性能問題

TCPCopy 在實(shí)現(xiàn)上沒有進(jìn)行多線程的設(shè)計(jì)，因此實(shí)際的轉(zhuǎn)發(fā)吞吐能力較為有限，對于一些高帶寬的測試場景無法很好地支持。

2.5.2 現(xiàn)有實(shí)現(xiàn)無法支持響應(yīng)錄制等更多場景

TCPCopy 定位只是請求復(fù)制轉(zhuǎn)發(fā)工具，只會復(fù)制線上流量的請求部分，而不會復(fù)制線上流量的響應(yīng)。我們接到了一些想要對線上流量進(jìn)行分析的用戶的需求，他們希望能夠同時(shí)收集線上流量的請求和響應(yīng)，TCPCopy 沒法支持這類場景。

3. 自研 ByteCopy，開啟海量流量和復(fù)雜業(yè)務(wù)場景的支持

前面提到了第一代引流系統(tǒng)存在一些性能和靈活性的問題，與此同時(shí)業(yè)務(wù)也提出了一些新的需求，例如支持 MySQL 協(xié)議，支持歷史流量的存儲和回放等?？紤]到在現(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)用

針對 3 個(gè)模塊我們分別展開介紹

3.1 流量采集

流量采集模塊會依據(jù)服務(wù)部署的平臺以不同方式拉起，如在 Kubernetes 會由 Mesh Agent 喚起，使用 libpcap 監(jiān)聽特定端口流量，在用戶態(tài)重組 TCP 層包，batch 發(fā)送至 Kafka。

默認(rèn)場景下，流量采集模塊只會對被采集的服務(wù)監(jiān)聽的 IP 和端口進(jìn)行抓包。此外，為了提供出口流量采集（即采集某一服務(wù)對其下游依賴發(fā)的調(diào)用）的能力，流量采集模塊還對接了公司的服務(wù)發(fā)現(xiàn)框架。在需要對出口流量進(jìn)行采集時(shí)，流量采集模塊會查詢下游依賴服務(wù)所有實(shí)例的 IP 和端口，對這部分流量也進(jìn)行采集。（這一方案存在一定問題，后續(xù)會詳細(xì)介紹）

由于流量采集進(jìn)程和應(yīng)用進(jìn)程是部署在同個(gè) Docker 實(shí)例或物理機(jī)里，業(yè)務(wù)會對流量采集模塊的資源占用比較敏感，我們除了在代碼層優(yōu)化，還會用 cgroups 對資源使用做硬性限制。

此外流量采集平臺是多租戶設(shè)計(jì)，對一個(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 的請求，會出現(xiàn) env1 環(huán)境部署 5%+1 實(shí)例 env2 部署 1 實(shí)例這種冗余部署。我們的做法是把用戶的請求規(guī)格和采集模塊的實(shí)際部署解耦，用戶提交一個(gè)規(guī)格請求后，會先和已有的規(guī)格合并，得到一個(gè)最小部署方案，然后更新部署狀態(tài)。

3.2 流量解析

引流源采集上來的原始流量還是第四層協(xié)議，為了支持一些更復(fù)雜的功能，比如過濾，多路輸出，歷史流量存儲，流量查詢及流量可視化等等，我們需要將四層流量解析到七層。字節(jié)跳動內(nèi)部服務(wù)使用得比較多的協(xié)議是 Thrift 和 HTTP ，這兩個(gè)根據(jù)協(xié)議規(guī)范即可很好地完成解析。

流量解析有一個(gè)難點(diǎn)是判斷流量的邊界，區(qū)別于 HTTP/2 等的 Pipeline 連接復(fù)用傳輸形式，Thrift 和 HTTP/1.X 在單條連接上嚴(yán)格按照請求-響應(yīng)對來進(jìn)行傳輸，因此可以通過請求和響應(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á)到一定水位以實(shí)現(xiàn)壓測的目的；還有的是特定流量會觸發(fā)線上 coredump ，他們希望把這段流量錄制下來線下 debug 等等。針對不同的場景，我們實(shí)現(xiàn)了若干流量輸出形式。

下面會著重介紹轉(zhuǎn)發(fā)和存儲。

3.3.1 轉(zhuǎn)發(fā)

結(jié)構(gòu)如上圖，emitter 會在 zookeeper 上注冊自身，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)考慮:

1. 如果每個(gè)任務(wù)均攤到所有實(shí)例上執(zhí)行，那每個(gè)實(shí)例需要和全部下游 endpoint 建立連接，在海量任務(wù)下的 goroutine、連接、內(nèi)存等資源占用是不可接受的
2. 通過將單個(gè)任務(wù)的處理收斂到少數(shù)實(shí)例上，提高了對單個(gè) endpoint 的請求密度，從而避免因?yàn)檫B接 idle 時(shí)間過長被對端 close，復(fù)用了連接。

由于 emitter 對性能比較敏感，我們?yōu)榇艘沧隽撕芏鄡?yōu)化，比如使用了 fasthttp 的 goroutine 池避免頻繁申請 goroutine，對連接的 reader/writer 對象池化，動態(tài)調(diào)節(jié)每個(gè) endpoint 的工作線程數(shù)量以自適應(yīng)用戶指定 QPS，避免 goroutine 浪費(fèi)及閑置長連接退化成短連接，全程無鎖化，通過 channel+select 做線程同步和數(shù)據(jù)傳遞等等。

3.3.2 存儲

存儲分為了兩層，數(shù)據(jù)層和索引層，采用雙寫模型，并有定時(shí)任務(wù)從數(shù)據(jù)層糾錯(cuò)索引層保證兩者的最終一致性。存儲需 要支持回放和查詢兩種語義，Data Layer 抽象成了一個(gè)支持 KV 查詢，按 Key 有序，大容量的存儲模型，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，寫入性能出色，對于流量回放場景，需要按 key 有序掃描流量記錄，因?yàn)?LSM 滿足按 key 的局部性和有序性，可以充分利用 page cache 和磁盤順序讀達(dá)到較高回放性能。分布式 LSM Tree 業(yè)界比較成熟的開源產(chǎn)品是 HBase，字節(jié)跳動內(nèi)部也有對標(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ù)合條件查詢，我們會預(yù)先內(nèi)置一些查詢索引，如源服務(wù)，目標(biāo)服務(wù)，方法名，traceid 等等，流量查詢目前的使用場景一個(gè)是作為服務(wù) mock 的數(shù)據(jù)源，可以屏蔽掉功能測試或者 diff 中不必要的外部依賴，還有一個(gè)功能是流量可視化，用戶通過請求時(shí)間，traceid 等等，查看特定請求的內(nèi)容。其他場景功能還有待進(jìn)一步發(fā)掘。

3.4 業(yè)務(wù)場景支持

3.4.1 支持通用的 diff 能力

Diff 驗(yàn)證是互聯(lián)網(wǎng)公司在快速迭代下保持產(chǎn)品質(zhì)量的一個(gè)利器，類似 Twtiter 的 Diffy 項(xiàng)目，都是通過線上流量的錄制回放來實(shí)現(xiàn)。但是它的適用場景也很有限，因?yàn)槭侵苯釉谏a(chǎn)環(huán)境上通過 AB 環(huán)境做回放，無法支持寫的流量。雖然阿里巴巴的 doom 平臺可以解決寫場景的回放隔離問題，但是它是在應(yīng)用程序中通過 AOP 來實(shí)現(xiàn)的，強(qiáng)綁定 JAVA 生態(tài)。

通過 ByteCopy 的無侵入引流和流量存儲回放能力，結(jié)合我們自研的 ByteMock 組件，我們提供了面向業(yè)務(wù)的無侵入 diff 解決方案，并解決了寫隔離的問題。

在一個(gè)生產(chǎn)環(huán)境下的 (A,B,C) 鏈路中，通過 ByteCopy 實(shí)現(xiàn)了針對每一跳 (request, response) 的采集，在做 A 的 diff 驗(yàn)證的時(shí)候，通過 ByteCopy 實(shí)現(xiàn)對于 A 服務(wù)請求的回放，同時(shí)，基于 ByteMock 來實(shí)現(xiàn)對于服務(wù) B 的 mock，并支持針對一個(gè) trace 的 response 回放 (依賴 ByteCopy 中流量存儲，實(shí)現(xiàn)精準(zhǔn)的回放)。因?yàn)?B 是 mock 的，即使是一個(gè)寫的請求，也可以做到對于線上沒有任何影響。

4. 未來展望

4.1 更精準(zhǔn)的流量采集

前面提到，在進(jìn)行出口流量的采集時(shí)，會對下游依賴服務(wù)的所有實(shí)例的 IP:端口 進(jìn)行抓包。而實(shí)際的生產(chǎn)環(huán)境中，同一臺服務(wù)器上，可能會部署具有相同下游依賴的多個(gè)服務(wù)，只依賴四層數(shù)據(jù)，無法判斷抓到的數(shù)據(jù)到底來自哪一個(gè)服務(wù)，會造成抓包、處理和轉(zhuǎn)發(fā)流程中都會存在資源浪費(fèi)的問題。目前來看基于網(wǎng)卡抓包的方案應(yīng)該沒法很好地解決這個(gè)問題，我們也在嘗試探索一些其他的流量采集的方案，比如探索用 ebpf 進(jìn)行進(jìn)程級別的流量采集。

4.2 引流回放系統(tǒng)的重新定義

現(xiàn)階段我們的引流回放系統(tǒng)只會根據(jù)用戶的配置被動進(jìn)行流量采集，而為了及時(shí)拿到流量進(jìn)行測試，用戶一般都會選擇實(shí)時(shí)引流進(jìn)行測試。而實(shí)際上并不是所有的場景都一定需要實(shí)時(shí)的流量進(jìn)行測試，我們在規(guī)劃逐步將引流回放系統(tǒng)從一個(gè)按照用戶要求進(jìn)行流量轉(zhuǎn)發(fā)回放的工具，轉(zhuǎn)變?yōu)橐粋€(gè)線上復(fù)制流量的取用的平臺。

在流量存儲能力的基礎(chǔ)上，對于有測試需求的服務(wù)，平臺主動錯(cuò)峰、定時(shí)發(fā)起流量錄制任務(wù)，從而維護(hù)一個(gè)不斷更新的流量池，用戶需要流量時(shí)直接從流量池中取用，這樣一來，既可以盡量避免引流操作對和線上業(yè)務(wù)搶占計(jì)算資源，也可以使得流量的可用性更高。

4.3 特定場景下的流量存儲優(yōu)化

隨著基于流量錄制回放的上層應(yīng)用的完善，為了更多的業(yè)務(wù)方便接入試用，我們正在考慮朝著常態(tài)化的引流去演進(jìn)。這個(gè)勢必對我們的流量存儲帶來新的挑戰(zhàn)，無論是的數(shù)據(jù)規(guī)模，存儲形態(tài)以及查詢性能。我們希望可以基于現(xiàn)有架構(gòu)的存儲系統(tǒng)，構(gòu)建流量存儲的解決方案，支持海量數(shù)據(jù)吞吐的同時(shí)，能夠支持點(diǎn)查(基于 TraceId )，和 time-range scan 等多種復(fù)雜的高性能查詢方式。另外我們也在積極和安全團(tuán)隊(duì)合作，確保相關(guān)核心流量數(shù)據(jù)在存儲時(shí)候能夠?qū)崿F(xiàn)脫敏，同時(shí)不斷強(qiáng)化對于流量存儲使用的安全審計(jì)。

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ù)團(tuán)隊(duì)更好地去構(gòu)建各種有趣的產(chǎn)品。

字節(jié)跳動基礎(chǔ)架構(gòu)團(tuán)隊(duì)

字節(jié)跳動基礎(chǔ)架構(gòu)團(tuán)隊(duì)是支撐字節(jié)跳動旗下包括抖音、今日頭條、西瓜視頻、火山小視頻在內(nèi)的多款億級規(guī)模用戶產(chǎn)品平穩(wěn)運(yùn)行的重要團(tuán)隊(duì)，為字節(jié)跳動及旗下業(yè)務(wù)的快速穩(wěn)定發(fā)展提供了保證和推動力。

公司內(nèi)，基礎(chǔ)架構(gòu)團(tuán)隊(duì)主要負(fù)責(zé)字節(jié)跳動私有云建設(shè)，管理數(shù)以萬計(jì)服務(wù)器規(guī)模的集群，負(fù)責(zé)數(shù)萬臺計(jì)算/存儲混合部署和在線/離線混合部署，支持若干 EB 海量數(shù)據(jù)的穩(wěn)定存儲。

文化上，團(tuán)隊(duì)積極擁抱開源和創(chuàng)新的軟硬件架構(gòu)。我們長期招聘基礎(chǔ)架構(gòu)方向的同學(xué)，具體可參見 job.bytedance.com （文末“閱讀原文”），感興趣可以聯(lián)系郵箱 [email protected] 。