百度搜索展现服务重构：进步与优化

点击蓝字，关注我们

百度搜索展现服务的主要职责是请求检索系统获取结果，并依次进行模板选择、实时摘要补充、数据适配和结果渲染，将检索结果能以丰富多样的形式精准地展示给用户。在初期，这项服务基于C语言进行开发，迭代效率不尽人意。随着产品的迅速迭代和业务的不断拓展，研发效率问题逐渐凸显，为了解决这一瓶颈，搜索展现服务进化为由PHP开发、HHVM运行的服务。目前，搜索展现服务由数十个产品线、上百个研发RD共同参与研发，承载了数百个精细化的业务展现策略。然而，随着搜索业务的日益复杂化和生成式大模型的崛起，搜索展现服务也开始面临研发难度增大、架构能力不足和复用性低等多重挑战。具体表现如下：

2.1.1 核心思路：

△搜索展现层架构图

2.1.2 基础设施

GDP(Go Develop Platform)：百度内部基于go实现的业务开发平台，具备完善的RPC Server和RPC Client能力，主要用于API、Web以及后端服务开发。

ExGraph: 百度搜索展现团队自研图执行引擎。

Datahold：百度搜索展现团队自研数据管理器，主要解决模块数据（比如配置、字典）依赖和加载问题。具备如下能力：

公共lib：此外基础设施层还提供了udai（远程数据统一访问cgo扩展）、百度自有签名等等展现团队公共lib，公共Lib建设有统一准入标准，避免重复造轮子，提升研发效率。

2.1.3 公共算子

将搜索展现通用逻辑抽象为接口，基于图引擎提供公共算子，实现一处开发，通用搜索、垂类搜索等多个应用共同使用。目前已经实现抽样、适配、降级、限流、检索请求、落地页点出、渲染等数十个公共算子，开箱即用，快速支持搜索新展现应用搭建。

2.1.4 应用层

通过公共算子、各服务自有展现算子搭建执行图，实现应用业务逻辑。当前搜索展现服务包含通用搜索展现服务、垂类搜索展现服务、生成式搜索展现服务等。

通用搜索相比垂类搜索等业务更具复杂性，本章节将以通用搜索展现服务为例，具体介绍其重构迁移go的落地方案。

△通用搜索展现服务重构前后对比图

在重构迁移过程中我们主要面临两个难点：

对于难点1，主要通过架构业务解耦、平滑迁移机制这两个手段解决；对于难点2将从研发、测试、上线全流程稳定性保障。接下来将详细介绍这两个部分内容。

2.2.1业务解耦&平滑迁移

保障迁移和现有业务迭代效率，并协同多产品线进行业务展现策略迁移核心手段：解耦架构和业务展现逻辑，架构迁移部分先行迁移go，业务展现策略依旧基于php运行，架构逻辑迁移过程中不阻塞业务迭代，尽量避免php&go两个版本同时开发相同的业务逻辑。设计一套机制支持业务展现策略按业务线独立迁移到基于go的搜索展现服务上，并将整个复杂迁移过程拆分成四个阶段有序进行，最终实现整体项目目标。

第一阶段：架构部分图化迁移go+展现策略服务化

将限流、参数处理、检索请求、广告检索请求、http-header渲染等架构逻辑代码基于GDP+Exgraph图化迁移go，基于go的通用搜索展现服务完成检索数据统一处理之后，再请求基于php的展现策略服务进行业务展现逻辑。这样即可以保证迭代相对不频繁的架构逻辑先行迁移go，为后续展现策略迁移做好基础，同时也能保证迭代频繁的展现策略依旧可以按原有研发模式继续迭代。

第二阶段：异步摘要请求全量迁移

首先回答下异步摘要是什么。

检索系统往往为了考虑计算资源和响应速度，会在各个子系统内部设置cache，cache失效时间至少都是分钟级别，部分场景甚至达到天级别。对于部分需要秒级别就能更新的展现元素，比如搜索结果里需要展现视频播放量、文章点赞数量，以及用户是否对这条结果进行点赞等，cache就没有那么友好了。异步摘要因此诞生，检索请求返回之后基于检索结果请求高时效摘要服务，摘要请求是异步完成的，和普通展现策略并发，既实现了实时摘要补充，又避免了用户响应速度的退化。

为了避免随着展现策略逐渐迁移go，异步摘要请求时间可并行时间缩短，引入旁路系统。异步摘要策略数十个，本身迭代相对普通展现策略较不频繁，请求整体一起迁移go，异步摘要请求成功写入旁路系统，执行完所有普通展现策略（无论是迁移到go执行，还是保留在php上执行），基于PHP的策略服务通过旁路系统获取所有异步摘要并执行实时摘要补充。引入旁路系统本身也需要通信开销，通过以下手段降低：

第三阶段：展现策略迁移

协同各个产线线完成展现策略组1、展现策略组2、展现策略组3迁移到基于go的搜索展现服务。该阶段支持产品线按策略粒度、按业务小流量迁移；同时新展现策略（不包括异步摘要策略）可以直接基于go的搜索展现服务开发。

迁移准则：按展现策略有无依赖分类迁移。依赖常见场景：策略执行依赖其他非本业务的展现策略先执行，这种场景必须被依赖策略先迁移；策略内部依赖了架构能力，但这部分能力没有迁移go等。

迁移优先级：

第四阶段：全量迁移

整体完成异步摘要策略迁移、渲染、后置任务迁移。

该部分逻辑迭代也相对不频繁，为什么不提前迁移go?

主要限制因素是响应速度。如果将基于php展现策略服务发回给基于go的展现服务，再进行渲染、后置任务，php->go会再增加一次序列化、反序列化以及通信时间，会造成速度退化，这部分速度退化迁移go之后无法带来速度优化弥补抵消。

2.2.2 全流程稳定性保障

通用搜索展现服务重构项目的用户效果、商业收入和服务稳定性主要通过全流程稳定性保障。全流程稳定性主要包含研发、测试、上线稳定性保障。

研发保障

迁移过程不仅仅是简单功能平迁，通用搜索展现服务已经迭代了数十年，本身存在诸多不合理设计，如数据冗余、历史飞线逻辑较多、代码复用低等，我们基于以上问题进行数据治理、飞线包袱清理、重新抽象设计公共算子等。这些对研发质量提出了更高的要求，一方面通过单元测试和自动化流水线测试（数据diff&UI-DIFF，测试保障介绍）保障代码质量，另一方面通过日志打点分析对历史包袱进行提前下线避免不合理、不必要的迁移。

测试保障

功能测试：

稳定性测试：通过引流线上流量进行长时间压力测试，模拟线上运行环境，保障服务线上稳定性。

性能测试：通过性能火焰图发现系统性能热点并优化点；通用线上实例峰值qps进行性能测试以及极限压测获取服务极限qps，提前预估线上资源容量是否充足，响应数据是否存在退化。

上线保障

上线阶段稳定性保障主要手段包括：上线前资源/响应时间预估等进行稳定性评审、监控&报警、降级、内测、全网小流量等。

本文介绍了搜索展现服务发展过程以及当前面临主要挑战：研发难度高、架构能力不足、可复用性低，然后提出基于图执行引擎+公共算子+重构迁移go方式解决上述问题，最后基于通用搜索展现服务详细阐述了方案的落地。本文旨在通过将搜索展现服务重构思考分享给大家，期望大家有所借鉴和收获，当然也可能存在不足之处，也期望大家留言共同探讨。