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）的搜索链路性能飞跃，为用户带来更快、更流畅的搜索体验。