嘉賓 | 張宇、段熊春、宋牧春、謝永吉、鄧良

作者 | 凌敏

隨著網際網路的快速更迭，許多明星產品在時代的光環下熠熠生輝；但在喧鬧的背後，有這樣的一個群體，默默的守護著網際網路世界的平穩，今天我們就來介紹這樣一群幕後守護者。

2012 - 2022，是字節跳動產品線快速延伸的十年，也是基礎設施規模快速增長的十年。在這背後，有這樣一支團隊默默為字節上層業務的穩定保駕護航，他們就是字節系統部 STE 團隊。

早在 2015 年，STE 團隊就初具雛形，當時主要是問題驅動，為字節內部基礎設施及軟體系統提供技術支持。隨著 2017 年抖音等熱門產品用戶量級大爆發、成為現象級 APP，字節內部的伺服器規模愈發龐大，對系統的維護工作也成為重中之重。

2018 年，團隊被正式命名為 STE（全稱：System Technologies & Engineering，系統技術與工程）。如今，STE 團隊已從最初的 20 人擴大至數百人規模，在英國、美國等多地設有研發中心。技術維度也從作業系統內核擴展到伺服器固件、編譯器技術、系統虛擬化、主機網絡、系統智能運維等基礎技術，並將基礎軟體工程能力賦能業務。

在本期訪談中，InfoQ 有幸採訪到了 STE 內核方向的多位核心成員，了解他們在 Linux 內核優化上的技術實踐與經驗，以及這些工作為業務帶來的價值，同時一窺這支專注於底層基礎設施建設、在「看不見的地方」用技術構築城牆的團隊的精神和文化。

專注 Linux 內核的 90 後團隊

據了解，STE 內核團隊是字節系統部面向公司內部所有業務提供 Linux 內核服務的團隊，主要負責內核管理、進程調度、虛擬化和網絡等幾個方面的工作。據 STE 內核團隊負責人段熊春介紹，在 2015 年 STE 團隊初具雛形的時候，就有研發人員負責內核相關的工作。2018 年，STE 團隊正式成立，內核方向也作為其下屬團隊之一，逐步擴建成有專職研發人員負責解決 Linux 內核存在的問題，並增加和維護新特性。

我們注意到，這是一支非常年輕的團隊，內核維護者以 90 後居多，這其實並不常見。畢竟 「Linux 之父」Linus Torvalds 曾感慨，「目前的維護者多是 50、60 後，社區面臨代際更新問題。」Linus Torvalds 甚至擔心，在他們這批 Linux 內核維護者老去之後，很難再找到新的繼任者，因為很多年輕開發者認為「Linux 內核項目並不那麼有趣」。

STE 團隊的負責人張宇深耕於系統技術領域多年，對此他也表示，「現在專注在底層基礎軟體、作業系統內核上的人才越來越匱乏，甚至出現了兩種極端：一種是開發者的計算機基礎非常紮實，底子好，但對內核研發並不感興趣；一種是對內核非常感興趣，但底子薄，需要補功課。同時具備這兩方面優勢的人才非常少。對於我們內核團隊而言，年輕是我們的優勢，正是這種對內核技術的痴迷和熱愛，才讓我們走到了一起。」

向團隊中注入新鮮的血液並不難，難的是如何讓這些年輕人在 Linux 內核方向愈戰愈勇、愈走愈遠。對此，張宇提到了兩個字：激發。給年輕人平台，激發其興趣；給年輕人機會，激發其鬥志。「我們也有很多資深的開發者，但他們更傾向於把好的機會留給年輕人。這種『傳幫帶』的傳統，能夠讓年輕開發者有機會站到台前，越做越有信心。否則，如果年輕人持續得不到鼓勵、不被激發，在這條艱辛的道路上就很難做出成績、走得長遠。」張宇提到。

正是在這種文化氛圍的薰陶下，STE 內核團隊依託於 Linux 內核，在虛擬化、雲原生、eBPF 等技術方向都有非常硬核的輸出。比如，2020 年 9 月，團隊向 Linux 內核社區貢獻了 HVO 方案，該方案能夠解決 Linux 內核內存管理冗餘這一難題。

困擾業內數十年的 Linux 內核內存管理冗餘，有了解法

從 Linus Torvalds 在 1991 年發布第一版開始，Linux 內核迄今已發展了 30 餘年。據稱，第一版的 Linux 內核只有 10250 行代碼，占用 65 KB，而如今，Linux 內核代碼行數早已超過 2700 萬。

Linux 內核每年新增 / 刪除的代碼多達百萬行，也加入了越來越多優秀的特性。這樣一個複雜且臃腫的工程，在不同的業務場景下，勢必會面臨各式各樣的挑戰。

支撐字節全量伺服器運轉的正是 Linux 作業系統。STE 內核團隊發現，一些雲計算的場景會帶來額外的內存管理開銷，隨著伺服器規模越來越大，這種損耗也會成倍放大。

「Linux 內核以頁（一般 4 KB）為單位管理物理內存。每個 4 KB 頁對應一個 struct page 結構體。使用一個 struct page 管理一個頁，這本身沒什麼問題。但是當使用的頁的大小是 2 MB 甚至 1 GB 時，Linux 依然以 4 KB 為單位分配 struct page，這顯然是個內存浪費的行為。我的目的就是儘可能減少這部分冗餘的內存管理開銷。」說這話的是 STE 工程師宋牧春。2019 年 7 月，宋牧春加入字節 STE 內核團隊，三年時間，宋牧春隨團隊一同成長，也完成了從 Linux 內核開發者到 Linux 內核維護者的轉變，並成為 Linux 內核社區 HugeTLB 和 Memory Cgroup 兩個核心子模塊的 maintainer。

實際上，Linux 內核內存管理冗餘並不是一個新問題，它在業內已存在十年之久。過去不少公司都做過研究，但始終沒有找到解法。即便如此，STE 內核團隊依然想做一些嘗試。在不斷地討論、驗證各種方案的可行性後，團隊發現這個問題是有可能被解決的。

「某些場景會使用到大頁，每個大頁需要 8 個頁的 struct page 去管理，即 8X4K 的內存，我們希望最終只占用一個頁的物理內存（4KB）。對此，我們想的方案是復用，把後面 7 個虛擬地址映射到唯一的物理頁，如果方案能成功落地，則意味著 1T 的伺服器，最大能節省接近 16GB 的內存。即使優化 1%，整體給公司帶來的收益也會非常大。」宋牧春說道。

這套方案被稱作 HVO (HugeTLB Vmemmap Optimization)。方案有了，下一步就是做代碼調研。

Linux 內核管理是非常複雜且核心的一個模塊，它和各個模塊交織在一起，它的穩定性也必然會影響整個 Linux 內核的穩定性。因此，STE 內核團隊需要儘可能地減少該方案代碼涉及的範圍，並確保不會影響系統里的其他功能。為此，從 2020 年 4 月到 2021 年 6 月，團隊開始了長達一年時間的代碼調研、開發、測試和重構。

用一年的時間，解決一個技術難題，值得嗎？段熊春給出了肯定的回答。

「我們會衡量這件事情的價值，顯然我們也面臨著很多壓力，但真正難的事情是需要投入更多時間去看的，我們也需要這樣做。基於對技術的狂熱，我們周末也經常聚在一起討論和思考，再把這些想法帶到實際場景中，更好的打磨和優化。這是一個長期的過程，而這些突破也能為公司和業界帶來巨大的收入，這就是有價值的。」

同時，HVO 也得到了業界的廣泛認可：華為、Google、AWS、甲骨文都準備將這個方案投入使用，還有公司向團隊發來感謝信。「但這不是終點，我們會持續優化 HVO 方案。」段熊春說道。

Linux 內核雲原生技術新探索

設備虛擬化技術作為雲計算領域最重要的基礎技術之一，多年來一直在穩步向前演進。其中，virtio 和 VFIO 在過去一直是最主流的設備虛擬化技術，並分別於 2008 年、2012 年被合入 Linux 內核主線。為了將 virtio 和 VFIO 的優勢結合，2020 年，vDPA（Virtio Data Path Acceleration）技術框架被合入 Linux 內核主線。

與此同時，字節內部的雲原生化進程也在進行著。

據了解，字節最早於 2016 年開始在內部推進雲原生化進程，對業務進行大規模容器化改造。到 2021 年年末，字節已經有超過 95% 的應用實現了雲原生化。在這個過程中，STE 內核團隊發現，容器在一些 I/O 相關的解決方案中，與傳統的虛擬化方案相比比較受限。「我們當時希望能夠在 Linux 內核中提供一套框架，開發者可以基於這個框架去模擬各種各樣的設備，並且能夠直接供容器接入使用。這樣，就進一步彌補了基於容器的雲原生方案在 I/O 方面的短板，甚至還能夠和相對成熟的虛擬化方案實現一定程度上的技術復用。」STE 工程師謝永吉對 InfoQ 說道。

於是，VDUSE 框架應運而生。通過 VDUSE，開發者可以在一個用戶進程中實現一個軟體定義的 vDPA 設備，並可以通過 vDPA 框架接入 virtio 或者 vhost 子系統，供容器或者虛機使用。

根據介紹，具體的實現原理上，VDUSE 設備是由 /dev/vduse/control 的 ioctl(VDUSE_CREATE_DEV) 創建的，通過這個 ioctl，用戶空間可以為這個模擬設備指定一些基本配置，如設備名稱（唯一標識 VDUSE 設備）、virtio 特性、virtio 配置空間、virtqueues 數量等等。然後，一個字符設備接口（/dev/vduse/$NAME）會被導出到用戶空間用於設備模擬。用戶空間可以在 /dev/vduse/$NAME 上使用 VDUSE_VQ_SETUP ioctl 來初始化每個 virtqueue 的配置，如 virtqueue 的最大長度等。

在初始化之後，VDUSE 設備可以通過 VDPA_CMD_DEV_NEW 這條 netlink 消息綁定到 vDPA 總線。之後，用戶空間可以在 /dev/vduse/$NAME 上通過 read()/write() 來接收並回復來自 VDUSE 內核模塊的一些控制請求，同時還可以通過 mmap() 映射一段共享內存，與內核相應的 virtio 驅動進行數據通信。

2020 年 10 月，STE 內核團隊向 Linux 內核社區正式開源 VDUSE。經過一年時間，VDUSE 在 Linux 5.15 版本被正式合入。

「在計算存儲分離的架構下，我們可以在計算節點通過 VDUSE 框架模擬各類存儲設備供容器或虛機使用，這類存儲設備的後端往往是遠端的存儲節點。現在，這套解決方案在字節的雲原生場景已經開始大規模部署。後續，我們也將繼續探索在雲原生高性能網絡場景上的應用可行性。」謝永吉說道。

Linux 內核始終在向前演進，在 STE 工程師鄧良看來，「隨著雲原生應用場景不斷擴大、硬體朝著高密度應用異構的機型上發展，對 Linux 內核提出了新的要求。內核是連接底層硬體和上層雲原生應用的一個橋樑，我們也在思考，當前這種單一的宏內核是否合適，並且我們也在做一些探索。」

擁抱社區，讓技術產出更大的收益和價值

如果說攻克技術難關靠的是技術硬實力，那麼向社區推廣並使其合入我們的代碼，則要依靠足夠多的耐心去溝通和布道。

在與社區溝通上，STE 內核團隊也積累了自己的經驗。

2020 年 9 月，當 HVO 第一個版本發到社區後，團隊收到很多質疑的聲音。「社區起初對我們的方案產生懷疑，我們需要先向社區證明這個方案沒有問題。同時，社區也會提出一些針對性的問題，甚至有很多都是我們之前沒有考慮過的場景。根據這些問題，我們再對方案進行疊代和維護。像 HVO，我們疊代了 20 多個版本，需要不斷地向社區證明這個方案在不同場景的有效性，這個過程持續了很長的時間。」回憶 HVO 的社區之路，宋牧春覺得特別漫長。在他看來，社區需要考慮維護成本是否大於收益，這無可厚非，作為開發者和社區貢獻者，要做的就是解釋清楚技術方案能夠產生的價值，讓社區看到它帶來的收益，並證明這個方案的可行性和穩定性。

在企業內部，一套技術方案從開發到應用，這個鏈路並不複雜。但面向社區，開發人員需要考慮的問題就會更多。「很多時候，我們要突破自有場景，去看社區裡的其他場景和痛點，而這些很可能是我們從來沒有遇到過的。」顯然，擁抱社區的溝通成本會很高，但在段熊春看來，為社區貢獻代碼能夠實現雙贏，這都是值得的。

「現在我們的工作環境基本是模擬社區環境，工作模式也跟社區保持一致。這種標準化的作業模式能有效降低代碼的維護成本，同時社區思維的開闊性，也為我們思考問題提供了更多的思路，進而為技術創造價值提供了更多的可能性。」

走進「無人區」

對於 STE 內核團隊的願景和目標，張宇用了三個「貼近」來描述：貼近業務，去了解業務的痛點；貼近社區，去了解社區的方向；貼近新硬體技術，在軟硬協同設計上發揮內核更大價值。內核本身無法直接創造價值，更多是通過服務業務來創造價值。所以團隊在做研發時，一定要想清楚對業務的收益是什麼，它能否真正的解決業務痛點，進而創造業務價值。

STE 內核團隊多年來一直深入社區。基於開源 Linux 作業系統，團隊做了一些優化以滿足企業內部的需求，反之，團隊也會把這些好的特性回饋給社區，像前文提到的 HVO 和 VDUSE 都已被合入 Linux 內核主線。在張宇看來，STE 內核團隊並不是要做一個標新立異的作業系統，更多的是源自技術初心，希望能夠把自身的力量貢獻給社區，交給 Linux，再不斷引進。

張宇表示，STE 團隊非常重視「務實」，這也是字節的核心價值觀之一。「我們在做的事情都是圍繞基礎設施展開的，提高它的穩定性、優化性能等等，與公司內其他能直接創造收益的明星產品相比，我們是一個做減法的部門，通過技術手段降低基礎設施成本，在業務鏈路里屬於非常靠後的位置，就像足球場上的後衛一樣，要能守住系統穩定性 / 可靠性的基本盤不出問題，又要能夠往前場助攻進球。回到團隊的願景來看，我的想法比較簡單務實，希望團隊先滿足業務的需求，再高於業務需求、先於業務需求，做一些引領業界的技術。就像一開始，我們是跟著社區，跟著業界領先者的路徑去走，但隨著我們技術能力不斷提升以滿足業務場景多樣性的需求，再往前走，必將進入『無人區』。」

進入「無人區」後，沒有方向的指引，也沒有參照物，這才是最考驗團隊能力和韌性的時候。「我希望團隊有開拓精神，辨識出合理的方向並堅定的走下去，也許在過程中會有微調，但最後頂多畫出來的路線是波浪線，而不是一條完全沒有目標的曲線。」張宇說道。

寫在最後

直到今天，團隊對 HVO 的優化還在繼續。2022 年 3 月，團隊優化了 HVO 在 2 MB HugeTLB 的表現，與此前相比，它進一步將 2 MB HugeTLB 的 struct page 開銷減少了 12.5%；2022 年 4 月，HVO 支持 ARM 64 架構；2022 年 5 月，HVO 支持運行時開關，不再束縛於 cmdline 的方式使能。

依託 Linux 內核，團隊在虛擬化、雲原生、eBPF 等技術方向上也在繼續探索著。

「現在我們關注的比較多的場景，一個是雲原生，這也是大家都在關注的方向，但當前並沒有一個特別好的解決方案，甚至在雲遊戲的一些基礎設施場景下，業界還沒有形成一個標準；另一個就是軟硬協同，用軟體的方式定義硬體，用硬體的方式來定義軟體。目前我們也圍繞這些方向在做一些研究。」張宇認為，「如果團隊一直在做一些重複的事情，是沒有激情與戰鬥力的，對團隊的期待還是要在滿足業務需求之上，去做一些引領業界的事情。」

在張宇看來，做作業系統這類基礎軟體不是一時熱情，是需要長期投入的。大浪淘沙沙去盡，沙盡之時見真金。「目前國內外大廠也都在圍繞自己的業務場景做軟硬一體的事情，涉及基礎系統軟體、晶片板卡伺服器之類的硬體研發。在做的同時也要上升到社會責任感的層面上來看，能貢獻多少力量。這些都是需要持續思考的。」

嘉賓介紹：

張宇，字節跳動 STE 團隊負責人

段熊春，字節跳動 STE 內核團隊負責人

宋牧春，字節跳動 STE 工程師、Linux 內核社區 HugeTLB 和 Memory Cgroup 兩個核心子模塊的 maintainer

謝永吉，字節跳動 STE 工程師

鄧良，字節跳動 STE 工程師