(馬蜂窩技術原創內容，公眾號 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. 服務化改造
營銷基礎平台依舊搭建在單體架構上，部分功能的邊界與職責並不完全清晰。接下來營銷技術平台會進行技術架構的升級與改造，從單體架構轉向微服務架構，使服務能力與開發能效同步提升。
小結
隨着營銷的逐年發展，活動的趣味性和複雜度會一起上升，這需要我們不斷更新對營銷活動的認識。在這過程中也要反覆嘗試新的抽象和重構，通過不斷改進現有系統，支持更多和更好玩的營銷活動，讓馬蜂窩用戶玩兒得更省心，玩兒得更省錢。
本文作者：馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
昶洧自有品牌 Thunder Power 電動車系列，於「2015 法蘭克福國際車展(9 月 17 日至 27 日)」中進行首秀。昶洧表示，Thunder Power 電動車系列量產車預計將於 2017 年在歐洲上市，2018 年在中國大陸上市，之後更將進一步拓展美國市場。 Thunder Power 主要生產廠將設在大陸浙江省紹興市，而歐洲的生產基地，待確定後也將公佈。公司指出，目前所有研發活動都將由昶洧設在米蘭附近的歐洲總部開展並管理，而設在中國大陸和美國的研發機構將負責提供額外支持。 昶洧指出，Thunder Power 作為一款後驅電動轎車，擁有令人興奮的駕控性能，和令同儕豔羨的強大續航能力，該系列車型輸出功率有 230 千瓦或 320 千瓦 2 款動力選擇，充滿電後可行駛超過 650 公里，經過 30 分鐘短暫充電，可再行駛 300 多公里，強大的續航能力足以傲視同級；320 千瓦功率車型在 5 秒內便可完成 0-100 公里加速，最高時速可達 250 公里。 昶洧董事長沈瑋表示，公司歷經 5 年多研發，於本屆法蘭克福國際車展上展出 Thunder Power 豪華電動車系列，選擇在此舉行全球首秀，希望吸引全球媒體、投資人和消費者的目光；相信電動車成為主流並取代內燃發動機汽車，不再是不可能的事，而只是時間問題。
