盒马生鲜搜索服务化实践与思考

盒马生鲜搜索服务化实践与思考

背景

随着盒马和淘鲜达业务不断发展，业务需求也从开店扩张（拷贝不走样）逐渐向精细化运营方向转变。外部商家的接入、业务形态的扩展、集团业务的融合势必带来更多的需求。盒马业务发展到如今，速度不但不会降，而且会越来越快。如果继续按照原有的系统设计思路，要么累死都无法满足业务需求，要么无限招聘加大人力成本，似乎都不是解决问题的好办法。

如果能够将系统能力抽象为组件，并且可以清晰完整的进行描述。当一个新业务到来时，如果通过已有组件能够支持业务，那么就可以通过搭积木的方式快速支持；如果缺少哪个组件，只需要开发这个组件即可。组件是抽象的能力点，可以使用多态能力对不同的业务进行扩展支持。

就我个人而言，我认为服务化应该做到以下3点

能力可视化，各域能够清晰完整的表达出已有的能力点，让产品和运营了解我们能干什么。流程可编排，通过编排流程完成业务需求，通俗点就是搭积木，且搭好的业务可管理。组件多态化，不同的业务形态可以有不同的业务实现。盒马搜索已有业务

盒马搜索从大的方向上进行划分，主要包含以下三部分业务

盒马搜索自身业务盒马主搜索、推荐搜索、优惠活动搜索等等。底纹、热词、suggest。搜索商品数据引擎基于门店（storeId）+商品编码（skuCode）维度的查询服务，包括商品、库存、优惠、履约等信息。同时向搜索、分类、投放、推荐、购物车、手淘小程序提供服务。dump数据搜索、分类、推荐共有数据底层。服务化思考与设计

在这里需要向大家安利一下盒马NBF平台，具体可以参考辉子老师的大作盒马开放服务框架。在这里需要说明一下，服务化是一种设计理念，而NBF是目前我能接触到的最好的服务化实现工具。

盒马搜索自身服务化

从消费者视角看，目前盒马搜索已有的产品力如下图

而目前盒马搜索处理流程如下图（部分产品力未标识，理解意思就好）

搜索共分为4个基本步骤

request build，接收外部MTOP请求，然后串行调用request filter，拼接上对应的业务参数。调用搜索引擎。result build，收到引擎的返回结果，然后串行调用result filter，解析出返回结果。Ext service，并行调用外部请求用于补全数据，如场景卡、商品数据引擎、投放广告资源位等等。

根据以上流程，就可以比较清楚的确定如何进行搜索的服务化设计，如下图所示

每个流程可以定义为一个SPI，每个流程中的能力点也可以定义为一个SPI。将SPI注册在NBF平台，使能力可视化。通过流程编排，将SPI编排成业务流程，完成一次完整的搜索流程。SPI可以有多个bundle实现，通过传入的业务识别码（如盒马，淘鲜达，猫超，餐饮等等）进行业务路由，实现多态能力。搜索商品数据引擎

搜索商品数据引擎是盒马搜索中比较特殊的一个应用，主要用于补充商品信息，如商品的库存、优惠、履约等。为什么需要这样一个系统，是因为盒马商品的品类结构导致。盒马以生鲜蔬菜水果为主，这些品类的复购概率较高，用户在列表页加购的心智很强。比如一个青菜，如果你天天买的话根本没有必要去看详情和评价。这就导致需要在列表页透出准确的库存和优惠数据，而优惠数据又和人群相关，人群信息不可能放在搜索引擎，那么就需要当引擎返回结果后，再调用补全服务。随着该应用的发展，逐渐向分类，投放、推荐、小程序和tpp提供服务。

搜索商品数据引擎在2017年末做过类TMF3的改造，将整个处理流程变为扩展点+扩展实现的方式，扩展点可以自由编排，如下图所示。除了组件未做到能力可视化，其余的流程编排与多态能力已经可以实现。这就与服务化的思想比较接近了，所以对于此系统的服务化改造也就相对简单。

从图中可以看到，扩展点就相当于是能力点。扩展实现相当于bundle。diamond配置相当于流程编排。只要将扩展点在NBF注册为SPI,将bundle作为能力实现，即可实现该系统的服务化。dump数据

盒马搜索dump是整个盒马导购的基础数据，负责将散落在各域的数据加工处理成宽表，然后提供基础数据能力。在dump数据进行服务化的过程中，整个设计思路就需要发生一点改变。

盒马搜索dump发展到今天，遇到最大的问题并不是各种各样的业务形态导致业务需求增多，因为dump数据作为底层数据，相对来说较为稳定。目前遇到最大的问题是给到dump处理的各种各样的表结构。商品有商品的模型（主档->机构->门店）；库存有库存的模型（skuCode+storeId）；营销有营销的模型（优惠详情+优惠分组）。但搜索最终需要把这些数据转为skuCode+storeId的维度。以前都是搜索去深入了解这些表结构，累死累活先不说，一旦对方修改了模型，搜索也就需要跟着变更。在这里，搜索作为数据使用方，其实应该在这里定义数据维度的SPI，即搜索定义什么样的数据结构才能进入dump。然后由各域去实现这个SPI。我们只应该识别这个“SPI”，而不应该感知“bundle”。

针对以上问题，在盒马各个兄弟团队的帮助下。商品、库存、营销都将数据处理为dump需要的数据结构，在这里表示由衷的感谢，@项鸿、白雁、林尘，多谢各位老大的支持。

服务者视角能力

以上所述，均为搜索域自身系统拆解后的服务化设计。这些能力点和流程更多的使用者应该是搜索开发同学。而从盒马整体设计来看，搜索应当向外域暴露能力点。这些能力点外域的开发和PD应该都能够了解。下图是从服务者视角看搜索应该暴露的能力。

搜索数据配置能力圈选商品能力 itemSelect。搜索主链路屏蔽能力 itemMask。搜索主链路去屏蔽能力 deleteMask。搜索查询配置能力search搜索能力。getItemInfo搜索商品数据引擎能力。搜索服务化实践-星巴克项目

项目背景是星巴克商品进入在线点餐，从导购->详情->交易->履约->餐饮都要感知星巴克商品。如果按照以前的经验，大概率按以下流程处理：

各域的PD拉上开发评审说要新增一个逻辑。商品中心的开发同学搞个页面，然后运营给这些商品打标。每个域的同学在自己的代码中识别这个标，写一堆的ifelse逻辑。如搜索开发对这个标的处理就是解析这个标返回给投放，让投放的开发同学进行过滤。大家约个时间写个发布计划按流程发布上线。

到此为止，项目上线了。过两天，又来了个Costa项目，luckin项目等等。处理流程基本一样，难道我们又要去识别新的标然后再发布一次？或许有人会说，代码可以搞得灵活点，比如可以配个diamond或者switch。这么搞有两个问题，第一，PD或者业务不知道这个diamond配置，业务逻辑全部藏在代码和配置中，除了熟悉的开发没人知道（说不定过一段时间开发也不清楚了），业务全貌缺乏，很容易踩坑；第二，这个能力点已经开发好了，还需要开发介入进行线上配置，改diamond也属于发布，改不好一样会出故障。

对于以上问题，本期星巴克项目处理流程如下：

由业务方申请场景码。每个域负责解释这个场景。如果已有能力能够支持，则不需要进行开发；如已有能力不支持，则开发改能力即可。搜索dump对于这个场景码没有响应的能力支持，所以需要进行开发。提供itemSelect的SPI，然后由业务方调用。商品数据引擎将这个场景返回供投放进行商品过滤，即过滤出来的商品都是属于在线点餐的商品。

SPI定义如下图

当后续由新的项目到来时，搜索开发完全可以不进行线上变更（后续甚至都不需要感知），SPI的能力已经集成在NBF平台。对应的业务调用即可。

后续规划

在后续项目中，不断将现有系统进行服务化改造。这样我们才能提供更多的能力点支持业务，而已有的能力要趋于稳定，在保证稳定性的情况下支持业务的快速发展。