基於電商中臺架構-商品系統設計(一)

時間 2019-11-16

標籤基於中臺架構商品系統設計欄目系統架構简体版

原文原文鏈接

1、整體設計

爲何採用中臺架構前幾篇已經說明了，這裏就介紹一下基礎層和平臺層的功能。前端

1. 基礎層

發佈、編輯、上架、下架這些功能你們應該比較熟悉。數據庫

審覈：是否須要審覈經過才容許上架後端

打標：對商品進行標記，例如參加某種活動緩存

Sku管理：商品和sku關係bash

關聯關係：先後端商品關聯關係、組合商品關聯關係等架構

先後端商品：前端商品面向用戶，後端商品面向倉庫併發

類目：商品類目，先後端類目框架

屬性：商品屬性、類目屬性等等性能

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. 商品銷量統計&排序

銷量其實不是做爲商品自己的一個屬性，由於銷量是根據交易訂單成交量來動態計算出來的，可是通常電商網站都會有根據銷量排序的需求，那這個怎麼實現呢。確定是搜索引擎來作，由於搜索條件太多，排序條件太多，數據庫索引也支持不了各類組合查詢、排序。因此咱們就根據業務需求，通常銷量一天統計一次就知足需求了。在商品索引中添加一個銷量字段，天天定時任務從訂單裏面統計銷量，而後再以消息的方式，推送到搜索引擎，搜索排序的時候搜索引擎就能幫咱們實現這個功能。