导读

　　本文深入探讨百度视觉搜索在快速发展的业务及技术背景下，如何通过持续的技术创新和架构升级强化自身的竞争力和适应性，支撑业务健康高效迭代。本文介绍了我们如何通过技术栈升级、架构能力提升以及稳定性建设，来实现全链路架构的演进。借助Golang、百度自研GDP开发框架和ExGraph图化引擎，我们对视觉搜索展现架构进行了全面重构，并重新定义了视觉搜索全系统通路上的模块职责和分层逻辑，开展了一系列系统收敛内聚优化。此外，我们还建设了配套稳定性基础设施，确保系统的高效运行。期望大家能有所收获和借鉴。

　　01 背景

　　视觉搜索是基于图像识别和深度学习技术实现的图像搜索应用，区别于传统文本方式搜索，接受用户拍照/上传图片输入，识别图像特征和内容，获取图片内容相关的检索结果。目前广泛应用在学习、动植物、商品等领域，满足用户对图片的认知、购买等多元需求。　　

△视觉搜索业务概览

　　随着产品的高频迭代和规模迅速拓展，视觉搜索架构需要通过持续的技术创新和架构升级，强化自身的竞争力和适应性，以应对业务和技术的一系列新挑战。具体手段为：

　　【技术栈更新】现有展现架构采用PHP开发、HHVM运行，随着HHVM基础设施停止维护，以及对异步/多线程等功能支持的局限性，我们需要探索下一代框架和语言，以持续满足服务高可用性、及AI大模型挑战下的新产品迭代要求

　　【架构能力升级】随着业务高速迭代，要求系统架构也必须随之升级以不断适配新的业务需求，当架构通路中开始出现庞大的单体应用模块和日益复杂的模块交互，需要及时开展架构重构/优化，保障业务健康可持续迭代

　　【稳定性保障】稳定性方面，随着技术栈和架构的升级，配套的基础技术建设也当随之加强，从测试流水线、监控拦截、线上监控、定位工具等各环节持续健全稳定性能力，从而高效实现问题闭环，确保服务稳定性目标得以实现

　　02 解决方案

　　2.1 整体设计

　　本项目从展现架构重构、系统分层改造、基础技术建设等多个角度出发，结合图化思想，对现有视觉搜索整体架构进行全链路重构优化，同时一方面接入搜索内部公共技术栈，另一方面完善视觉自有技术基建，建设如下全系统图：　　

△视觉搜索全系统图

　　展现架构重构

　　接入层：开发视觉BFF（Backend For Frontend）接入模块，提供多端统一适配&动态路由解决方案，提高系统可扩展性和可维护性；

　　技术栈：PHP+HHVM转向Golang，支持并发/异步/流式交互能力，提高系统性能；同时，基于百度内部的Golang开发框架和搜索内部自研的ExGraph图化服务，对展现模块进行彻底重写，以DAG图的方式描述业务流程，算子化实现业务细节和基础Lib，并保障算子的可复用性；

　　全系统改造：

　　分层：明确视觉整体架构分层及模块定位，对检索通路中现存庞大单体应用解耦拆分，实现展现层与检索层单次请求多路召回，降低业务与数据耦合，简化架构通路交互；

　　协议：统一召回数据及模板展现数据协议，提升研发效率；

　　稳定性建设：

　　流水线：健全全模块持续集成与持续交付流水线能力；

　　标准化：拒绝重复造轮子，复用搜索内部配套运维与问题闭环生态环境，统一基础技术栈，降低运维成本；同时基于Prometheus+Grafana监控解决方案重建业务监控系统，保障核心稳定性。

　　2.2 详细设计

　　2.2.1 接入模块建设

　　通过建设视觉BFF（Backend For Frontend）模块提供多端适配问题解决方案，提高用户跨设备使用业务的无缝性和一致性，并且使得业务需求的开发能够更专注于需求自身逻辑，实现高效接入和迭代。为满足上述要求，视觉BFF整体流程如下：　　

△视觉接入层整体流程

　　服务初始化：系统首先完成服务启动，初始化App及依赖词典、服务等；

　　多端适配：接收到用户实时流量请求时，首先完成对不同前端应用输入数据协议的解析适配，然后执行中间件，识别用户信息、设备信息，完成抽样染色、功能开关初始化等；

　　路由分发：根据多端适配信息，以及流量分发配置规则，动态调整负载均衡和API响应；

　　结果输出：收集下游返回数据，适配各端私有化协议，确保业务数据传输到不同前端应用的安全性与一致性。

　　2.2.2 展现模块重构

　　视觉展现模块的主要职责是使用图片请求检索系统获取结果，基于检索数据，完成不同业务场景下的数据解析和组装渲染，最终在多终端上呈现给用户丰富多样的结果满足样式。本小节将主要介绍使用Golang对视觉展现模块进行图化改造和重写的实现方案。　

△视觉搜索展现模块架构图

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

　　模块拆分：解决原展现模块自身复杂度的问题，拆分独立功能，如上文所述的BFF接入模块，让UI聚焦到具体的业务逻辑实现，忽略不同端或者场景不同协议以及不同参数等的输入输出问题；

　　逻辑分层：为了保持UI模块有清晰的逻辑分层，便于业务长期健康迭代和维护，将UI内部按照功能逻辑定义分层结构，在后续迭代里遵循分层规范，严格控制相应的代码和逻辑管理；

　　图化改造：抽象和封装公共算子及业务算子，简化业务主干逻辑，通过图化引擎编排和调用算子实现需求->图->算子->Lib库/基础设施的层次调度：　　

△检索流程图化改造前后对比图

　　图化引擎选型：采用百度搜索展现团队自研图执行引擎ExGraph，提供了一套利于研发人员和机器理解的图语言，该图语言将算子作为基础单位，通过串行组、并行组、子图、条件算子、switch算子、中断、等待等机制，能灵活适配复杂的业务流程；

　　公共算子：可在不同业务图流程中灵活配置调用的功能算子，目前已实现图片上传，缓存管理，风控，检索请求，渲染等，一处开发，多处快速配置即用；

　　业务算子：如特定的数据解析、字段填充，下游请求构造等；

　　策略组：为了使算子逻辑清晰简洁，通过策略组的方式来管理个性化场景，如参数处理策略组、意图选择策略组、不同垂类的整页展现策略组等；

　　公共Lib库：封装一些业务逻辑无关的开发常用功能库，例如规则引擎、数据结构容器（如集合、有序map以及字符串常用方法等）、图片下载工具等，提高代码的可复用性及研发效率。

　　2.2.3 系统分层改造

　　在前2小节中阐述了对视觉接入和展现模块的图化重构及技术栈升级，为服务性能、技术储备、研发效率等方面带来了一定程度的提升，随后我们转向全系统架构通路，着手解决如下问题：

　　模块交互复杂：一次用户请求过程中，展现模块与检索模块多次交互，不仅增加了网络耗时，也增加了线上问题定位的难度，同时造成线上服务间相互依赖，甚至请求成环等问题；

　　检索系统复杂：视觉在线检索系统承接了数十业务场景下的多轮调度、触发、召回等检索逻辑、图片处理等策略逻辑、以及数据整合等展现逻辑，是视觉架构中最为庞大的单体应用，随着业务日益复杂化和大模型应用场景崛起，检索系统开始面临架构设计、模型管理、可扩展性、流式能力、高速迭代等方面的多重诉求和挑战；

　　数据适配复杂：缺少业务标准数据定义，以模板驱动数据选择，数据通路可复用性较差，展现模块中字段适配归一的逻辑占比较高。

　　首先，我们梳理了全链路模块内部逻辑，明确各模块的职责功能，重新制定模块间的交互接口协议及模块内的逻辑分层，在此基础上，完成了对检索模块中业务展现、检索及策略逻辑的解耦重构，主要工作包括以下几个方面：　　

△视觉全系统分层改造前后对比

　　展现服务分层改造：模块内部定义逻辑分层，降低模块代码复杂度，提升可复用性，同时提高系统的异步执行和并行化能力；

　　检索接口收敛内聚：检索服务底层框架升级，采用图化思路重写，以算子化的方式重新拼装组合不同场景及不同下游的逻辑调度，对上游提供收敛后的统一检索接口，一次检索请求即可拿到全部召回结果和策略信号；

　　庞大单体应用解耦：重新分解和认领庞大单体应用中的功能，按照系统分层完成对应逻辑的迁移重构，最终完成目标模块解耦下线，提升系统效能，优化机器资源；

　　数据协议标准化：统一召回数据规范，并制定标准组件模板协议，以数据驱动展现模板选择；同时增加特征通路和日志通路，去除数据透传模块依赖。

　　2.2.4 稳定性建设

　　随着视觉架构和各模块的演进改造，我们也梳理了配套的质量保障技术设施，查漏补缺，完善感知>处置>预防>根因分析复盘>巡检各环节的稳定性基建，从而保障服务能够提供稳定可靠的用户效果。

　　故障感知：

　　首先，GDP框架提供了一套基于Prometheus的标准化采集&监控解决方案，能极大降低传统日志采集+解析+监控配置+可视化的学习和管理成本，它定义了统一的指标规范，可由业务方按需调用接入。基于该标准化监控方案和业务核心诉求，我们建设了如下核心指标故障感知指标：

　　上述指标的监控报警生效在研发、测试、上线全流程，快速发现故障，确保各阶段业务效果符合预期。

　　故障处置：

　　长期以来，经过对线上各模块错误日志的治理和代码重构优化后，线上日常故障更多的集中到了机器/实例/应用等容器管理的健康状态波动上，因此，我们通过ALM（Application Lifecycle Management）机制，依据健康探活、日常quota及日常采集指标，自动化实现实例迁移以及模块容量弹性伸缩管理，提升系统的自愈能力，同时提升资源整体的分配率和使用率。

　　根因分析复盘：

　　通过ALM自愈机制我们实现了问题实例的快速感知和自动迁移，但在日常运维中，不易做到快速介入人工分析，导致现场丢失，以至于cpu/mem/协程等指标异常多归于偶发问题。为了有效实现问题排查和闭环，搜索团队基于Go语音内置pprof性能工具及监控平台，自研pprof自动化采集系统Keeper，在对应报警事件发生时，通过回调触发pprof文件采集及上报，能有效保留问题现场，让业务做到对故障根因的分析复盘。

　　辅助平台工具：

　　调研平台：全模块建设线下仿真环境，一键搭建/升级环境模块，快速满足环境交付需求，提高业务评测、开发联调效率；

　　Debug平台：平台化模拟端到端请求，可视化展现全链路模块日志，快速实现问题复现和定位；

　　Trace平台：采集业务核心模块，自定义日志切割规则及链式日志关键字，条件化快速查询线上日志，提高定位效率；

　　03 总结

　　本文介绍了视觉搜索架构为了应对业务和技术发展带来的一系列挑战，从技术栈更新、架构能力升级、稳定性保障等方面入手，采取了全链路架构演进的技术应对方案。基于业务特点，结合百度内外的技术设施储备，我们采用Golang+GDP开发框架+ExGraph图化引擎重构了视觉展现架构，将其拆分为接入模块及展现模块，降低多端数据与业务逻辑耦合度；然后重新定义了视觉搜索架构分层及模块功能职责，并对展现模块及检索模块进行了数据协议统一、功能收敛内聚、逻辑分层改造工作；最后完善了业务感知>处置>预防>根因分析复盘>巡检各环节的稳定性基建。本文旨在将视觉搜索架构演进的思路和方案分享给大家，希望对面临类似挑战的业务有所借鉴，未来我们仍将持续优化业务系统和性能，为大家提供更好的产品服务。