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

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

作者 | 瞭东

导读

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

全文4736字预计阅读时间12分钟。

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为后续展现策略迁移做好基础同时也能保证迭代频繁的展现策略依旧可以按原有研发模式继续迭代。

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

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

检索系统往往为了考虑计算资源和响应速度会在各个子系统内部设置cachecache失效时间至少都是分钟级别部分场景甚至达到天级别。对于部分需要秒级别就能更新的展现元素比如搜索结果里需要展现视频播放量、文章点赞数量以及用户是否对这条结果进行点赞等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方式解决上述问题最后基于通用搜索展现服务详细阐述了方案的落地。本文旨在通过将搜索展现服务重构思考分享给大家期望大家有所借鉴和收获当然也可能存在不足之处也期望大家留言共同探讨。