(馬蜂窩技術原創內容，公眾號 ID: mfwtech)
引言
消費者的狂歡節「雙 11」剛剛過去，在電商競爭環境日益激烈的今天，為了抓住流量紅利，雙 11 打響的已經不僅僅是「促銷戰」，也是「營銷戰」，這對平臺的技術支撐能力提出新的要求，
從 2014 年的「318 大促」，到正在進行的 「馬蜂窩雙 11 全球旅行蜂搶節」，馬蜂窩旅游電商業務的大促已經走過 5 年時間，僅僅是雙 11、暑期、十一黃金周、年終這些關鍵節點的 S 級促銷就張羅了 50 多場，每年上線活動達幾百個，
圖：馬蜂窩11.11全球旅行蜂搶節
在這個程序中，馬蜂窩營銷平臺也在經歷著優化和改進，不斷探索靈活高效的營銷活動運營開發方式，更好地支撐業務營銷活動的模式創新和投放需求，努力實作平臺商家與馬蜂窩旅游消費者的高效匹配，目前已經形成了一套較為完整的技術體系，
本文將以馬蜂窩營銷活動后臺的技術實踐為重點，分享馬蜂窩營銷平臺的架構設計思路，希望能讓遇到類似問題的同學有所識訓，
一、馬蜂窩營銷平臺架構
1. 營銷中心體系
談到大促，大家可能首先會想到的海量資料、高并發、高流量等關鍵詞，其實除了這些，營銷活動數量多、周期短、功能復雜多變等，都是營銷活動運營開發需要應對的挑戰，并且由于我們的很多活動會涉及到一些獎勵或權益的下發，對于安全性的要求也很高，
針對以上問題，馬蜂窩營銷系統的技術架構要具備的核心能力包括：
-
打造靈活、高效的活動開發模式
-
提供高可靠、高可用的活動運營支撐
-
保證營銷活動業務的安全運行
因此，我們本著「平臺化、組件化、模塊化」的方法，將營銷體系的架構設計如下：
馬蜂窩整體營銷體系分為 B 端和 C 端兩部分，B 端主要面向商家，幫助商家在馬蜂窩招商平臺進行大促活動的提報以及商品選取；C 端主要是面向馬蜂窩用戶，平臺用戶可以在業務營銷頁面完成活動商品的購買、秒殺、大促紅包贏取等具體的營銷活動參與互動，
2. C 端營銷平臺
C 端營銷平臺的系統架構主要分為主要分為營銷應用層、中間層、投放平臺、搭建平臺四個部分，
-
活動開發平臺：營銷平臺最核心的部分，也是本文重點，包括前端頁面搭建層「魔方」、業務邏輯層「蜂玩樂園」、獎勵規則控制層「獎池」三部分
-
投放平臺：是指營銷活動頁的投放，包括投放策略、運營策略和機制等
-
中間件：負責并發處理、分布式快取和容災限流等等
-
營銷應用：包括馬蜂窩大促營銷、業務營銷、新人禮包等
下面，我們重點介紹營銷搭建平臺的核心部分——活動開發平臺，是如何實作高效、靈活的營銷活動開發模式的，
二、活動開發平臺的實作
2.1 靈活高效的開發模式
通過上圖可以看到，由 MySQL、ElasticSearch、Redis 組成的資料池在底層為活動開發平臺提供支撐，其中 MySQL 為最主要的存盤方案，用于會場搭建配置資料、蜂玩樂園的用戶運行資料、獎池配置資料等的存放，ElasticSearch 是搜索引擎，支持活動頁面商家活動報名與篩選程序，Redis 有 2 種用途：1）活動任務并發鎖；2）獎池的獎品資料存放；3）限流和削峰，
之前我們提到，活動開發的挑戰包括數量多、周期短、功能復雜多變，為了降低開發同學的作業量，提升研發效率，我們將前端和后端組件進行了整合，并封裝成功能模塊對提供服務，形成了目前的魔方、蜂玩樂園、獎池三個子系統，使整體結構更加清晰，每個部分解決的問題和主要功能模塊示意如下：
2.1.1 系統分層
魔方
「魔方」系統希望通過組件、工具的方式完成營銷頁面的搭建，實作統一維護和復用，從而減少前端團隊在活動開發中承載的重復性開發作業，目前為止我們已經在「魔方」中開發了 80 多個組件模塊，例如秒殺模塊、貨架模塊、店鋪模塊、導航模塊、領券模塊、游戲互動模塊等，
現在，小型活動完全可以不用開發人員支持，只需要業務同學操作即可搭建促銷會場上線活動，提升了活動運營效率，也大大解放了前端開發人員，關于「魔方」更多的細節我們會在后續文章單獨介紹，本文不過多展開，
蜂玩樂園
(1) 邏輯功能抽象
營銷活動的核心是創新和吸引力，每次活動開始前，運營同學都會在創意策劃上絞盡腦汁，盡可能創造出與眾不同的新玩法，這些新穎有趣的游戲玩法，可以在微信，App 等渠道引起用戶的好奇心和興趣，為賣場拉新，進而創造更多的交易，
隨著「花樣」的不斷翻新，活動開發的復雜度也在增加，有時甚至讓技術同學應接不暇，也促使我們探索更加高效的開發方式，
我們開始思考在復雜多變的活動玩法下，是否潛藏著一些不變的模式和規則？通過對不同業務活動模式的分析和抽象，我們將活動的流程和用戶的行為進行了一個有趣的類比：
-
首先，開發活動就創建了一個「樂園」
-
我們會根據不同的「規則」去設計每一個「活動」，激發潛在「參與者」的興趣，或建立他們希望贏得獎勵的期待，
-
進入活動后，我們會驗證參與者「身份」，和需要滿足這次活動的「條件」，來確定他是否可以開始，
-
活動開始時，參與者參與一次活動需要發生的行為，就是在完成「任務」
-
完成「任務」后，為參與者發放相應的「權益」或「獎勵」，
這個類比模型在歷屆促銷活動中進行了推演，結果顯示基本是通用的，但完成任務可能伴隨獎勵服務，也可能沒有，由具體業務需求決定，舉個例子，在一場紅包裂變的營銷活動中有一個需求是下紅包雨，用戶可以點擊掉下來的紅包領取相應的紅包獎勵，那么「領取」這個動作就可以視為活動中的一個任務；另一個需求是每當用戶成功邀請一位好友后就可以在任務中心領取一個邀請紅包獎勵，那么我們可以把在任務中心領取邀請紅包也看成一個任務，
這兩個任務有一個共同的特點就是觸發后都有紅包獎勵，只是在第二個場景中的任務，本質上是用戶發起了一個請求，
經過進一步的梳理、規整，我們抽象出了「參與者」、「活動」、「任務」、「獎品」等業務邏輯功能，
(2) 技術實作
蜂玩樂園將每一個業務邏輯功能收歸到一個唯一的入口和統一的體系中，形成獨立的功能組件模塊，如資料請求模塊、自定義資料配置模塊、驗證器模塊 、執行器模塊、獎勵服務模塊等，每個活動的任務開發都可以選擇模塊配置，模塊配置資訊以 yaml. 的格式進行統一管理，這樣的配置具有靈活性、擴展性和可復用性，
在使用的時候決議配置資料，并向組件注冊中心注冊該任務所需要的組件模塊，再按照定義好的順序執行即可，流程如下圖所示：
為大家介紹幾個關鍵模塊的實作，
-
資料請求模塊
資料請求模塊定義了客戶端與服務端約定好的請求引數規則：
request:
-
field: deviceId
rule: required #必填項校驗
method: post
message: deviceId引數錯誤
-
field: sex
rule: in:[0,1] #范圍校驗
method: post
message: 性別范圍錯誤
-
field: phone
rule: regex:/^1[3456789]\d{9}$/ #正則校驗
method: post
message: 手機號格式錯誤
(i) field - 傳入引數的 key
(ii) rule - 校驗該引數的規則，目前我們已經實作了一些常用的規則：
(iii) required - 必傳引數
-
in：驗證所傳引數必須在指定范圍內
-
regex：正則運算式校驗
-
min，max：自定義規則最小和最大長度
-
integer：必須是數字
-
method：定義 GET、POST 請求方式，
(iv) message - 規則驗證失敗回傳的錯誤資訊，這一層會讀取配置模塊中的請求引數模塊配置內容，將內容決議出來，按照所配置的欄位規則做回應的校驗，如校驗通過繼續向下執行，沒有通過則直接回傳規則提示，
-
引數配置模塊
引數配置模塊定義了該任務執行中所需配置的所有靜態資料配置項，營銷活動的特點是多樣性、創新性，所以很難去窮舉各種場景建立一個有針對性的配置中心，因此這里就為每一個任務單獨開辟了一個沒有結構化的小空間，可根據具體場景的特定需求為任務自由配置，使程式代碼里基本不用再寫各種不合理的硬編碼，
params:
stockRedPacket:
amount: 1
stock: 3
stockKey: limit_key
stockField: limit_key_90
timeWindow:
beginTime: "2019-11-06 00:00:00"
endTime: "2019-11-10 23:59:以一個用戶開啟紅包的配置資訊為例：
(i) stockRedPacket 配置了活動設定的固定庫存與固定金額紅包的業務邏輯
-
amount 金額
-
stock 庫存
-
stockKey、stockField 用來加鎖的欄位
(ii) timeWindow 定義了該任務的活動開始和結束時間
-
驗證器模塊
驗證器模塊的功能主要是是對業務或者規則的校驗，它定義了該任務要執行的業務驗證規則，特點是具有單一性、普適性，能提供一種適用于大多數場景的方法，這些驗證規則可以拆解得足夠細，越細則越靈活，得以在不同任務中靈活組裝使用，
validator:
- MCommon_Validator_TimeWindowValidator
- MCommon_Validator_AuthValidator
- MCommon_Validator_LockValidator-
這里使用了活動時間驗證 TimeWindowValidator，不在活動時間內則回傳錯誤提示
-
登陸驗證 AuthValidator，參加活動必須要登錄，前端通過判斷錯誤狀態碼統一跳轉到登陸頁面
-
并發鎖 LockValidator，避免一個用戶同樣的操作多次提交
-
取出所有的驗證器，然后通過反射依次按照順序呼叫，如果其中一個驗證器失敗，則直接回傳錯誤資訊，終止向下執行，
-
執行器模塊
執行器模塊定義了該任務要執行的一些業務邏輯，比如要執行一段寫日志的邏輯，要執行一個異步呼叫的邏輯等，都可以使用此模塊定義一個執行器去執行，
command: MSign_Command
afterCommand: MSign_Command_After
執行器又分為前置 command 和后置 afterComman：
-
如果需要執行獎勵模塊，則先執行前置 command，再執行獎勵邏輯，最后執行后置 afterCommand，最侄訓傳結果
-
如果沒有獎勵，則先執行前置 command，接著執行后置 afterCommand
-
獎勵服務模塊
獎勵服務模塊決定該任務是否需要執行獎勵發放，如果配置了獎勵，任務在執行時會根據獎勵的配置規則下發獎勵，在我們的實際場景中，主要涉及到的獎勵型別包括獎勵機會、紅包、抽獎、優惠券等：
-
獎勵機會：有 2 種規則，分別是按固定頻次給用戶初始化機會數，和獎勵增量機會數，
-
發送紅包：設定固定紅包和隨機紅包，隨機紅包按需求設定發放的概率與用戶群，
-
抽獎：對接獎池系統，下文詳細介紹，
-
優惠券：與馬蜂窩優惠中心直接打通，只需要配置優惠券 SN 和渠道號，即可把優惠券發送到用戶卡券，
獎池
在營銷活動中，許多場景都涉及用戶抽獎或獎品發放，營銷技術平臺因此對獎品發放的整個生命周期進行了抽象和封裝，創建了「獎池」，
(1) 主要功能
獎池的主要功能點包括：
-
創建獎品池：為每次活動創建一個或多個獎品池
-
設定獎品：在單一獎品池中均勻放置獎品
-
用戶抽獎：用戶在單一獎池中抽獎，支持按概率抽獎，支持獎品的發放和領取
-
中獎統計：包括獎品已發放數量，已領取數量，剩余數量
如下圖所示，只需創建好獎池，配置好獎品資訊，把對應的獎池 ID 填寫到任務，即可實作抽獎功能：
(2) 方案設計
獎池早期的設計非常簡單，獎品物體僅定義「余量」的概念，利用關系型資料庫中單行記錄存盤一次活動的獎品、總量、發放量、余量等資料，在用戶流量較小且均勻的情況下，發放程序平穩正常，每次進行獎品發放時，在單行記錄上進行 update 操作，扣減余量并增加發放量即可，
然而隨著公司業務的發展，一次營銷活動帶來的效果讓我們不得不立刻改進獎池方案，這次營銷活動帶來的流量遠超預期，但獎品數量的配置卻一如往常，當活動開啟后，獎品消耗很快，并在一段時間后被提前抽光，為了不影響用戶體驗，營銷運營同學不得不持續向獎池中補充獎品，
經歷這次問題開發同學發現，獎池提前抽光的原因在于設計中忽略了時間分布的因素，使獎品抽光的速度只與訪問量相關，因此，大家開始思考如何讓獎品固定且均勻分布在活動周期內，
通過學習與比較，最終選擇了業界比較通用的方案，使用 Redis 的有序集合（Sorted Set）創建獎池和設定獎品，從而使獎品在活動時間段內均勻分布，防止提前抽光的情況出現，
(3) 實作演算法
1. 時間戳：根據獎品的數量和活動時長，為每 1 份獎品設定一個出獎時間戳，這份獎品僅能在這一時間點及之后被抽出，這一步使出獎時間戳盡量均勻分布在活動時間范圍內，
2. 創建獎品池：為每一組獎品設定一個獎池，在 Redis 創建一個 zset 資料結構，將其中的每 1 份獎品作為 1 個成員（Member），將時間戳作為分值（score），
3. 放置獎品：使用ZADD 獎池 出獎時間戳 1 份獎品 語法，在 Redis 中布置一個獎品，
4. 抽獎：使用 Sorted Set 的排序方法，每次排序后查看排名第一的獎品，比較當前時間戳與獎品時間戳的大小，如果當前時間晚于或等于出獎時間，則使用 ZREM 指令出獎，否則不出，
示意圖如下：
2.1.2 體系統一
為了讓開發同學只專注于任務的設計開發，我們抽象出「賬戶」的概念，每個任務產生的資料資源會存盤在所在的「賬戶」體系下，使其支撐多個類似的活動，這種設計的好處在于：
（1）同一用戶在參與不同的活動時得到的獎勵都是相互獨立的，不會出現混淆的情況，
（2）之前每次活動都需要單獨創建資料表，活動下線后表不能復用，時間長了造成系統占用許多無用的資料表，而把資料庫表以抽象的任務形態創建，不針對具體的某一業務型別，就可以使資料表實作復用，這樣我們只專注任務的設計開發，不用再關心資料表的設計，
在營銷大促的活動中，我們也接入了風控中心、并發鎖和限流服務，以保障整個活動的安全和穩定，
2.2 可用性和可靠性
秒殺模塊是大促流量的最高峰，結合業務實際，我們針對這種場景也做了限流和削峰處理，
限流采用的方案是限制時間窗內最大請求資料，用戶再搶會員權益時，第一步會讀取限流配置 key 和 value，判斷單位時間內是否超過限制的最大請求數 value，如果超過則回傳資訊提示結束請求；如果沒有超過閾值，則進入下一步操作，目前的限流系統只是在應用層面的實作，為了更好地支撐業務發展，后續我們也會接入網關服務，通過 Sentinel 和 Hystrix 做限流熔斷，避免流量進入應用層，提高服務的高可用性，
削峰部分結合實體說明，
以秒殺金卡會員的場景為例，我們會先用 RabbitMQ 承接瞬時的流量洪峰，再平滑地消費所有請求，并提前把庫存數量對應的 Token 寫入 Redis 快取（這里我們針對性的對不同的用戶引入了 Token 機制，以保證我們的秒殺商品在時效和庫存上得以保障），用戶在秒殺時會順序地從 Redis 中 rPop 對應的 Token，避免庫存超賣的情況；用戶拿到 Token 之后再去收銀臺下單開通金卡會員，就可以避免流量同一時刻去下單，
隨著業務和技術的發展，系統的不確定性以及流量的預估都更為困難，我們也在不斷學習業界的先進經驗，來更好地提升系統的可用性和可靠性，目前我們正在調研基于 Noah 的「自適應」限流技術并積極推進，以期針對不同的服務器性能以及當前的流量情況進行針對性的限流控制，相信我們會在后續的優化中會做得更好，
2.3 風險控制
目前是接入公司統一的風控中心，在營銷活動需求確定好后，我們會向風控服務中心提供需要風控的業務場景邏輯，風控中心根據業務配置不同策略，給出不同的場景 key，我們只需要在營銷活動任務中的自定義引數配置模塊配置好風控場景 key，就可在獎勵服務模塊自動呼叫風控介面去校驗用戶，如果識別出是風險用戶則會被攔截，終止活動參與，
可用性和可靠性、風險控制的實作流程如下圖所示：
三、近期規劃
1. 完善監控體系
目前對于活動運行中的資料監控，主要依賴資料組的統計與輸出，線上活動的運行情況并不能通過「蜂玩樂園」與「獎池」系統實時并綜合表現出來，
未來會補齊運行時的活動監控功能，通過活動、任務、獎品的運行時資料指標，指導運營同學第一時間調整活動引數，取得最佳運營效果，
2. 服務化改造
營銷基礎平臺依舊搭建在單體架構上，部分功能的邊界與職責并不完全清晰，接下來營銷技術平臺會進行技術架構的升級與改造，從單體架構轉向微服務架構，使服務能力與開發能效同步提升，
小結
隨著營銷的逐年發展，活動的趣味性和復雜度會一起上升，這需要我們不斷更新對營銷活動的認識，在這程序中也要反復嘗試新的抽象和重構，通過不斷改進現有系統，支持更多和更好玩的營銷活動，讓馬蜂窩用戶玩兒得更省心，玩兒得更省錢，
本文作者：馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/37733.html
標籤：架構設計