一、總體設計

為什麼採用中臺架構前幾篇已經說明了，這裡就介紹一下基礎層和平臺層的功能。

1. 基礎層

釋出、編輯、上架、下架這些功能大家應該比較熟悉。

稽核：是否需要稽核通過才允許上架

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

Sku管理：商品和sku關係

關聯關係：前後端商品關聯關係、組合商品關聯關係等

前後端商品：前端商品面向使用者，後端商品面向倉庫

類目：商品類目，前後端類目

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

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手機，他具有屬性為顏色，屬性值為黑色。

三、技術設計

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. 商品搜尋設計

搜尋設計將在後續文章詳細介紹。搜尋設計包括搜尋引擎選型、儲存結構設計、索引構建、搜尋、以及通用搜索框架等等。

四、總結

本文介紹了商品系統分層設計，以及每一層對應的功能和功能設計。後續還會對商品系統中設計要點、細節進行詳細介紹，比如類目、搜尋。此外，在實現中還涉及了許多中介軟體的封裝使用，所以後續還會對通用元件（通用搜索框架、訊息框架）進行介紹。

聯絡郵箱：[email protected]

(未經同意，請勿轉載)