基于电商中台架构-商品系统设计(一)

1、整体设计

为何采用中台架构前几篇已经说明了，这里就介绍一下基础层和平台层的功能。

1. 基础层

发布、编辑、上架、下架这些功能你们应该比较熟悉。

审核：是否须要审核经过才容许上架

打标：对商品进行标记，例如参加某种活动

Sku管理：商品和sku关系

关联关系：先后端商品关联关系、组合商品关联关系等

先后端商品：前端商品面向用户，后端商品面向仓库

类目：商品类目，先后端类目

属性：商品属性、类目属性等等

2. 平台层

商品管理：商品的基本操做

商品收藏：管理用户收藏的商品

商品快照：保存商品编辑的每个快照版本

活动打标：根据不一样的活动映射到商品属性上不一样标记

销量管理：商品的销量统计、以及排序操做

浏览历史：用户浏览记录

搜索：不一样维度对商品的搜索

2、概念定义

1. Item-sku

Item表明产品 sku表明商品

举例：item对应苹果7手机 但苹果7有黑色、白色 则sku对应黑色的苹果7手机

对应关系以下：

2. 先后端商品

前端商品：面向用户的，在商城展现销售的，它是一个虚拟的概念。

后端商品：面向仓库实体商品的，好比一台电脑就建立一个后端商品。它和仓库有着紧密的关系，同步库存，入库出库等操做都要同步到该商品信息。

前端商品和后端商品有个映射关系，好比前端商品为电脑，则后端商品会对应一个电脑。

后端组合商品：有些商品是能够单个售卖，也能够打包售卖，好比电脑套装优惠，这个套装就是一个组合商品A，他是由电脑B、鼠标C、键盘D组成。

因此这里就有一个映射关系A->(1B,1C,1D)。此时若是须要在商城售卖，则能够建立一个前端商品和A进行关联。

3. 关联关系

这里关联关系就包括：前端商品和后端商品的映射关系、后端组合商品和单个商品的关系。根据这个关系能够肯定该商品在哪些仓库有库存、该发货几个等等。

4. 商品快照

商品每次编辑都会保存一份快照，一来能够记录操做日志，二来能够追溯，好比订单会存一个快照商品版本，根据该版本找到下单当时的商品信息。

5. 商品打标

打标其实就是一个标记，好比一个商品参加的十几个活动，那么怎么在商品上保存，咱们可使用一个long型字段flag来保存，long是64位，每一位表明一种类型的活动，0表明否，1表明是，经过对flag进行二进制操做便可完成活动信息更新。

6. 类目

类目也分为先后端类目，前端类目就是面向用户，具备导航功能，并且易变。

后端类目是和商品直接关联，很稳定。先后端类目有映射关系。

7. 属性

商品关联的属性，举例：黑色苹果7手机，他具备属性为颜色，属性值为黑色。

3、技术设计

1. 关系图

2. 商品关键字段介绍

商品表都是基于分库分表的设计。

category_id：商品和类目是一对一的关系，建立商品的时候须要首先获取到商品所属类目。判断该类目下商品发布是否须要审核，以及商品必需要填充该类目下关联的属性并保存到商品上。

item_pattern：商品形态：包括实物商品、虚拟商品、服务商品，为何要有这个字段，由于实物商品须要关联仓库实物商品；虚拟商品不须要关联，好比电子书、视频等等；服务商品做为另一种特殊处理方式，好比三年保修、送货上门等都是做为一种服务，咱们把它抽象成服务商品，在下单时一同加入订单中，这样作的好处在于易于扩展。

item_type：商品类型：包括前端商品和后端商品；或者组合商品，或者扩展的商品类型。

shop_id：归属的店铺

selle_id+item_code：商家id和商家编码，若是是商家本身erp系统导入的商品，则这两个字段是惟一的，能惟一肯定商家系统的商品。

flag：标记位，进行二进制打标操做。

biz_type：所属业务平台，根据该字段进行不一样业务间的数据隔离。

feature：扩展字段，将商品属性存在里面，也可存储将来新加的信息而无需改表结构。

3. 商品历史表Item_history设计

历史表就是已经删除了的商品数据表，那为何要把删除的数据保存下来，这就是电商系统的设计原则，任何表的数据只逻辑删除，不进行物理删除。因此不少表都会加上is_delete字段标记是否被删除。

可是商品表为何要新建一张表，这里有两点，1)商品表中有惟一键约束，(seller_id,item_code)，若是删除了放在原表，商家再次同步该商品时，由于这两个字段相同，会影响惟一键约束，但又不能真正删除，因此就将数据移至历史表。2)商品表数据日积月累会愈来愈庞大，将删除的数据迁出有利于提升原表的性能。

4. 商品快照设计

商品做为电商交易中的对象，对其任何的改动都相当重要，因此存储快照一方面是把每次的更改记录都保存下来。另外一方面是存在相似于交易订单的场景，须要当时商品的信息，以便处理投诉、维权。

那么快照数据更加庞大，由于每一次的改动都会生成一份数据，因此不能存在数据库，而是采用外部存储。查询的时候须要itemId+snapshotVersion，商品id和快照版本进行查询。

5. 商品打标设计

首先定义一个活动类型枚举类，说明每一位表明什么活动。其余类型也能够，反正就是标记该商品具备某种属性。

假如flag=0；如今商品参加某个活动，flag第三位表明该活动，则打标过程为；

flag=flag | (1 << 2)
复制代码

去标一样的逻辑。

6. 商品扩展字段设计

不只是商品表，在工做中咱们会常常遇到，在需求不断迭代的过程当中，确定会有添加字段的需求，但若是咱们添加的字段都不是关键字段的话（不用于检索），好比商品表若是后端商品如今须要存储长宽高、质量、以及一些产地等信息，咱们就能够经过扩展字段的方式解决，并且还免去了对线上表加列的操做。扩展字段feature其实就是Json格式的字符串，预留必定长度，待后面有需求在往里面加键值对。

好比说加以前是这样存的：

{“length”:10,“width”:12,”height”:20}复制代码

加了产地后就变为

{“length”:10,“width”:12,”height”:20,”region”:”HZ”}
复制代码

但更新的时候必定注意要带版本更新，不然并发状况将会发生数据覆盖。这也是另一个设计原则，数据库全部表都要加version字段的缘由：数据更新乐观锁控制。

7. 商品销量统计&排序

销量其实不是做为商品自己的一个属性，由于销量是根据交易订单成交量来动态计算出来的，可是通常电商网站都会有根据销量排序的需求，那这个怎么实现呢。确定是搜索引擎来作，由于搜索条件太多，排序条件太多，数据库索引也支持不了各类组合查询、排序。因此咱们就根据业务需求，通常销量一天统计一次就知足需求了。在商品索引中添加一个销量字段，天天定时任务从订单里面统计销量，而后再以消息的方式，推送到搜索引擎，搜索排序的时候搜索引擎就能帮咱们实现这个功能。

8. 商品类目设计

类目设计将在后续文章详细介绍。包括前台类目、后台类目、类目树构建、类目缓存设计、类目属性等等。

9. 商品搜索设计

搜索设计将在后续文章详细介绍。搜索设计包括搜索引擎选型、存储结构设计、索引构建、搜索、以及通用搜索框架等等。

4、总结

本文介绍了商品系统分层设计，以及每一层对应的功能和功能设计。后续还会对商品系统中设计要点、细节进行详细介绍，好比类目、搜索。此外，在实现中还涉及了许多中间件的封装使用，因此后续还会对通用组件（通用搜索框架、消息框架）进行介绍。

更多文章欢迎访问 http://www.apexyun.com/

公众号:银河系1号

联系邮箱：public@space-explore.com

(未经赞成，请勿转载)