每當大促，各大電商、品牌都會為消費者提供各式各樣的活動，各類活動任意組合，將帶來多樣化的價格計算場景。如何滿足業務發展同時，最大化的降低系統計算的複雜度？本文將為你揭祕嚴選商品價格計算背後的祕密。

1. 背景

商品的價格計算是促銷計價系統根據使用者身份、使用者資產、商品享受的活動、優惠券、紅包等計算商品的價格。在交易場景（購物車、結算頁、下單）體現為實際支付價格，在導購場景（商詳、列表）體現為預估價格。

隨著嚴選業務、渠道的不斷擴充套件，活動玩法千變萬化，商品價格計算愈發複雜。原來的價格計算體系已無法快速有效的支撐新增玩法，需進行促銷計價系統的獨立建設，與交易、商城業務解耦。

2. 難點及解決方案

當前嚴選價格計算可歸為3大類：當前的實付價、當前的預估價、某時間段內的預估最低價，需分場景提供實時價格計算能力、實時預估價計算能力、指定時間範圍內模擬價格計算能力。有以下難點：

2.1 難點一：各活動的規則並未統一

目前參與計算的活動由不同業務組維護，短期內規則無法統一。意味對活動規則的解釋過程和計算結果均存差異性。

解決方案：活動計算元件化—— 將單個活動計算過程封裝成一個元件，對元件外黑盒。並對輸入和輸出標準化。

• 計算項（計價輸入）：包含價格、優惠內容、來源、屬性等影響價格變化的內容。
• 單個活動計價輸出：主要包含價格和記錄價格變化過程的快照資訊。

• 全域性上下文：儲存互斥資訊、每個活動計算的過程快照、分組資訊。

2.2 難點二：導購場景的價格計算隨時可能根據營銷策略進行快速調整，對擴充套件性要求極高

如新增一種活動時，參與計算的順序可能位於計算鏈的末端或中間。原優先順序相同的活動，計算順序也可能經常調整。

解決方案有以下兩種：

• 設計好全域性的上下文資訊，計價流程編排採取硬編碼的方式，需改變順序時更改程式碼即可。

• 計價流程可配置：將計算的順序放在檔案中，每次計算時讀取，實現無程式碼改動即可快速調整編排順序。

2.3 難點三：活動優先順序矩陣互斥。

如上圖所示，活動與活動直接可能的優先順序關係複雜：

• 互斥：若商品能參與活動A，則一定不能參與活動B。

• 可配置：商品能參與活動A，能否

  參與活動B，由活動建立人配置。

• 最優價：商品同時能參與優先順序相同的多個活動，選價格最低的

解決方案：

2.4 難點四：交易場景的價格計算屬於核心邏輯，涉及到使用者資產。需最大程度保證計算結果精準度，防止對嚴選和買家造成損失。

解決方案：

• 熱點活動資料採取多級快取。

• 對計算中的易出現資損的過程進行監控和報警。

• 增加場景-元件級別降級機制，保證核心計算鏈路的穩定性。

3. 價格計算引擎的誕生

新的計價服務，需要滿足以下幾個目標：

• 支援快速擴充套件新的營銷玩法；能無感的從原計價流程中移除某個活動。

• 支援快速調整計價順序。

• 效能：導購場景具有極高的RT要求和吞吐量要求，交易場景需保證極高的系統穩定性。

• 最重要的是：提升研發效率、降低迭代過程中的影響輻射面。

3.1 具體實現

我們借鑑了流程類引擎的思想，並結合嚴選活動價格計算的現狀，採用了：元件化、計算流程可配置、可插拔、計算過程場景化的解決方案。包含以下幾個核心的模組：

3.1.1 計價pipeline

• 單個pipeline內計算節點按順序執行；單個計算節點內部，計算單元按順序執行。

• 計算節點內，從多個計算單元的計算結果中選出優先順序最高的，並將非最優的活動計算結果、過程快照從上下文中移除。

• 元件互斥：元件1與元件2互斥——商品真實參與了計算單元1的計算（元件1計算後，價格發生變化），則不再參與計算單元2的計算。

3.1.2 計價泳道處理器

計價泳道是指模擬計算商品某段時間T內的最低價時，需計算出時間T內所有可能出現的價格。因此需模擬可能出現的使用者情況，我們定義每種身份為一個計價泳道。

確定計價泳道後，先獲取該身份在時間T內參與的活動。以下5個活動的在時間T內的有效時間為：

• 活動A：時間區間1；

• 活動B：時間區間1+時間區間2；

• 活動C：時間區間2；

• 活動D：時間區間3；

• 活動E：時間區間1+時間區間2+時間區間3

處理後時間片如上圖所示。

經過計價泳道處理器處理後，某身份下每個時間片內參與活動已確定，剩下的交個計算驅動器。

3.1.3 計價驅動器

實時計算：直接獲取當前能參與的優惠，交給pipeline處理

模擬計算：先根據場景獲取對應的計價泳道，在計算各時間片內的價格（交個pipeline處理）。

3.1.4 配置管理

服務執行中調整活動計算順序並實時生效不是核心問題，外加安全考慮，我們將編排資訊放在json檔案中，應用啟動時會載入某個場景下的配置到引擎中。

以下為某個場景計價pipeline的配置（舉例，不為真實配置）。

[    [        {            "componentType": 1,            "componentName": "限時購計價元件",            "conflictInfo": [                "5"            ]        },        {            "componentType": 2,            "componentName": "特價計價元件"        }    ],    [        {            "componentType": 3,            "componentName": "N元任選計價元件"        }    ],    [        {            "componentType": 4,            "componentName": "全場類滿額減計價元件"        }    ],    [        {            "componentType": 5,            "componentName": "郵費計價元件"        }    ]]

計價元件1和其互斥資訊構成了單個計算單元。計算單元1和計算單元2構成單個計算節點。

商品經過1和2的處理後發生價格變化，那麼只能擇出最優作為該計算節點的輸出。(數字編號代表計算單元)

商品經過了1的處理且發生價格變化，則不參與5的計算。(數字編號代表計算單元)

3.1.5 整體設計

輸入適配層接收引數後，將其轉換成引擎入參後開始引擎計價過程，引擎輸出結果經過結果適配層處理後對外輸出。

4. 總結與展望

• 截止目前，全新的價格計算引擎已為嚴選購物車、組單、下單等交易場景提供商品的計價服務。

• 導購場景: 商詳、列表、推薦等正在接入中。2021年的雙十一，價格計算引擎將支援嚴選主站所有場景的商品價格計算。

• 本文重點介紹價格計算引擎的設計思路。相關的併發設計、快取設計、落地過程中遇到的問題及解決方案會陸續分享。

• 在後續的規劃中，促銷團隊會對活動規則進行重新設計並打造符合嚴選活動特色的規則引擎，進一步完善嚴選促銷技術體系。