(馬蜂窩技術原創內容,公衆號 ID: mfwtech)前端
消費者的狂歡節「雙 11」剛剛過去。在電商競爭環境日益激烈的今天,爲了抓住流量紅利,雙 11 打響的已經不只僅是「促銷戰」,也是「營銷戰」,這對平臺的技術支撐能力提出新的要求。正則表達式
從 2014 年的「318 大促」,到正在進行的 「馬蜂窩雙 11 全球旅行蜂搶節」,馬蜂窩旅遊電商業務的大促已經走過 5 年時間,僅僅是雙 十一、暑期、十一黃金週、年終這些關鍵節點的 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:
以一個用戶開啓紅包的配置信息爲例:
(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,就可在獎勵服務模塊自動調用風控接口去校驗用戶,若是識別出是風險用戶則會被攔截,終止活動參與。
可用性和可靠性、風險控制的實現流程以下圖所示:
目前對於活動運行中的數據監控,主要依賴數據組的統計與輸出。線上活動的運行狀況並不能經過「蜂玩樂園」與「獎池」系統實時並綜合表現出來。
將來會補齊運行時的活動監控功能,經過活動、任務、獎品的運行時數據指標,指導運營同窗第一時間調整活動參數,取得最佳運營效果。
營銷基礎平臺依舊搭建在單體架構上,部分功能的邊界與職責並不徹底清晰。接下來營銷技術平臺會進行技術架構的升級與改造,從單體架構轉向微服務架構,使服務能力與開發能效同步提高。
隨着營銷的逐年發展,活動的趣味性和複雜度會一塊兒上升,這須要咱們不斷更新對營銷活動的認識。在這過程當中也要反覆嘗試新的抽象和重構,經過不斷改進現有系統,支持更多和更好玩的營銷活動,讓馬蜂窩用戶玩兒得更省心,玩兒得更省錢。
本文做者:馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波。