支撐馬蜂窩「雙11」營銷大戰背後的技術架構

消費者的狂歡節「雙 11」剛剛過去。在電商競爭環境日益激烈的今天，為了抓住流量紅利，雙 11 打響的已經不僅僅是「促銷戰」，也是「營銷戰」，這對平臺的技術支撐能力提出新的要求。

從 2014 年的「318 大促」，到正在進行的 「馬蜂窩雙 11 全球旅行蜂搶節」，馬蜂窩旅遊電商業務的大促已經走過 5 年時間，僅僅是雙 11、暑期、十一黃金週、年終這些關鍵節點的 S 級促銷就張羅了 50 多場，每年上線活動達幾百個。

圖：馬蜂窩11.11全球旅行蜂搶節

在這個過程中，馬蜂窩營銷平臺也在經歷著最佳化和改進，不斷探索靈活高效的營銷活動運營開發方式，更好地支撐業務營銷活動的模式創新和投放需求，努力實現平臺商家與馬蜂窩旅遊消費者的高效匹配，目前已經形成了一套較為完整的技術體系。

本文將以馬蜂窩營銷活動後臺的技術實踐為重點，分享馬蜂窩營銷平臺的架構設計思路，希望能讓遇到類似問題的同學有所收穫。

談到大促，大家可能首先會想到的海量資料、高併發、高流量等關鍵詞。其實除了這些，營銷活動數量多、週期短、功能複雜多變等，都是營銷活動運營開發需要應對的挑戰。並且由於我們的很多活動會涉及到一些獎勵或權益的下發，對於安全性的要求也很高。

針對以上問題，馬蜂窩營銷系統的技術架構要具備的核心能力包括：

• 打造靈活、高效的活動開發模式

• 提供高可靠、高可用的活動運營支撐

• 保證營銷活動業務的安全執行

因此，我們本著「平臺化、元件化、模組化」的方法，將營銷體系的基礎架構設計如下：

馬蜂窩整體營銷體系分為 B 端和 C 端兩部分。B 端主要面向商家，幫助商家在馬蜂窩招商平臺進行大促活動的提報以及商品選取；C 端主要是面向馬蜂窩使用者，平臺使用者可以在業務營銷頁面完成活動商品的購買、秒殺、大促紅包贏取等具體的營銷活動參與互動。

C 端營銷平臺的系統架構主要分為主要分為營銷應用層、中間層、投放平臺、搭建平臺四個部分。

• 活動開發平臺：營銷平臺最核心的部分，也是本文重點。包括前端頁面搭建層「魔方」、業務邏輯層「蜂玩樂園」、獎勵規則控制層「獎池」三部分

• 投放平臺：是指營銷活動頁的投放，包括投放策略、運營策略和機制等

• 中介軟體：負責併發處理、分散式快取和容災限流等等

• 營銷應用：包括馬蜂窩大促營銷、業務營銷、新人禮包等
  
  

下面，我們重點介紹營銷搭建平臺的核心部分——活動開發平臺，是如何實現高效、靈活的營銷活動開發模式的。

透過上圖可以看到，由 MySQL、ElasticSearch、Redis 組成的資料池在底層為活動開發平臺提供支撐。其中 MySQL 為最主要的儲存方案，用於會場搭建配置資料、蜂玩樂園的使用者執行資料、獎池配置資料等的存放。ElasticSearch 是搜尋引擎，支援活動頁面商家活動報名與篩選過程。Redis 有 2 種用途：1）活動任務併發鎖；2）獎池的獎品資料存放；3）限流和削峰。

之前我們提到，活動開發的挑戰包括數量多、週期短、功能複雜多變。為了降低開發同學的工作量，提升研發效率，我們將前端和後端元件進行了整合，並封裝成功能模組對提供服務，形成了目前的魔方、蜂玩樂園、獎池三個子系統，使整體結構更加清晰。每個部分解決的問題和主要功能模組示意如下：

「魔方」系統希望透過元件、工具的方式完成營銷頁面的搭建，實現統一維護和複用，從而減少前端團隊在活動開發中承載的重複性開發工作。目前為止我們已經在「魔方」中開發了 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: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 指令出獎，否則不出。

示意圖如下：

為了讓開發同學只專注於任務的設計開發，我們抽象出「賬戶」的概念，每個任務產生的資料資源會儲存在所在的「賬戶」體系下，使其支撐多個類似的活動。這種設計的好處在於：

（1）同一使用者在參與不同的活動時得到的獎勵都是相互獨立的，不會出現混淆的情況。

（2）之前每次活動都需要單獨建立資料表，活動下線後表不能複用。時間長了造成系統佔用許多無用的資料表。而把資料庫表以抽象的任務形態建立，不針對具體的某一業務型別，就可以使資料表實現複用。這樣我們只專注任務的設計開發，不用再關心資料表的設計。

在營銷大促的活動中，我們也接入了風控中心、併發鎖和限流服務，以保障整個活動的安全和穩定。

秒殺模組是大促流量的最高峰。結合業務實際，我們針對這種場景也做了限流和削峰處理。

限流採用的方案是限制時間窗內最大請求資料，使用者再搶會員權益時，第一步會讀取限流配置 key 和 value，判斷單位時間內是否超過限制的最大請求數 value，如果超過則返回資訊提示結束請求；如果沒有超過閾值，則進入下一步操作。目前的限流系統只是在應用層面的實現，為了更好地支撐業務發展，後續我們也會接入閘道器服務，透過 Sentinel 和 Hystrix 做限流熔斷，避免流量進入應用層，提高服務的高可用性。

削峰部分結合例項說明。

以秒殺金卡會員的場景為例，我們會先用 RabbitMQ 承接瞬時的流量洪峰，再平滑地消費所有請求，並提前把庫存數量對應的 Token 寫入 Redis 快取（這裡我們針對性的對不同的使用者引入了 Token 機制，以保證我們的秒殺商品在時效和庫存上得以保障）。使用者在秒殺時會順序地從 Redis 中 rPop 對應的 Token，避免庫存超賣的情況；使用者拿到 Token 之後再去收銀臺下單開通金卡會員，就可以避免流量同一時刻去下單。

隨著業務和技術的發展，系統的不確定性以及流量的預估都更為困難。我們也在不斷學習業界的先進經驗，來更好地提升系統的可用性和可靠性。目前我們正在調研基於 Noah 的「自適應」限流技術並積極推進，以期針對不同的伺服器效能以及當前的流量情況進行針對性的限流控制，相信我們會在後續的最佳化中會做得更好。

目前是接入公司統一的風控中心。在營銷活動需求確定好後，我們會向風控服務中心提供需要風控的業務場景邏輯。風控中心根據業務配置不同策略，給出不同的場景 key。我們只需要在營銷活動任務中的自定義引數配置模組配置好風控場景 key，就可在獎勵服務模組自動呼叫風控介面去校驗使用者，如果識別出是風險使用者則會被攔截，終止活動參與。

可用性和可靠性、風險控制的實現流程如下圖所示：

三、

目前對於活動執行中的資料監控，主要依賴資料組的統計與輸出。線上活動的執行情況並不能透過「蜂玩樂園」與「獎池」系統實時並綜合表現出來。

未來會補齊執行時的活動監控功能，透過活動、任務、獎品的執行時資料指標，指導運營同學第一時間調整活動引數，取得最佳運營效果。

營銷基礎平臺依舊搭建在單體架構上，部分功能的邊界與職責並不完全清晰。接下來營銷技術平臺會進行技術架構的升級與改造，從單體架構轉向微服務架構，使服務能力與開發能效同步提升。

小結

隨著營銷的逐年發展，活動的趣味性和複雜度會一起上升，這需要我們不斷更新對營銷活動的認識。在這過程中也要反覆嘗試新的抽象和重構，透過不斷改進現有系統，支援更多和更好玩的營銷活動，讓馬蜂窩使用者玩兒得更省心，玩兒得更省錢。

本文作者：馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波。

（責任編輯：於雪）