作者
瞭东
导读
本文将简单介绍搜索展现服务发展过程，以及当前其面临的三大挑战：研发难度高、架构能力欠缺、可复用性低，最后提出核心解决思路和具体落地方案，期望大家能有所收货和借鉴。
全文字，预计阅读时间12分钟。
01背景百度搜索展现服务的主要职责是请求检索系统获取结果，并依次进行模板选择、实时摘要补充、数据适配和结果渲染，将检索结果能以丰富多样的形式精准地展示给用户。在初期，这项服务基于C语言进行开发，迭代效率不尽人意。随着产品的迅速迭代和业务的不断拓展，研发效率问题逐渐凸显，为了解决这一瓶颈，搜索展现服务进化为由PHP开发、HHVM运行的服务。目前，搜索展现服务由数十个产品线、上百个研发RD共同参与研发，承载了数百个精细化的业务展现策略。然而，随着搜索业务的日益复杂化和生成式大模型的崛起，搜索展现服务也开始面临研发难度增大、架构能力不足和复用性低等多重挑战。具体表现如下：
：搜索展现服务基于过程管理，逻辑复杂，多个策略框架分布于代码的各个阶段，不能满足多业务对于简化管理、易于扩展的效率诉求
：hhvm基础设施已经停止维护，对于异步/多线程等功能的支持较为有限，流式能力的缺失使其无法满足生成式搜索等需求，因而不能满足服务稳定性和新产品需求迭代的要求。
：搜索展现层主要服务与通用搜索、垂类搜索等。目前，通用搜索和垂类搜索之间目前缺乏合理的架构设计，这导致相同的需求在通用搜索和垂类搜索中都需要进行重复的开发。
02解决方案2.1整体设计2.1.1核心思路降低研发难度：根据展现层特点，通过设计实现图管理引擎，将展现功能以算子的粒度进行拆分，单个算子的逻辑简单清晰、业务方把工作聚焦在功能（算子）和需求，而非应用整体，同时将搜索展现服务的过程处理升级为DAG图处理，降低流程管理的复杂度。通过实现算子-图-需求的层次管理，推动搜索展现服务的过程研发模式从面向过程到面向功能、面向业务。
提升架构能力：从PHP+HHVM转型GO，基于百度内部GO开发框架搭建搜索展现服务，获得更好的性能和更高的并发处理能力。同时对于异步/协程/流式交互能力支持成本更低。
提升可复用性：通过抽象公共算子和实施基础Lib共建，提高代码的可复用性和可维护性。公共算子可以在多个搜索展现服务中复用，避免了重复开发和维护的代价。基础Lib可以提供通用的功能和工具类，方便开发人员快速开发和维护代码，减少重复开发和出错的可能性。
△搜索展现层架构图
2.1.2基础设施GDP(GoDevelopPlatform)：百度内部基于go实现的业务开发平台，具备完善的RPCServer和RPCClient能力，主要用于API、Web以及后端服务开发。
ExGraph:百度搜索展现团队自研图执行引擎。
图：设计了一套简单的图描述语言，不借助任何工具，rd可轻松学习并据此了解模块执行逻辑的全貌，降低接手难度
算子：设计简单的接口，屏蔽实现细节，rd实现算子接口即可执行
执行：灵活设计了串行组、并行组、子图、条件算子、switch算子、中断、等待等机制，以适配复杂的业务流程
效率工具：实现了代码生成器、脚手架等效率工具，可快速创建应用
Datahold：百度搜索展现团队自研数据管理器，主要解决模块数据（比如配置、字典）依赖和加载问题。具备如下能力：
支持热加载，后台监听并解析变更文件后切换到前台使用；提供通用字典、配置解析器，同时支持自定义文件解析器
支持通过配置完成数据对象自动注册、加载和解析，有效管理大型服务中配置/字典不可丢、解析出错及时报警感知等
支持rd线下环境一键部署模块依赖远程数据，提升研发阶段环境部署效率
公共lib：此外基础设施层还提供了udai（远程数据统一访问cgo扩展）、百度自有签名等等展现团队公共lib，公共Lib建设有统一准入标准，避免重复造轮子，提升研发效率。
2.1.公共算子将搜索展现通用逻辑抽象为接口，基于图引擎提供公共算子，实现一处开发，通用搜索、垂类搜索等多个应用共同使用。目前已经实现抽样、适配、降级、限流、检索请求、落地页点出、渲染等数十个公共算子，开箱即用，快速支持搜索新展现应用搭建。
2.1.4应用层通过公共算子、各服务自有展现算子搭建执行图，实现应用业务逻辑。当前搜索展现服务包含通用搜索展现服务、垂类搜索展现服务、生成式搜索展现服务等。
2.2详细设计通用搜索相比垂类搜索等业务更具复杂性，本章节将以通用搜索展现服务为例，具体介绍其重构迁移go的落地方案。
△通用搜索展现服务重构前后对比图
在重构迁移过程中我们主要面临两个难点：
难点1：前文已提到通用搜索展现服务是一个数十个产品线+RD共同研发的模块，展现策略组12共有+业务展现策略，每天平均有4+策略迭代上线，在重构迁移落地过程中，首要解决的问题就是：如何兼容迁移和现有业务迭代效率？如何协同众多业务线迁移？
难点2：搜索展现服务业务逻辑非常复杂，重构项目如何保障用户效果、商业收入和服务稳定性。
对于难点1，主要通过架构业务解耦、平滑迁移机制这两个手段解决；对于难点2将从研发、测试、上线全流程稳定性保障。接下来将详细介绍这两个部分内容。
2.2.1业务解耦平滑迁移保障迁移和现有业务迭代效率，并协同多产品线进行业务展现策略迁移核心手段：解耦架构和业务展现逻辑，架构迁移部分先行迁移go，业务展现策略依旧基于php运行，架构逻辑迁移过程中不阻塞业务迭代，尽量避免phpgo两个版本同时开发相同的业务逻辑。设计一套机制支持业务展现策略按业务线独立迁移到基于go的搜索展现服务上，并将整个复杂迁移过程拆分成四个阶段有序进行，最终实现整体项目目标。
第一阶段：架构部分图化迁移go+展现策略服务化
将限流、参数处理、检索请求、广告检索请求、