本文将简单介绍搜索展现服务发展过程，以及当前其面临的三大挑战：研发难度高、架构能力欠缺、可复用性低，最后提出核心解决思路和具体落地方案，期望大家能有所收货和借鉴。

　　01 背景

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

　　【研发难度高】：搜索展现服务基于过程管理，逻辑复杂，多个策略框架分布于代码的各个阶段，不能满足多业务对于简化管理、易于扩展的效率诉求

　　【架构能力欠缺】：hhvm基础设施已经停止维护，对于异步/多线程等功能的支持较为有限，流式能力的缺失使其无法满足生成式搜索等需求，因而不能满足服务稳定性和新产品需求迭代的要求。

　　【可复用性低】：搜索展现层主要服务与通用搜索、垂类搜索等。目前，通用搜索和垂类搜索之间目前缺乏合理的架构设计，这导致相同的需求在通用搜索和垂类搜索中都需要进行重复的开发。

　　02 解决方案

　　2.1 整体设计

　　2.1.1 核心思路：

　　降低研发难度：根据展现层特点，通过设计实现图管理引擎，将展现功能以算子的粒度进行拆分，单个算子的逻辑简单清晰、业务方把工作聚焦在功能（算子）和需求，而非应用整体，同时将搜索展现服务的过程处理升级为DAG图处理，降低流程管理的复杂度。通过实现算子->图->需求的层次管理，推动搜索展现服务的过程研发模式从面向过程到面向功能、面向业务。

　　提升架构能力：从PHP+HHVM转型GO，基于百度内部GO开发框架搭建搜索展现服务，获得更好的性能和更高的并发处理能力。同时对于异步/协程/流式交互能力支持成本更低。

　　提升可复用性：通过抽象公共算子和实施基础Lib共建，提高代码的可复用性和可维护性。公共算子可以在多个搜索展现服务中复用，避免了重复开发和维护的代价。基础Lib可以提供通用的功能和工具类，方便开发人员快速开发和维护代码，减少重复开发和出错的可能性。　　

△搜索展现层架构图

　　2.1.2 基础设施

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

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

　　图：设计了一套简单的图描述语言，不借助任何工具，rd可轻松学习并据此了解模块执行逻辑的全貌，降低接手难度

　　算子：设计简单的接口，屏蔽实现细节，rd实现算子接口即可执行

　　执行：灵活设计了串行组、并行组、子图、条件算子、switch算子、中断、等待等机制，以适配复杂的业务流程

　　效率工具：实现了代码生成器、脚手架等效率工具，可快速创建应用

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

　　支持热加载，后台监听并解析变更文件后切换到前台使用；提供通用字典、配置解析器，同时支持自定义文件解析器

　　支持通过配置完成数据对象自动注册、加载和解析，有效管理大型服务中配置/字典不可丢、解析出错及时报警感知等

　　支持rd线下环境一键部署模块依赖远程数据，提升研发阶段环境部署效率

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

　　2.1.3 公共算子

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

　　2.1.4 应用层

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

　　2.2 详细设计

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

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

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

　　难点1：前文已提到通用搜索展现服务是一个数十个产品线100+RD共同研发的模块，展现策略组1&2&3共有600+业务展现策略，每天平均有4+策略迭代上线，在重构迁移落地过程中，首要解决的问题就是：如何兼容迁移和现有业务迭代效率？如何协同众多业务线迁移？

　　难点2：搜索展现服务业务逻辑非常复杂，重构项目如何保障用户效果、商业收入和服务稳定性。

　　对于难点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的策略服务通过旁路系统获取所有异步摘要并执行实时摘要补充。引入旁路系统本身也需要通信开销，通过以下手段降低：

　　通过边车化实现旁路服务降低远程通信开销

　　基于go展现服务不对异步摘要进行解析，将原始序列化结果写入到旁路系统，基于php服务获取数据进行解析。可以有效避免go/php展现重复反序列化数据带来开销。

　　第三阶段：展现策略迁移

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

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

　　迁移优先级：

　　（1）优先迁移无依赖的展现策略，可以独立迁移开发、实验、推全

　　（2）对于存在依赖的展现策略，协同被依赖方一起完成迁移

　　第四阶段：全量迁移

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

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

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

　　2.2.2 全流程稳定性保障

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

　　研发保障

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

　　测试保障

　　功能测试：

　　数据Diff：协同qa建设自动化数据diff功能，录制线上请求进行回放，将关键数据如检索请求、广告请求、输出给渲染服务的数据等等进行全面自动化例行数据diff，通过数据diff发现潜在问题，累计发现并消除上万数据diff。

　　UI-Diff: 搜索结果页结果类型众多，比如天气阿拉丁、股票阿拉丁等等，共有上千个资源类型，每种资源类型都有各个的展现模板。效果回归成本高且难度大，根据资源展现量大小作为优先级，利用ui-diff平台（html页面像素级diff）自动挖掘线上query进行基线和策略线自动化ui-diff，重点关注diff差异超过阈值的效果问题，通过这种方式累计发现并修复40+效果类问题。

　　端到端测试：数据diff&UI-diff这两个自动化测试手段已经能够覆盖绝大多数效果类场景，除此此外，QA对搜索重点场景比如落地页跳转、翻页、广告效果等人工效果测试回归。通过自动化测试+人工效果测试保障重构改造后的展现效果。

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

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

　　上线保障

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

　　03 总结

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