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

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

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

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

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

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

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

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

搜索共分为4个基本步骤

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

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

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

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

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

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

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

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

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

SPI定义如下图

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

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