CloudWeGo 作為字節跳動開源的高性能微服務框架體系，核心組件 Kitex 中的流式架構設計，能夠適配複雜業務的多次請求、分段返回需求，為億級流量產品的鏈路優化提供了堅實基礎。在抖音這樣億級用户的產品中，是如何落地實踐並取得實效的呢？
本文基於抖音搜索服務端架構研發工程師馬永真在 CloudWeGo 四週年技術沙龍演講內容整理，闡述抖音搜索核心鏈路如何藉助 Kitex 流式能力進行技術改造，突破性能優化瓶頸，實現首屏體驗與業務指標的雙重提升。
一、性能優化：業務背景、痛點與現有探索
1. 搜索性能對業務的關鍵影響
在抖音，搜索是連接內容、用户與信息的關鍵橋樑，其性能表現與核心業務指標緊密相連。行業研究表明，毫秒級的延遲都可能導致用户流失------例如，谷歌的數據顯示，搜索速度每慢 400 毫秒，用户流失率便會增加 0.6%。抖音內部的性能劣化實驗也同樣證實，搜索性能的波動與用户的點擊行為、搜索興趣乃至商業指標之間存在強相關性。
2. 抖音搜索核心架構拆解
抖音搜索的後端架構主要由兩大核心模塊構成：
- 引擎檢索：作為接收用户請求的入口，這一層負責從海量的視頻、用户等異構內容中召回初步相關的數據。隨後召回的數百條初步結果，會在這裏經過複雜的排序與篩選模型，精選出最匹配的十條結果。
- 結果打包：這一層中系統會根據不同內容的特性，差異化地獲取下游數據，並將其打包成適合客户端渲染的格式，最終通過 API 層呈現給用户。
3. 搜索業務的優化難點解析
與推薦流等場景相比，搜索業務的性能優化面臨着特殊瓶頸：
- 難以預取：推薦場景可以在用户瀏覽當前內容時，提前加載後續內容，而搜索行為具有瞬時性，無法進行有效的預取。搜索服務端架構團隊曾嘗試預取優化，但緩存命中率僅有約 10%，效果有限。
- 用户行為的複雜性：搜索過程中，用户可能隨時取消請求，這種不確定性與交互過程中的天然延遲，進一步加大了優化的難度。
- 傳統手段效果有限：在引擎檢索層直接增加緩存的方案，雖然能提升速度，但卻面臨數據時效性的挑戰，可能因返回過時結果而損害用户體驗，得不償失。
4. 抖音搜索的業務特點與優化方向
和傳統搜索相比，抖音搜索有明顯的獨特性：早期百度、今日頭條 PC 端等 WEB 搜索通常展示十條結果，今日頭條 APP等諮詢類 APP會展示三條左右結果，而抖音搜索以視頻內容為主，單條結果的高度很高，用户首屏基本只能看到一條完整結果，下一條僅露出一點點。基於這個特點，搜索服務端架構團隊把優化核心從"優化用户獲取第一刷十條結果的速度"，調整為"優先優化用户首屏結果的呈現速度"。
5. 早期性能優化手段實踐
圍繞"加速首屏"這一核心目標，抖音搜索服務端架構團隊進行了一系列早期的技術探索：
- 首屏結果拆分： 用户發起搜索請求後，API 層接收引擎返回的結果，先計算鋪滿首屏需要 1-2 條數據，然後把打包請求拆成兩次 ------ 第一次優先打包首屏數據並返回給 API 層，端上先展現首屏內容，剩餘數據後續再返回，用户感知不到後續數據的加載，只覺得首屏數據很快拿到。
- 首屏預測優化： 為了進一步縮短延遲，搜索服務端架構團隊引入了預測機制。當用户請求到達 API 層時，系統會並行發起兩次請求：一次是常規的在線引擎檢索，另一次則是對緩存結果的召回。緩存數據同樣會被拆分為首屏和非首屏兩部分。然而，為了保證結果的準確性，客户端並不會立即展示緩存數據，而是等待在線檢索結果返回。API 層會比對兩者，若首屏內容一致，則向客户端發送"命中"信號，使其立即渲染首屏；若不一致，則放棄緩存，等待在線結果。這種"多次請求、多次返回"的交互模式，讓搜索服務端架構團隊在技術選型上傾向於採用 HTTP Chunked Transfer Encoding 流式返回數據，因為它既避免了獨立請求帶來的請求量翻倍問題，也規避了多次請求可能路由到不同實例的風險。
- 自建打包優化： 把搜索結果拆成兩部分：一部分是能夠快速獲取的靜態元數據，如視頻封面、標題文案、點贊評論數等，另一部分則是獲取相對耗時的動態視頻流數據。核心思路是先返回靜態元數據，讓用户迅速看到結果的框架，再加載視頻流以供播放。然而，在缺少原生 RPC 流式支持的背景下，搜索服務端架構團隊不得不採用一種變通方案：通過一次 RPC 調用觸發兩次獨立的打包操作，並將動態視頻流數據臨時緩存在服務實例的內存中。第二次打包時，通過硬編碼的 IP 地址去獲取緩存數據。這種設計雖然在當時解決了問題，但無疑增加了架構的複雜性，並引入了潛在的穩定性風險------該方案強依賴服務實例的內存緩存，在實例發生重啓或漂移時，存在數據丟失和獲取失敗的風險。
二、技術改造：基於 Kitex 流式架構的核心鏈路重構
1. 流式改造的核心動因與思路
早期的自建打包方案雖然解決了部分問題，但其固有的架構複雜度和穩定性風險，成為了搜索服務端架構團隊持續優化的障礙。隨着字節跳動內部微服務框架 Kitex 對流式能力的支持日趨成熟，團隊決定基於此進行一次徹底的鏈路重構。
核心思路十分明確：利用 Kitex 流式接口原生的 會話保持（Session Stickiness）能力 ，將原方案的多次打包與多次請求，優化為 一次打包、單次連接、流式返回 的全新模式，從根本上簡化架構，消除不穩定性。
2. 流式架構與傳統架構的對比優勢
改造後的新舊架構對比如下，其優勢顯而易見：
- 架構更精簡：API 層與 Loader 服務之間不再需要為獲取緩存數據而發起二次請求，交互流程大幅簡化。
- 穩定性顯著提升：請求量的減少直接降低了 Loader 服務的常駐內存佔用。更重要的是，流式長連接確保了會話的穩定性，徹底解決了在服務發佈或實例銷燬時，因內存數據丟失而導致的二次打包失敗問題。
- 服務成功率顯著提升：由於流式連接在會話期間會保持實例存活，老方案中"第二次打包數據獲取失敗"這一高頻痛點被徹底根除，打包成功率得到大幅優化。
3. 開發體驗與問題排查
Kitex 流式能力不僅帶來了架構上的收益，在開發和運維層面也提供了極大的便利。例如，框架提供的日誌可以一鍵生成流式連接的全生命週期觀測圖，清晰地展示了服務何時發包、何時收包、何時斷開，以及各環節的耗時分佈，極大地提升了問題排查的效率。
在改造初期，搜索服務端架構團隊曾遇到部分場景下無法收到第二次回包的問題。通過細緻排查，最終定位為業務邏輯實現的一個 Bug------在數據尚未完全發送時，請求便意外斷開。整個定位過程中因為框架繼承了高效的trace能力很快就能對排查方向進行判斷並且快速修復。
4. 流式與非流式協議的性能對比
在真實業務場景中做了詳細對比測試：
- CPU 佔用： 無論是客户端還是服務端，流式協議帶來的額外 CPU 消耗與非流式場景基本持平，並未引入新的性能負擔。
- RPC 耗時： 通過 AB 實驗驗證，流式接口的 P99 耗時劣化不超過 3 毫秒，完全在可接受的範圍內。
- 業務收益： 首屏加載速度 獲得了顯著提升，在熱點卡、活動卡等關鍵場景， 平均提升 14% 以上 。更重要的是，核心業務指標也獲得了顯著的正向收益，例如搜索總點擊率、熱點卡點擊 UV 等關鍵指標均有明顯增長。
5. 基於流式的場景化業務優化
在完成基礎鏈路的流式改造後，搜索服務端架構團隊還針對一些特殊業務場景進行了深度優化。例如，在"抗戰勝利80週年閲兵"這類重大活動期間，用户搜索相關關鍵詞時，返回的單條結果卡片可能鋪滿四倍於常規的屏幕高度。在這種情況下，僅僅打包首屏所需的一兩個常規組件是遠遠不夠的。
搜索服務端架構團隊與熱點打包服務團隊協作，進一步優化了處理流程：API 層請求 Loader 服務後，Loader 會首先動態計算鋪滿當前首屏所需的全部組件數量，然後優先返回這部分"首屏"數據，剩餘數據則在後台流式返回。這一優化在普通場景下能帶來平均 14% 的首屏加速，而在閲兵這類特殊場景下，首屏加速效果可高達 50%——其核心在於，渲染耗時完全取決於首屏所需組件的打包速度，無需再等待全量數據的返回。
三、未來展望：搜索理想架構的流式演進
目前，搜索服務端架構團隊已經成功完成了搜索打包鏈路的全面流式化，但優化的腳步並未就此停止。放眼整個搜索鏈路，引擎檢索層作為耗時佔比最大的環節，其流式改造將是團隊未來的核心攻堅方向。
搜索業務的個性化特徵極其顯著，這意味着最終結果的呈現，高度依賴於複雜的個性化計算。然而，搜索服務端架構團隊也觀察到，部分結果形態（如熱點卡、活動卡等特型卡片）的確定，並不需要等待全量計算完成，其所需的數據往往能夠被快速生成。這類本質上的結構化數據，為團隊進一步優化提供了可能。
未來期待將流式改造繼續向上游的引擎層延伸。搜索服務端架構團隊計劃將 API 層到引擎層，乃至引擎內部的召回與排序鏈路，都納入流式優化的範疇。在理想的模式下，當引擎在進行復雜的個性化檢索時，可以優先返回能夠快速生成的結構化數據（如特型卡），隨後再以流式的方式，返回需要複雜計算的個性化內容。
這種模式不僅能將引擎層的耗時進行有效拆分，更能讓下游的打包環節第一時間接收到首屏所需的數據並進行處理，最終實現端到端（End-to-End）的搜索鏈路性能飛躍，為用户帶來更快、更流暢的搜索體驗。
