当前位置 鱼摆摆网 > 资讯 >
盒马生鲜搜索服务化实践与思考
作者:鱼摆摆 2019-07-16 15:15背景
随着盒马和淘鲜达业务不断发展,业务需求也从开店扩张(拷贝不走样)逐渐向精细化运营方向转变。外部商家的接入、业务形态的扩展、集团业务的融合势必带来更多的需求。盒马业务发展到如今,速度不但不会降,而且会越来越快。如果继续按照原有的系统设计思路,要么累死都无法满足业务需求,要么无限招聘加大人力成本,似乎都不是解决问题的好办法。
如果能够将系统能力抽象为组件,并且可以清晰完整的进行描述。当一个新业务到来时,如果通过已有组件能够支持业务,那么就可以通过搭积木的方式快速支持;如果缺少哪个组件,只需要开发这个组件即可。组件是抽象的能力点,可以使用多态能力对不同的业务进行扩展支持。
就我个人而言,我认为服务化应该做到以下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平台。对应的业务调用即可。
后续规划
在后续项目中,不断将现有系统进行服务化改造。这样我们才能提供更多的能力点支持业务,而已有的能力要趋于稳定,在保证稳定性的情况下支持业务的快速发展。
相关文章
- 淘宝创业一对一孵化,合同保底年赚10万以上!
- 怎样经营服装店的技巧(服装店的营销策略和方法)
- 阿里为什么放弃易果选择盒马生鲜?
- 盒马生鲜,第一个将活的梭子蟹送内陆城市的新零售生鲜电商
- 新零售“休整”的下半场,盒马为何又出了一张“新牌”?
- 盒马鲜生CEO侯毅称「盒马去中心化的物流优于京东的物流」,如何评价这番言论?
- 未来十年的零售模式会向哪个方向发展?
- 2018年国内生鲜市场如何演变?
- 阿里巴巴的盒马生鲜被立案调查,对此你怎么看?
- 阿里盒马生鲜的核心竞争力是什么,能否跳出电商超市难以盈利的怪圈?
- 盒马生鲜开在三线城市能盈利吗?
- 如何看待盒马生鲜帝王蟹的供应商买下阿拉斯加一座岛,专供中国吃货运送帝王蟹?
- 贵阳的盒马生鲜超市怎么样?
- 深圳有几家盒马生鲜超市?
- 全部评论(0)