SaaS 电商设计 (八) 直接就能用的一套商品池完整的设计方案(建议收藏)

一.前言
- 1.1 在哪些业务场景里使用
- 1.2 一些名词搞懂他
- 1.3 结合业务思考一下-业务or产品的意图
二.方案设计
- 2.1 业务主流程
- 2.2 一步步带你分析B端如何配置
- 2.3 数据流
- - 2.3.1 ES 数据表建设
  - 2.3.2 核心商品池流程
  - - 2.3.2.1 商品池B端维护流程
    - 2.3.2.2 商品池版本更新逻辑
- 2.4 核心代码设计
- 2.5 附 DB 设计以及 Mapping设计
三.总结

一.前言

1.1 在哪些业务场景里使用

一般在具体应用场景中常见的是,营销的一些活动投放以及面向 C 端平台首页.店铺首页的展示的类目下的商品.具体的场景如下:

场景1:解决 C 端应用(App,小程序)营销活动投放.如下某东的首页营销活动 ICON

场景2::解决 App 平台首页或者 App 中店铺首页的前台类目下的商品投放.如下某东的店铺首页商品池

店铺首页

平台首页 ICON /二级活动页.如下某宝的活动页商品池

场景3:解决线下快捷收银的 POS 端线下快捷收银场景

1.2 一些名词搞懂他

有了上面的一些场景我们再来结合下面的一些名词解释,相对来说理解起来会更加有立体感一些.不然就和九年义务教育里的语文一样,就是生硬的灌输,没有了场景,没有了画面就显得很没有体验.

商品池:
一个商家或者电商平台所销售的所有商品的集合。在一个商品池中，可以包括各种不同类型的商品，例如服装、家电、食品等。商家可以根据消费者的需求和市场趋势来选择合适的商品放入商品池中进行销售。商品池的管理和优化可以帮助商家提高销售效果，增加收入。
如上的场景中,我们通过营销活动以及 POS 收银常卖的一些商品.
前台类目:
是指在电商平台或者线下店铺中，用于展示和分类商品的一级、二级或更多级别的分类目录。前台类目的设置对于消费者的购物体验和商品搜索非常重要，能够帮助消费者快速找到自己所需的商品。在电商平台中，前台类目一般会按照商品的类型、品牌、功能等进行划分，例如服装类目可以分为男装、女装、童装等子类目。商家需要根据自己所售商品的特点和市场需求，合理设置前台类目以便于消费者的浏览和购买。
后台类目:
是指电商平台或者线下店铺中，用于管理和组织商品的分类目录。与前台类目不同，后台类目通常是商家自己设定和管理的，用于方便商品的库存管理、订单处理和统计分析等后台操作。后台类目可以根据商家自身的需求和商品特点进行设置，例如按照商品类型、品牌、价格等进行分类。在后台类目中，商家可以对商品进行归类、标签管理、库存调整等操作，以便于更好地管理和营销商品。后台类目的设置与管理对于商家的运营和管理非常重要，能够提高工作效率和订单处理的准确性。

1.3 结合业务思考一下-业务or产品的意图

一点思考:程序员对于产品思考的必要性:

不管你是长时间的技术思维和习惯与代码沟通的情况下,还是沉浸在 CRUD 的海洋里不能自已.那么个人觉得还是有必要多多少少了解一些业务和产品的思维,至少在目前的国内互联网环境下,业务和技术,项目管理结合的复合型人才目前还是比较稀缺的.那后面尽量还是去会去在这些点上多一些思考,前期没有感觉,至少先把这些产品的一些专业用语混个脸熟,别到时候产品开讲,咱也是听过的.与君共勉.

回来这里

通过聚合商品池为 App 端页面提供商品投放服务，包括活动落地页的商品楼层、前台分类页的商品楼层、以及线下场景的下 POS 端收银得快捷收银场景. 并以此为场来通过数据反馈建设需求侧和供给的循环,增加 CTR (点击率) 甚至 GMV (交易额).

从以上的分析来看,基本是整体的商品池的业务定位是用于线上营销,活动,线下这块用于快捷支付收银的场景.基本上是一些商家的一些热点商品,那么对于以上的这些业务场景:

q1:对于既存在线上C端售卖场景又存在线下的收银场景,我们如何去利用这样一套技术解决方案来去解决呢 ?
q2:详细一点具体的模型层面我们该怎么去设计 ?
q3:对于 toC 侧我们能不能有好的性能 ?

带着这些问题我们继续往下看.

二.方案设计

2.1 业务主流程

B 端能力:通过配置来支持商品池的管理.目前的主要是两个维度.自定义的维度.固定规则维度.

C 端:主要分为两个场. 小程序或 app 端的的商品池.线下 POS 收银场景的快捷收银.

2.2 一步步带你分析B端如何配置

回忆下问题q1:

对于既存在线上C端售卖场景又存在线下的收银场景,我们如何去利用这样一套技术解决方案来去解决呢 ?

那实际的业务过程中会出现这样的场景单一的某个租户在平台开设门店存在多个,多个的店铺场景下,对于 C 端小程序或者 app 端的展示类目树同样存在复用前台类目树展示的场景.基于这个场景分析得到前台类目树是店铺是存在和前台类目的关联场景的.

从上面我们知道店铺和前台类目存在 n:n 的关联关系.接着分析从以上的表述我们知道实际业务过程中存在一套前台类目(一组稳定的前台类目树)既存在店铺 A ,也存在店铺 B 的场景中. 为了应对这种场景也便于后端的配置端的操作便捷性.在原来的基础上延伸出一个模板的概念.

前台类目模版:一套稳定的前台类目树集合.

同时由 场景3 可知,某个店铺 A 是既存在线上场景也存在线下的收银场景,对于数据层面这时候我们其实是同一个店铺 ID ,那就需要解决店铺 A 同时关联两套前台类目树的场景所以在上面的前台类目模版基础上通过新增场景的概念来表达线上,线下的两种场景.延伸之后的关联如下.

基于店铺维度的配置诉求以及线上线下的业务背景,我们通过延伸出模版的概念来做到店铺和前台类目模型的解耦.以此店铺维度的关联关系绑定都存在于模版维度,以及前台类目的维护的不需要关心了.这不就是我们想要的吗?

B端配置详细用例

配置前台类目模版

配置前台类目

配置前台类目下的商品池

2.3 数据流

2.3.1 ES 数据表建设

如上在整体构建商品池服务过程中,本身是基于一些规则来实现商品池的圈定.如类目(后台类目)规则,促销等规则来实现商品的召回.在整体商品池建设前期去构建了一个ES数据大宽表建设.具体的过程

step1:监听商品,库存,促销,数据中心的 binlog
step2:通过 binlog 工具,如 Canal databus DTS 等.解析 binlog 后实现 binlog 到 mq 的转换.
step3:通过消费 mq 完成数据到 ES data 的转换,实现宽表建设.

2.3.2 核心商品池流程

2.3.2.1 商品池B端维护流程

整体流程的核心在于规则到商品池的形成的转换.
规则这里目前可以支持后台类目的抓取.如:圈定后台类目为 酒水饮料 的三级类目为一个商品池.

step1:通过三级类目反查得到整颗酒水饮料所在的类目树.如:零食,水,酒水饮料
step2:在后端接口处理的过程中,由于圈定商品池的时间并不可预测,创建的动作是异步来进行的.
step3:创建成功仅仅表达的是后台该商品池规则的创建成功.创建规则成功的同时将发送 mq 消息.
step4:最终的商品池创建过程中会依赖 mq 消息的消费来实现商品池创建.消费 mq ,调用 searchService 来实现商品池圈定.

这里涉及到一个问题,后台类目这个规则是一个固定规则,这块的逻辑是存在于商品领域.同时会存在后台类目下商品新增的场景,这个过程同时需要做到对于商品池的动态更新.那么整个更新过程同时也会涉及到商品主档新增的逻辑处理.那么在整个处理过程中会有一个商品池的刷新,同样有这个问题的场景还有诸如店品的上下架.
目前是这样的一个设计.

2.3.2.2 商品池版本更新逻辑

如上我们通过版本号的逻辑来保证商品池更新的时候既有版本 preVersion 商品池数据仍能够正常展示.在依赖的逻辑事件发生后通过新增的版本号来执行具体的商品池全新版本 newVersion 的落库,最终通过监听商品池数据库来进行商品池 es 表的更新.

这样一来保证了 c 端的正常查询,同时 问题3 的性能问题也可以通过 es 的查询能力做到支持.基本是满足使用.

2.4 核心代码设计

目前支持的规则有

主档类目更新规则
门店商品更新规则
门店状态变更规则

后续还可能新增促销变更等规则,为了在代码层面尽可能支持灵活扩展.以及核心逻辑不变更.通过抽离规则接口的形式来实现规则可更加灵活的变更.比较生硬,还是直接看图.

1.通过实现 applicationContextAware 扩展点来动态获取 spring 容器上下文中所有实现 ZoneRuleAnalyse 接口的
实现类。
2.在进行更新或初始化商品池时通过持有 List 来实现所有规则的读取。后续在新增规则的场景
时能够通过继续实现ZoneRuleAnalyse 来做到，核心流程 ProductZoneInitiator 的稳定，仅需要适配接口的规则读取即可。