一、背景

隨著vivo商城的業(yè)務架構不斷升級，整個商城較為復雜多變的營銷玩法被拆分到獨立的促銷系統(tǒng)中。

拆分后的促銷系統(tǒng)初期只是負責了營銷活動玩法的維護，促銷中最為重要的計價業(yè)務仍然遺留在商城主站業(yè)務中，且由于歷史建設問題，商城核心交易鏈路中商詳頁、購物車、下單這三塊關于計價邏輯是分開獨立維護的，沒有統(tǒng)一，顯然隨著促銷優(yōu)惠的增加或者玩法的變動，商城側業(yè)務重復開發(fā)量會顯著加大。

促銷系統(tǒng)的獨立，計價相關業(yè)務能力從業(yè)務邊界上也應由促銷系統(tǒng)提供，因此促銷側需要從頭開始設計促銷計價相關能力。

二、原有計價業(yè)務

2.1 計價業(yè)務場景

商城原有涉及到計價業(yè)務的主要是商詳頁、購物車、確認下單、提交訂單這幾個業(yè)務場景。

如果將每一個影響最終售賣價的優(yōu)惠叫做計價因子的話，那前述幾種場景下對于售賣價有影響的計價因子歸為三大類：

• 優(yōu)惠活動（單品優(yōu)惠、訂單優(yōu)惠）

• 優(yōu)惠券（優(yōu)惠券、代金券）

• 虛擬抵扣（積分、換新鼓勵金）

對于每種計價場景與計價因子有如下關系：

2.2?原有計價模型

對于具體執(zhí)行的計價業(yè)務中各計價因子間是有一定的先后優(yōu)先級關系的，綜合如下圖所示，也在一定程度說明了原有計價業(yè)務模型：

三、促銷計價模型

3.1 分層模型

促銷系統(tǒng)從零搭建基礎計價能力，對于系統(tǒng)的穩(wěn)定性及擴展性必須有一定的保障，而這也就對于促銷系統(tǒng)的計價模型提出了一定的要求，通用的基礎計價模型最好是能有過一定的實踐經(jīng)歷驗證過的，因此我們采用了傳統(tǒng)電商久經(jīng)考驗的計價模型：分層計價。

所謂的分層計價即傳統(tǒng)電商中優(yōu)惠涉及的三個層面：商品級、店鋪級、平臺級，正常情況下不同級別的優(yōu)惠默認是可以疊加的，同一級別的優(yōu)惠默認情況下是互斥的。

這里需要說明的是，每一層級的優(yōu)惠計算的時候，對于有些優(yōu)惠的門檻條件是否滿足需要依賴原價，默認情況下依賴于上一個層級的優(yōu)惠計算后的價格，即商品級優(yōu)惠計算依賴商品原價，店鋪級優(yōu)惠依賴于商品級優(yōu)惠計算后的價格，平臺級優(yōu)惠依賴于店鋪級優(yōu)惠計算后的價格。

疊加規(guī)則特別說明：

正常優(yōu)惠疊加是指兩個優(yōu)惠可以同時享受，對于不同層級的優(yōu)惠默認就是疊加的，對于同一層級的優(yōu)惠默認是不疊加的，比如正常情況下，優(yōu)惠券下的各種類型券是只能用一張的。

但某些場景下，業(yè)務上會指定同一層級的優(yōu)惠可以疊加使用的，同時指定疊加使用的場景下還會分為普通疊加和并行疊加，舉個例子：訂單優(yōu)惠和優(yōu)惠券這兩個類型的疊加就屬于普通疊加（優(yōu)惠券門檻是否滿足的判斷取決于訂單優(yōu)惠后的價格），優(yōu)惠券和代金券的疊加屬于并行疊加（優(yōu)惠券和代金券的門檻是否滿足的判斷都取決于這兩者的前序優(yōu)惠后的價格）。

對于同一層級的優(yōu)惠按不同維度分為：必選/勾選、可疊加(并行疊加/普通疊加)/不可疊加 。

3.2 新的計價模型

3.3 核心計價流程

3.3.1 主流程

通過前述計價模型可以得知，在計算優(yōu)惠價時的先后順序是：商品級(CalcItem)、店鋪級(CalcShop)、平臺級(CalcGroup)，另外根據(jù)一些特殊業(yè)務場景，增加了可能的中斷業(yè)務邏輯(CalcInterrupt)，因此可得到下圖所示的最粗粒度的計價流程

那這三個級別的計算優(yōu)惠價內(nèi)部又是如何實現(xiàn)的呢？經(jīng)過業(yè)務抽象，這三個級別的計算可以變成一個通用的計算優(yōu)惠邏輯，僅有優(yōu)惠級別的區(qū)分。

3.3.2 通用流程

經(jīng)過業(yè)務抽象發(fā)現(xiàn)三個級別的優(yōu)惠計算的通用邏輯：

• 獲取當前層級的優(yōu)惠查詢器

  （Get Current Level PromotionGetter）

• 過濾優(yōu)惠查詢器

  （Filter PromotionGetter）

• 查詢優(yōu)惠（Get Promotion）

• 過濾優(yōu)惠（Filter Promotion）

• 通過計價引擎計算優(yōu)惠（Calc Engine）

• 過濾計價結果（Filter CalcResult）

因此我們得出如下的通用的計價流程：

通用計價流程中的又有幾個相對靈活的與業(yè)務相關過濾邏輯，從后面的細節(jié)流程中可以了解更多的實現(xiàn)。

3.3.3?細節(jié)流程

之所以在通用計價流程中會有幾個過濾節(jié)點，是因為在業(yè)務上會有一些特殊的過濾邏輯，比如商詳頁來源的時候，只能使用商品級優(yōu)惠查詢器，某個優(yōu)惠只能特殊渠道去享受等等。

所以需要抽象出一個通用的可擴展的過濾機制來實現(xiàn)業(yè)務需求，因此會按照不同維度去定制一些鏈式過濾器，執(zhí)行流程如下圖所示：

當然圖中所示的不同維度額過濾器只是目前業(yè)務中的一部分，比如還有按照終端、付款方式、外部業(yè)務方等等，這些在具體實現(xiàn)的時候可以非常靈活的支持。

那上述過濾器是如何制定？以及與業(yè)務如何關聯(lián)的？

上圖中列出部分業(yè)務定制過濾序器，自定義過濾器后會自動注冊到統(tǒng)一的優(yōu)惠業(yè)務過濾器工廠中，在前述的計價流程中，需要用到相關過濾器時，只需帶上相關上下文參數(shù)可以自動從過濾器工廠中獲取匹配的過濾器。

3.3.4 完整全流程

把前面這一系列流程中進行一個組合拼裝，就可以得到計價的完整全流程圖，如下：

從這個完整流程圖中，可以看到一個通用穩(wěn)定的核心計價流程以及一個支持業(yè)務多變的定制過濾器，既保證了核心的穩(wěn)定，又保留靈活的擴展。

四、系統(tǒng)核心設計

在通用的計價執(zhí)行流程中一個節(jié)點是「Calc Engine」，也就是計價引擎，這是整個計價邏輯中最核心底層的能力，由它來判定每個優(yōu)惠是否能被用戶享有。

4.1 統(tǒng)一優(yōu)惠模型

由于計價中心在建設的時候，已經(jīng)存在了促銷系統(tǒng)中的各個優(yōu)惠活動、獨立的優(yōu)惠券及代金券、遺留在商城主站的未遷移的優(yōu)惠，因此想用兼容這么多的優(yōu)惠類型，必然需要建立一個統(tǒng)一的優(yōu)惠模型，而在建設過程中需將現(xiàn)有的優(yōu)惠模型進行適配轉換至統(tǒng)一模型。

統(tǒng)一優(yōu)惠模型中的一些關鍵信息有：優(yōu)惠標識、優(yōu)惠類型、優(yōu)惠模板id、開始結束時間、優(yōu)惠參數(shù)及一些擴展參數(shù)等。

4.2 優(yōu)惠模板

1）在進行促銷計價時，每個具體的優(yōu)惠都會對應一個唯一的優(yōu)惠模板，每個優(yōu)惠模板本質(zhì)上是一個JSON字符串，只是這些JSON字符串是由遵循了一定特殊邏輯規(guī)則的元信息數(shù)據(jù)轉化而成，而這些元信息在被計價引擎解釋執(zhí)行時，都是返回布爾類型標識是否通過。

2）基本的元信息數(shù)據(jù)有這幾種：

AndMeta(與）

對應邏輯關系中的“與”關系，表示該類型的元信息所包含的子元信息解釋執(zhí)行都返回真才為真；

OrMeta(或）

對應邏輯關系中的“或“關系，表示該類型的元信息所包含的子元信息任一解釋執(zhí)行返回真就為真；

NotMeta(非）

對應邏輯關系中的“非”關系，表示該類型中元信息所包含的子元信息解釋為假當前元信息為真；

ConditionalMeta(條件）

如果條件參數(shù)不存在或者從上下文獲取參數(shù)指定的布爾值不為true，則當前元信息返回真，否則根據(jù)元信息中包含的子元信息解釋執(zhí)行的結果作為當前元信息執(zhí)行結果；

ComplexMeta(組合元信息）

該元信息作為所有模板的通用載體，該元信息中包含兩個重要信息conditon、action，兩者的關系是只有condition條件都滿足后后，才會去執(zhí)行后續(xù)的action，而condition和action都可能為前述中的各種元信息的復雜組合。

3）模板元信息關系：

4）優(yōu)惠模板示例：

{ "type": "COMPLEX", "condition": { "type": "AND", "metas": [ { "type": "CONDITIONAL", "metas": [ { "type": "CONDITION", "metaCode": "terminalCheckCondition" } ], "param": "needTerminalCheck" }, { "type": "CONDITION", "metaCode": "amountOverCondition" } ] }, "action": { "type": "AND", "metas": [ { "type": "ACTION", "metaCode": "cutPriceAction" }, { "type": "ACTION", "metaCode": "freezeCouponAction" } ] }}

（滑動查看）

4.3 計價引擎

計價引擎本質(zhì)上就是對應優(yōu)惠模板的解釋執(zhí)行，并配合相關上下文，進行優(yōu)惠計算，關鍵代碼如下：

private boolean executeMeta(Meta meta, EngineContext context) { if (meta instanceof AndMeta) { return executeAndMeta((AndMeta)meta, context); } else if (meta instanceof OrMeta) { return executeOrMeta((OrMeta) meta, context); } else if (meta instanceof NotMeta) { return executeNotMeta((NotMeta)meta, context); } else if (meta instanceof ComplexMeta) { return executeComplexMeta((ComplexMeta)meta, context); } else if (meta instanceof ConditionalMeta) { return executeConditionalMeta((ConditionalMeta)meta, context); } else { return executeIMeta(meta, context); }} ...... private boolean executeComplexMeta(ComplexMeta complexMeta, EngineContext context) { Meta condition = complexMeta.getCondition(); Meta action = complexMeta.getAction(); return executeMeta(condition, context) && executeMeta(action, context);} private boolean executeConditionalMeta(ConditionalMeta conditionalMeta, EngineContext context) { PromotionContext promotionContext = context.getPromotionContext(); if (promotionContext == null || promotionContext.getParameters() == null) { return true; } String conditionParam = conditionalMeta.getParameter(); String sNeedProcess = promotionContext.getParameters().get(conditionParam); if (sNeedProcess == null) { return true; } boolean needProcess = Boolean.parseBoolean(sNeedProcess); if (needProcess) { return executeMeta(conditionalMeta.getMetas().get(0), context); } else { return true; }} private boolean executeIMeta(Meta meta, EngineContext context) { IMeta iMeta = MetaFactory.get(meta.getMetaDef().getMetaCode()); if (iMeta == null) { throw new CalcException("meta not found, metaCode=" + meta.getMetaDef().getMetaCode()); } return iMeta.execute(context);}

（滑動查看）

五、小結

通過前面幾章內(nèi)容的描述，我們基本把vivo商城促銷系統(tǒng)建設計價中心的關鍵思路闡述完了。建設完計價中心后，整個促銷系統(tǒng)的核心基礎才立住，但這也只是個開始，整個商城圍繞著促銷計價中心仍然還有其他待建設的內(nèi)容，比如整個商城的營銷價格能力矩陣，價格監(jiān)控，商城時光機等等，而這些內(nèi)容我們后續(xù)有機會也會陸續(xù)輸出相關文章，與大家一起交流學習。

總結

以上是生活随笔為你收集整理的商城计价中心 - 从容应对复杂场景价格计算的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。