作者 | 王兆雄、衷颖杰、刘龙
编辑 | Tina
背 景
在 2021 年下半年，由于业务调整，我们团队在原来已经负责全局搜索服务的基础上，又对接了 i 音乐和 i 主题的搜索服务，在团队人员不变、需求高速迭代、业务规模快速增长的情况下，效能上面临的问题也越发凸显：
没有统一开发模式。三个业务最初是由三个不同的团队分别开发迭代，不同团队有不同的开发模式，导致相同业务逻辑的实现方式千差万别，更多的是根据开发人员自身的喜好或者代码习惯进行开发，缺少统一规范；
缺少公共能力沉淀。由于业务由不同的团队开发，各个业务更多的是根据各自的业务需求纵向发展，通用功能很难沉淀，存在大量功能重复的代码逻辑，并且随着团队人员的不断更新，团队人员的主要精力放在业务迭代和系统维护上，缺少统一的系统能力抽象；
系统功能不断扩展，业务复杂性不断上升。随着需求的快速迭代，业务系统的代码量和架构复杂度也在快速提升，业务代码量级已经发展到十万级别的规模。开发过程中很难保证对文档做出有效沉淀，新接手的同学在维护迭代时只能通过阅读源码去理解业务逻辑，难以高效进行需求迭代；
业务流程复杂，各种功能繁多。搜索系统本身就很复杂，搜索调用链路长，涉及到的周边系统多。开发同学在进行业务迭代时，还需要考虑到是否会对上下游链路产生负向影响。
总体来看，我们要解决的问题是：如何更快开发迭代少写或不写代码，更快上手优化业务流程易理解，更快上线交付操作简单易实现。
搜索流程分析
三个项目面对的业务场景大相径庭，但也都是搜索相关的业务场景。所以我们对这三个业务流程进行仔细的梳理，并从中发现了一些规律。
全局搜索流程
全局搜索是 vivo 手机重要的内置应用，致力于满足用户信息、服务获取的需求，为用户提供高效、个性、智能的建议、搜索服务，提供一站式的搜索体验。
全局搜索应用界面
全局搜索的具体业务流程如下：
用户请求，用户通过全局搜索客户端发起主动搜索请求；
前置处理，服务端中控服务在接收到用户请求后，会依次完成意图、特征、分词、搜索词处理等步骤，为后面的召回阶段做准备；
垂类召回，中控服务将请求分发到各个垂类服务，并行召回数据结果；
后置处理，中控服务在接收到各垂类的召回结果后，会进一步对整个结果进行过滤、排序、人工规则干预、结果高亮、分页等步骤的处理，并生成最终的数据结果；
结果返回，服务端将最终结果返回给客户端。
全局搜索处理流程
在上图的多垂类结果召回阶段中，每个垂类的具体处理流程与整体流程基本一致，即也要经过前置处理，数据召回、后置处理等阶段，具体如下：
垂类具体处理流程
i 音乐搜索流程
i 音乐搜索是 vivo 默认的音频播放器 i 音乐 App 内的搜索功能，入口为 App 首页的顶部搜索框，为用户提供便捷的音乐搜索服务。
i 音乐搜索应用界面
总体业务流程如下：
用户请求：用户通过 i 音乐客户端发起主动搜索请求；
前置处理：搜索服务在收到搜索请求后，会依次完成参数校验、搜索词归一化、同义词、纠错词、禁搜词、意图识别、实体识别，为后面的召回阶段做准备；
数据召回：并行检索歌曲、歌手、视频、专辑、歌单、听书结果内容，从不同的数据源召回相关数据；
后置处理：给歌曲、歌手等楼层做排序、聚合等处理，并提取各楼层精品结果生成最终数据；
结果返回：服务端将最终结果返回给客户
i 音乐搜索流程
i 主题搜索流程
i 主题搜索是 i 主题应用的搜索服务，为用户提供包括主题、铃声、字体、壁纸等资源的搜索。
i 主题搜索应用界面
i 主题搜索流程与前两个类似，具体处理步骤如下：
用户请求：用户通过 i 主题客户端发起主动搜索请求；
前置处理：搜索服务在收到搜索请求后，会依次完成搜索词的标准化、同义词处理、拓展词处理、黑名单过滤以及标识符处理，为后面的召回阶段做准备；
数据召回：从 ElasticSearch 以及 Redis 中召回包括主题、字体、壁纸等资源相关数据；
后置处理：对召回结果进行排序、去重、过滤处理，根据人工干预规则进行调整，并进行高亮和分页从而生成最终结果数据；
结果返回：服务端将最终结果返回给客户端
i 主题搜索流程
平台能力建设
搜索流程抽象
通过分析以上三个不同业务的搜索流程可以发现，虽然它们业务形态千差万别，但是对流程进行抽象后，三个搜索业务的流程基本一致，具体如下：
搜索服务的整体流程
前置处理阶段：对用户输入的查询词进行处理，主要包括请求参数的加解密，查询词的改写 (纠错、补全、同义词等)、理解 (意图、实体、分词) 等。
召回阶段：单路召回或者多路召回，包括倒排检索召回、模型计算召回、向量检索召回，但是全搜业务比较特殊，是多垂类召回。
后置处理阶段：对召回结果进行排序，包括粗排 (相关性模型排序，时效性排序)，精排 (权威性、质量度、多样性、模型、神经网络等)，合并不同来源数据并去重；根据活动运营规则，临时干预策略或者人工配置的规则对排序后结果进行过滤筛眩
对流程进一步抽象后可以看到，搜索流程具有一般性，即用户发起搜索请求，经过前置处理、数据召回、后置处理后返回搜索结果，搜索上下文在整个过程中负责中间数据结果的传递，具体如下：
搜索服务流程抽象
综上所述，一个搜索流程可以抽象成一个执行计划，每个流程又由许多不同的步骤 (执行阶段) 组成，每个步骤包含不同的业务逻辑 (处理器)，具体对应关系如下：
业务功能对应关系
针对开发功能中面临的实际问题，我们的解决思路是：
开发流程规范化。制定统一的开发规范，对原有的业务功能进行解耦，确定每个功能的职能边界，尽量复用公共组件进行开发；
公共能力组件化。梳理业务流程，将公共能力沉淀到搜索平台中形成公共组件，业务人员在开发时可以直接通过业务配置进行复用。同时，这些通用能力是标准化的，业务可以按标准规范进行开发，易于在不同业务中分享和使用。当通用组件满足不了业务场景时，业务人员就可以根据标准规范补充更多的通用组件，快速满足今后类似的需求开发；
搜索流程可视化。以流程图的形式展示完整的业务搜索流程，业务人员可以通过流程图快速熟悉业务流程，了解每个功能的上下环节，更好的把控整体业务流程。
组件能力实现
通过对业务逻辑进行抽象，我们发现搜索流程和具体步骤都不会涉及到具体的代码逻辑，只是对整体搜索过程进行串联和约束，为此我们开发了搜索平台流程编排功能，并对基础功能进行抽象和封装，形成一个个通用的系统服务组件给不同业务使用，而业务中特有的业务逻辑可以定制开发，这样可以将整个业务逻辑中变与不变的部分区分开来。
平台化后架构图
我们对不同业务的公共能力进行抽象，并封装成公共组件由搜索平台进行管理。在业务对接搜索平台后，业务人员就不再需要关注基础能力的具体实现，而是可以直接在搜索平台中进行配置，从而专注于业务功能的迭代；与此同时，业务人员还可以根据实际需要不断扩充搜索平台的组件类别，提升组件能力，并提供给其他业务使用。业务和平台之间相辅相成，业务促进平台能力的提升，平台也能进一步赋能业务的发展。
针对于不同业务场景中存在的相同逻辑功能，我们参考了低代码平台的实现思路，将通用功能封装成公共组件，开发人员通过页面拖拽配置组件实现通用的功能，少量代码即可完成业务功能扩展，从而实现便捷构建搜索流程。使用者可以通过页面可视化配置的方式对整个搜索流程进行组装，从而满足不同的业务需求。
通过对已有业务能力以及一般搜索业务流程逻辑进行梳理，我们总结了 3 大类 8 个小类的公共组件模块，具体如下：
公共组件模块
以上组件基本涵盖了搜索全流程的各个环节，业务开发人员在日常迭代过程中可以直接使用组件库中提供的组件模块进行可视化开发，如果不能满足需求，可以自行进行扩展。同时我们也定义了一套标准规范，所有内置的公共组件都按照这套规范进行开发，业务人员也可以按照这套规划开发自己的组件并共享到组件库中，而组件又是可以插拔的，业务之间都可以方便的拿来复用。
搜索链路监控
搜索服务涉及的垂类业务多，调用链路长，不仅包括团队自身维护的业务垂类，还包括算法团队、图谱团队等，当线上业务出现问题或者搜索结果出现 badcase 时，往往只能通过日志信息进行排查。这样不仅需要有详细完整的日志信息，而且要求开发人员能够熟悉整个业务流程才能快速对问题进行定位。在调用链路还比较短、业务功能还比较单一的时候，这种方式还是能够比较有效的帮助我们对问题进行定位和排查。但是随着业务的快速发展以及用户数量的快速增长，日志信息的规模也呈现指数级别的增长，这样会给日志采集系统带来极大的压力。此外，日志信息往往不能直观的展示服务中的具体问题，往往需要对应功能模块的开发同学进一步进行判断和定位，从而极大提高了问题的解决成本。因此，我们团队对业界已有的服务全链路监控工具进行调研，最后选择 SkyWalking 作为搜索服务的链路监控工具。
SkyWalking 是一款优秀的 APM 工具，提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。在实际使用过程中，由于搜索服务每天的请求量较大，我们并不是直接使用 SkyWalking 对每个请求的完整调用链路数据进行监控，这样每天会产生几十 TB 的监控数据，而且绝大部分都是无用的，而是对某个调试请求接口进行监控。当线上环境出现搜索结果异常或者其他问题时，可以直接通过请求该接口进行问题复现，然后通过 SkyWalking 对整个调用链路的请求和访问数据进行收集监控，并通过 SkyWalking 的可视化界面对问题快速定位。
SkyWalking 监控流程图
监控流程如下：
在项目代码中预设相关监控注解埋点。首先在项目工程中引入 SkyWalking 相关 jar 包，然后对请求链路上调用的方法添加注解，并输出入参和出参；
部署 SkyWalking 服务，并配置数据存储集群。使用容器对 SkyWalking 进行部署，并配置 SkyWalking 链接 ElasticSearch 集群，ElasticSearch 集群负责存储 SkyWalking 的各种上报数据；
通过指定的问题复现接口获取请求链路数据。在线上环境的结果数据出现问题时，通过查询关键字以及其他有关信息进行快速定位，然后拼装完整访问参数调用请求接口对文件结果进行复现；通过 SkyWalking UI 的追踪页面功能对整个调用链路的数据进行排查，快速定位出现问题的功能和代码并进行修复。
落地实践与成果
目前我们已经将全局搜索一部分业务接入搜索平台，并将逐步对接 i 主题和 i 音乐搜索业务，且已经初见成效：
项目维护成本降低。通过将基础能力沉淀到平台中进行复用，我们将至少可以减少了 30% 的项目代码量；并且通过可视化组件配置，业务逻辑将变得十分直观，业务人员可以更高效的理解整个业务链路逻辑；
项目开发效率提升。在平台化升级后，我们可以将更多的精力投入到业务逻辑实现上，业务功能开发周期由原来的 5 天缩短到 3 天左右；
减少开发人员的投入。原来我们需要投入 8 个人力进行三个项目搜索功能的开发工作，现在我们只需要 5 个人力就可以保障业务的正常迭代和运行；
问题解决速度加快。在对接 SkyWalking 链路跟踪服务后，我们对于产品中遇到的问题的定位和解决时长由原来的小时级缩短到现在的分钟级。
总结与展望
通过对全局搜索、i 音乐搜索、i 主题搜索三个业务场景的分析和搜索流程的抽象，我们一步步推进项目架构的迭代和创新，打造能力复用的搜索平台为业务开发降本增效。
未来，我们将进一步丰富和完善组件库资源，降低业务开发成本；深化平台能力，在准确性、稳定性、易用性等方面持续进行提升；优化用户使用体验，完善平台运营机制，不断提升产研迭代效率，更好的为业务赋能。
作者介绍：
王兆雄、衷颖杰、刘龙，vivo AI 架构工程师，来自 vivo AI 研究院推荐工程组深圳团队。
团队介绍：
活动推荐
