商城计价中心 - 从容应对复杂场景价格计算
一、背景
隨著vivo商城的業務架構不斷升級，整個商城較為復雜多變的營銷玩法被拆分到獨立的促銷系統中。
拆分后的促銷系統初期只是負責了營銷活動玩法的維護，促銷中最為重要的計價業務仍然遺留在商城主站業務中，且由于歷史建設問題，商城核心交易鏈路中商詳頁、購物車、下單這三塊關于計價邏輯是分開獨立維護的，沒有統一，顯然隨著促銷優惠的增加或者玩法的變動，商城側業務重復開發量會顯著加大。
促銷系統的獨立，計價相關業務能力從業務邊界上也應由促銷系統提供，因此促銷側需要從頭開始設計促銷計價相關能力。
二、原有計價業務
2.1 計價業務場景
商城原有涉及到計價業務的主要是商詳頁、購物車、確認下單、提交訂單這幾個業務場景。
如果將每一個影響最終售賣價的優惠叫做計價因子的話，那前述幾種場景下對于售賣價有影響的計價因子歸為三大類：
-
優惠活動（單品優惠、訂單優惠）
-
優惠券（優惠券、代金券）
-
虛擬抵扣（積分、換新鼓勵金）
對于每種計價場景與計價因子有如下關系：
2.2?原有計價模型
對于具體執行的計價業務中各計價因子間是有一定的先后優先級關系的，綜合如下圖所示，也在一定程度說明了原有計價業務模型：
三、促銷計價模型
3.1 分層模型
促銷系統從零搭建基礎計價能力，對于系統的穩定性及擴展性必須有一定的保障，而這也就對于促銷系統的計價模型提出了一定的要求，通用的基礎計價模型最好是能有過一定的實踐經歷驗證過的，因此我們采用了傳統電商久經考驗的計價模型：分層計價。
所謂的分層計價即傳統電商中優惠涉及的三個層面：商品級、店鋪級、平臺級，正常情況下不同級別的優惠默認是可以疊加的，同一級別的優惠默認情況下是互斥的。
這里需要說明的是，每一層級的優惠計算的時候，對于有些優惠的門檻條件是否滿足需要依賴原價，默認情況下依賴于上一個層級的優惠計算后的價格，即商品級優惠計算依賴商品原價，店鋪級優惠依賴于商品級優惠計算后的價格，平臺級優惠依賴于店鋪級優惠計算后的價格。
疊加規則特別說明：
正常優惠疊加是指兩個優惠可以同時享受，對于不同層級的優惠默認就是疊加的，對于同一層級的優惠默認是不疊加的，比如正常情況下，優惠券下的各種類型券是只能用一張的。
但某些場景下，業務上會指定同一層級的優惠可以疊加使用的，同時指定疊加使用的場景下還會分為普通疊加和并行疊加，舉個例子：訂單優惠和優惠券這兩個類型的疊加就屬于普通疊加（優惠券門檻是否滿足的判斷取決于訂單優惠后的價格），優惠券和代金券的疊加屬于并行疊加（優惠券和代金券的門檻是否滿足的判斷都取決于這兩者的前序優惠后的價格）。
對于同一層級的優惠按不同維度分為：必選/勾選、可疊加(并行疊加/普通疊加)/不可疊加 。
3.2 新的計價模型
3.3 核心計價流程
3.3.1 主流程
通過前述計價模型可以得知，在計算優惠價時的先后順序是：商品級(CalcItem)、店鋪級(CalcShop)、平臺級(CalcGroup)，另外根據一些特殊業務場景，增加了可能的中斷業務邏輯(CalcInterrupt)，因此可得到下圖所示的最粗粒度的計價流程
那這三個級別的計算優惠價內部又是如何實現的呢？經過業務抽象，這三個級別的計算可以變成一個通用的計算優惠邏輯，僅有優惠級別的區分。
3.3.2 通用流程
經過業務抽象發現三個級別的優惠計算的通用邏輯：
-
獲取當前層級的優惠查詢器
（Get Current Level PromotionGetter）
-
過濾優惠查詢器
（Filter PromotionGetter）
-
查詢優惠（Get Promotion）
-
過濾優惠（Filter Promotion）
-
通過計價引擎計算優惠（Calc Engine）
-
過濾計價結果（Filter CalcResult）
因此我們得出如下的通用的計價流程：
通用計價流程中的又有幾個相對靈活的與業務相關過濾邏輯，從后面的細節流程中可以了解更多的實現。
3.3.3?細節流程
之所以在通用計價流程中會有幾個過濾節點，是因為在業務上會有一些特殊的過濾邏輯，比如商詳頁來源的時候，只能使用商品級優惠查詢器，某個優惠只能特殊渠道去享受等等。
所以需要抽象出一個通用的可擴展的過濾機制來實現業務需求，因此會按照不同維度去定制一些鏈式過濾器，執行流程如下圖所示：
當然圖中所示的不同維度額過濾器只是目前業務中的一部分，比如還有按照終端、付款方式、外部業務方等等，這些在具體實現的時候可以非常靈活的支持。
那上述過濾器是如何制定？以及與業務如何關聯的？
上圖中列出部分業務定制過濾序器，自定義過濾器后會自動注冊到統一的優惠業務過濾器工廠中，在前述的計價流程中，需要用到相關過濾器時，只需帶上相關上下文參數可以自動從過濾器工廠中獲取匹配的過濾器。
3.3.4 完整全流程
把前面這一系列流程中進行一個組合拼裝，就可以得到計價的完整全流程圖，如下：
從這個完整流程圖中，可以看到一個通用穩定的核心計價流程以及一個支持業務多變的定制過濾器，既保證了核心的穩定，又保留靈活的擴展。
四、系統核心設計
在通用的計價執行流程中一個節點是「Calc Engine」，也就是計價引擎，這是整個計價邏輯中最核心底層的能力，由它來判定每個優惠是否能被用戶享有。
4.1 統一優惠模型
由于計價中心在建設的時候，已經存在了促銷系統中的各個優惠活動、獨立的優惠券及代金券、遺留在商城主站的未遷移的優惠，因此想用兼容這么多的優惠類型，必然需要建立一個統一的優惠模型，而在建設過程中需將現有的優惠模型進行適配轉換至統一模型。
統一優惠模型中的一些關鍵信息有：優惠標識、優惠類型、優惠模板id、開始結束時間、優惠參數及一些擴展參數等。
4.2 優惠模板
1）在進行促銷計價時，每個具體的優惠都會對應一個唯一的優惠模板，每個優惠模板本質上是一個JSON字符串，只是這些JSON字符串是由遵循了一定特殊邏輯規則的元信息數據轉化而成，而這些元信息在被計價引擎解釋執行時，都是返回布爾類型標識是否通過。
2）基本的元信息數據有這幾種：
AndMeta(與）
對應邏輯關系中的“與”關系，表示該類型的元信息所包含的子元信息解釋執行都返回真才為真；
OrMeta(或）
對應邏輯關系中的“或“關系，表示該類型的元信息所包含的子元信息任一解釋執行返回真就為真；
NotMeta(非）
對應邏輯關系中的“非”關系，表示該類型中元信息所包含的子元信息解釋為假當前元信息為真；
ConditionalMeta(條件）
如果條件參數不存在或者從上下文獲取參數指定的布爾值不為true，則當前元信息返回真，否則根據元信息中包含的子元信息解釋執行的結果作為當前元信息執行結果；
ComplexMeta(組合元信息）
該元信息作為所有模板的通用載體，該元信息中包含兩個重要信息conditon、action，兩者的關系是只有condition條件都滿足后后，才會去執行后續的action，而condition和action都可能為前述中的各種元信息的復雜組合。
3）模板元信息關系：
4）優惠模板示例：
（滑動查看）
4.3 計價引擎
計價引擎本質上就是對應優惠模板的解釋執行，并配合相關上下文，進行優惠計算，關鍵代碼如下：
（滑動查看）
五、小結
通過前面幾章內容的描述，我們基本把vivo商城促銷系統建設計價中心的關鍵思路闡述完了。建設完計價中心后，整個促銷系統的核心基礎才立住，但這也只是個開始，整個商城圍繞著促銷計價中心仍然還有其他待建設的內容，比如整個商城的營銷價格能力矩陣，價格監控，商城時光機等等，而這些內容我們后續有機會也會陸續輸出相關文章，與大家一起交流學習。
總結
以上是生活随笔為你收集整理的商城计价中心 - 从容应对复杂场景价格计算的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring Cloud原理详解
- 下一篇： 150面试题