京东到家搜索系统架构演进

最新推荐文章于 2025-10-10 14:26:02 发布

原创

最新推荐文章于 2025-10-10 14:26:02 发布 · 1.9k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#系统架构 #大数据 #搜索引擎

本文介绍了京东到家搜索系统从1.0到3.0的演进过程，从基于LBS的召回策略到精细化多路召回和模型升级。系统经历了从简单可用到高可用、高扩展性的转变，包括建立索引容灾能力，优化排序模型，并通过策略调整提升召回率和排序效果。未来，将继续向智能化和场景化方向发展。

文｜魏铮

编辑｜刘慧卿

一. 前言

京东到家作为行业领先的即时零售电商平台，依托达达快送的高效配送和大量优秀零售合作伙伴，为消费者提供海量商品小时达的极致服务体验。随着平台中的商品供给日益丰富，帮助用户准确寻找目标商品的能力就会显得越来越重要，而搜索系统在电商平台中即承担着这样的职责。

在到家平台中，搜索系统承接了多个主要流量入口，在不同业务场景下为用户提供了多元化的关键字商品检索能力。目前，搜索系统在平台中覆盖的主要场景有首页搜索、频道页搜索、秒杀活动页搜索、券购搜索及到家小程序平台搜索等，如下图所示：

随着到家业务发展，到家的用户量级也在持续增加，为了满足用户购物需求，给用户一个便捷的购物体验，搜索系统一直在持续地进行架构迭代和策略升级。本文将对到家搜索系统架构演进历程进行详细介绍。

二. 搜索系统架构演进

2.1 到家搜索系统1.0

基于LBS搜索召回场景

由于到家是基于LBS的即时零售业务场景，所以在搜索系统架构上与传统电商搜索相比也会有所区别。基于LBS的搜索系统在保证商品相关性和排序结果合理性的同时还要通过地理位置因素对召回商品范围进行限定。在到家系统中，我们采取的方法是通过墨卡托投影原理将门店的配送范围映射为多个有限区域块，再结合倒排索引找出覆盖目标位置的门店供给列表。对应到搜索场景中，我们所需要做的就是在给定的门店列表范围内通过Query进行高效地商品查询。

建立“可用”的搜索系统

在到家发展初期，搜索系统设计思路以简单、可用为目标，架构上采用分层单体架构。在实现上，通过对当前供给门店列表进行ES terms查询来保证LBS条件限定，而Query与商品的匹配主要依靠对Sku名称进行ES的query_string查询。同时,对用户输入的Query会通过分词方式进行简单的品牌品类成分信息提取，并用于对查询语句的boost提权中。ES查询结果顺序就是搜索系统的返回顺序，分页也交由ES来控制。这样一来，就实现了1.0版本的到家搜索系统。

小结

随着业务的发展，平台上门店和商品的供给数量呈爆发式增长，最初这版搜索架构在业务支持上显得愈发吃力。主要体现在以下几点：

1. ES深分页瓶颈
在召回期间通过ES的from size方式进行分页控制。在深度分页情况下，这种查询方式非常低效，查询性能会直线下降。

2. 缺乏完整召回能力
由于通过ES进行分页控制，所以每次请求搜索服务内部只能从ES拿到当前页的返回数据，无法得到完整召回数据。但一个完整的搜索系统应该包含对搜索结果多维度筛选功能、搜索结果聚合展示功能，如果每次只能拿到一页数据，那么在业务玩法上就会受到极大的限制。

3. 排序干预能力有限
在商品搜索场景中，ES的bm25评分可以反映出Query与Sku名称间的文本相关性，但除此之外，搜索排序逻辑还需要关注商品的价格、评价、门店信用、商家质量、促销力度等维度特征，仅通过bm25评分作为排序依据是远远不够的。但如果所有排序因素都通过ES加权语句实现，最终查询语句就会变得十分复杂，并且在索引中还要维护所有排序特征信息，这显然不太现实。所以，需要建立一套独立的搜索排序服务来承接这样的职责。

4. ES集群单点依赖
搜索业务最基本的能力就是召回，而召回能力又建立在了底层索引数据基础之上。在搜索1.0版本中底层索引由一套ES集群支撑，但这就会造成整个搜索系统对这套ES集群的单点依赖，如果ES出现问题那么整个搜索业务就会面临瘫痪的风险。

2.2 到家搜索系统2.0

将1.0版本搜索系统中的主要问题进行归类可以发现，除了底层集群单点依赖之外，其余三个问题之间都有着直接或间接关系。

ES分页依赖 ——> 无法完整召回 ——> 排序干预能力有限

所以，优化工作的核心目标是要替换掉当前的ES分页方式，将全部命中数据完整召回。基于以上思考，我们提出了以下方案：

弃用ES分页，全量召回内存分页
抽象排序模块，独立服务化部署

重构召回

首先需要考虑的问题是如何将全量数据召回到内存中。如果from 0 size n设置一个较大的数值，那么ES每一个分片均会召回n条数据后再汇总重排，引发上文中提到的深分页问题。而ES的另外两种分页方式scroll和search after更是不满足C端场景使用需求，尤其是scroll在高并发场景下还会有极大的性能风险。相比之下，还是from size的查询方式更适合当前C端搜索场景需要。

在确定from size查询方式后，我们尝试找到一个即满足业务需求又符合性能要求的size临界值。随着size增大,ES的查询性能持续下降。例如，在600qps和5000qps场景分别测试不同size查询性能，得出如下结果: