支撐馬蜂窩會員體系全面升級背後的架構設計

時間 2019-11-06

原文原文鏈接

流量紅利正逐漸走向終結，這已經再也不是什麼祕密。後互聯網時代，如何維繫住用戶羣，提高用戶在平臺上的體驗是整個行業都須要考慮的事情。正是出於這一緣由，如今全行業都在關注會員體系的搭建，這也是馬蜂窩 2019 年重點投入的方向之一。數據庫

面對這個全行業都在發力的會員市場，要對「馬蜂窩特點」的會員體系進行有力的支撐，無疑對會員體系的架構設計提出更高的要求。小程序

馬蜂窩會員體系建設從 2018 年 9 月份開始啓動，通過前期對會員身份和會員權益的摸索，伴隨業務的快速發展，到 2019 年上半年，爲了讓更多用戶體驗到馬蜂窩高質量的會員服務，公司推出了更靈活、維度更多、權益更豐富的會員模式。在這樣的背景下，初期較爲粗曠的底層技術也須要及時作出調整，對核心架構和服務進行升級。安全

1、會員身份策略改造

早期的會員身份模塊由會員產品、用戶屬性和時間屬性共同構成：性能優化

能夠看到早期的會員產品比較單一，所以將產品信息設計成一級結構。這種設計的好處是邏輯簡單，能夠快速實現，但不易擴展，一旦新增會員類別以及不一樣卡種之間出現複雜關係時，不管是對項目或者對代碼自己而言，維護成本都將成倍增加。架構

從 2019 年年初開始，馬蜂窩會員體系進行了全面升級，主要體如今如下幾個方面：併發

更完善的獲客渠道，增長了在小程序端的服務展現；框架
更豐富的會員類別，新增了很是多卡種，在最初的年度金卡和體驗金卡基礎上，增長了季度金卡、7 日卡、「蜂享卡」，將來還計劃推出月度金卡、學生卡等；異步
更低的獲取門檻，早期的會員身份只能經過在 App 中購買得到，爲了讓更多用戶享受到品質更高的服務，增長了經過完成用戶激勵任務、供應商合做、產品搭售、線下實體卡等會員獲取方式。分佈式

這也意味着，同一時間段內用戶的會員身份將變得愈發複雜，早期單一的會員身份策略和模型設計已經不能知足需求。從新設計會員身份的時候，咱們明確了將來不管業務線如何劃分會員身份，底層結構都要可以較好地支持，所以決定把會員模塊身份抽離出來。會員體系升級後，產品信息調整爲以 SKU 做爲最小粒度從新劃分，同時增長了用戶信息中的來源以及獲取渠道信息：高併發

2、會員中心架構設計和優化

在明確了新的會員身份策略後，咱們對整個會員體系進行了梳理，將現階段的會員中心架構設計以下：

合上面的架構圖來看，目前馬蜂窩會員中心繫統主要劃分爲數據存儲、核心服務、接口層、應用層四大部分：

數據儲存：主要基於 MySQL 和 Redis，以及馬蜂窩統一日誌系統 MES
核心服務：這是當前馬蜂窩會員體系中最重要的一層。核心服務又能夠分爲三大塊：

（1）「四駕馬車」：會員身份、權益、增值服務接入、會員積分，驅動着整個會員體系的運轉；

（2）交易營銷：輔助四駕馬車快速往前跑；

（3）支撐模塊：與會員體系對接的公司級別支撐模塊，包括風控、監控、日誌、消息總線、商家結算對帳等
接口層：會員體系對外暴露的接口，包括了會員身份、權益領取、蜂蜜消費等接口
應用層：主要是面向 C 端的應用，包括會員頻道頁、蜂蜜中心、用戶權益中心、任務中心等

下面重點圍繞「核心服務」層展開介紹。

2.1「四駕馬車」

2.1.1 會員身份

目前，市面上不少常見的會員產品都是採用普通的續費模式，好比一些視頻平臺的年度會員、季度會員。這種模式的特色是隻進行時間的區分，在會員身份後生效後享受的權益徹底相同，經過續費使權益時效獲得相應延長。

可是馬蜂窩因爲業務的特殊性，會員體系須要設計得更爲立體。若是隻採用單純的續費模式，會影響高忠誠度用戶的使用體驗。

首先，在同一類別的會員身份下，時長不一樣的產品對應的權益也不一樣。以金卡會員爲例，季度金卡、年度金卡這種同類別下的會員身份，能夠經過續費升級，但它們彼擁有的權益不徹底相同，好比年度金卡 96 折抵額上限爲 500 元，季度金卡只有 100 元。
另外，同一用戶在同一時間內，只要知足條件，就可同時擁有不一樣類別的卡種，好比金卡和蜂享卡。

爲了知足上述需求，咱們決定引入用戶身份的疊加以及續費模型。經過增長會員 SKU 疊加、續費關係表，使用戶在一個時間段內不只能夠同時擁有多種身份，還能夠續費已有卡種。

上圖是會員身份的時間軸示意。橫軸表明時間，縱軸表明不一樣的卡種。咱們經過最終 SKU 時間軸即可以確認用戶當前的會員身份。

咱們將用戶已有的每一個 SKU 時間軸拉平，當用戶在某個時間點發出購買新卡種的請求時，查看當前生效的時間軸中是否已有用戶正在購買的 SPU，若是沒有則疊加，如已有則須要再判斷 SKU 之間的配置策略，決定是疊加仍是續費；而後繼續計算出正在購買的 SKU 生效時間軸；接下來根據配置好的規則，對比當前購買生效時間軸和已有 SKU 時間軸的身份關係，決定用戶是否能夠完成這次購買，如：

前置身份：指必須已經購買某個 SKU，才能夠購買當前 SKU
衝突身份：指若是已經購買某個 SKU，就不能夠購買當前 SKU

爲了知足不一樣的業務需求，這裏的疊加、續費關係都是能夠經過運營來配置的。整個流程大體示意以下：

爲了讓用戶的體驗更好，當同時擁有多重身份的時候，咱們會根據數據分析結果調整會員 SPU 權重，優先展現權重高的權益。好比當前會員同時擁有金卡和門票卡，數據顯示金卡權益的使用率或者關注度高於其餘產品，則提高金卡權重，金卡身份和相關權益會在用戶進入會員頻道頁時首先展現。

2.1.2 權益中心

除了身份體系，最重要的就是會員權益，它直接體現會員的不一樣級別。會員項目發展初期，一切都是從零開始，對拓展性要求不高，每出現一種新的身份、卡種，都須要從頭設計其所含權益，開發效率很低，後臺的配置也很分散。後期爲了支撐業務快速發展，咱們開始考慮將權益中心進行拆分，分紅兩部分進行改造。

第一步是權益池的搭建，下圖是權益池的基本模型：

咱們將會員權益中通用的屬性抽象出來，定義爲原則上不變的基礎屬性，造成「權益物料」存放在權益池中，通用的屬性主要包括：

權益類型：主要有兌換碼、折扣購買、優惠券、三方跳轉 4 種，目前能支持到馬蜂窩全部的權益類型
供應商：不一樣供應商提供了不一樣的權益，甚至還有不一樣的權益接入流程和權益消費流程，同時和涉及了不一樣的供應商結算模式
下發時機：主動下發或者被動下發，例如金卡 96 折權益，是用戶購買會員的核心權益，這種權益在用戶購卡以後便直接下發至用戶帳戶。其餘的權益例如機場貴賓廳、QQ 綠鑽、騰訊視頻季卡等則須要用戶主動領取。
基礎屬性：權益的基礎屬性依賴於權益類型、下發時機、供應商，也就是說不一樣的供應商或者不一樣的權益類型和下發時機，都會組合出不一樣的權益基礎屬性，這裏的屬性大可能是這些權益的固定屬性。最終這 4 大屬性共同組成了基本的權益物料。

下圖是用戶開卡及權益發放的流程示意：

當會員產品支付完成後，會員中心會通知權益中心發放權益；權益中心進行權益過濾以後通知優惠中心，最終由優惠中心完成被動權益的發放；須要用戶主動領取的權益則只爲用戶發放使用權利，最終由用戶決定是否領取。

第二步權益規則的配置。有了第一步的基礎以後，會員中心爲權益池中的權益物料配置相應的權益規則，以後展現給用戶。

權益規則主要劃分爲：

條件規則：指肯定權益的一些基本前提，主要指會員身份、前求來源、當前業務等
通用規則：指對外展現的標準，包括文案、排序、上下線時間、權益說明等等
運營規則：這是權益規則中變更最多，也是體現權益中心精細化運營的一部分。不一樣的用戶身份擁有不一樣的權益價格、兌換價格以及不一樣的標籤，差別化地顯示用戶的身份特權

咱們抽象出了權益規則中的通用屬性，造成權益對外展現統一的標準。固然，只有通用的權益規則配置是遠遠不夠的，所以在不影響核心權益規則的前提下，在後臺加入了擴展規則模板的配置，以便知足特殊權益不一樣規則的需求，實現動態規則配置，使用起來更加靈活。

2.1.3 第三方權益接入

權益池中有一部分是站內權益，好比核心的金卡商品 96 折、馬蜂窩優惠券、接送機等。這些權益的發放和消費在站內創建的統一規則下完成，接入起來相對容易。

另一部分是須要接入的站外權益，也就是爲會員供提的增值服務，好比機場貴賓廳、旅行保險等。不一樣的第三方都有本身權益規則的特殊性，目前沒法抽象成統一標準，也就沒法採用 OpenAPI 的方式接入。

現階段咱們把第三方權益的接入進行了流程上的整合，最終造成了兩大類方式：

一類是權益領取在馬蜂窩內完成，用戶全部的操做徹底在咱們的應用裏進行，完成後異步再調用第三方接口爲用戶發放權益。
第二類是權益領取過程徹底在第三方系統中進行，主要針對一些積分兌換的權益。用戶點擊領取權益後跳轉至第三方頁面，交互完成以後異步回調馬蜂窩接口，馬蜂窩系統根據回調狀況進行積分的增長或者扣減。這種方式的弊端是用戶體驗徹底由第三方決定，可控性不高；但優點在於可以快速接入一些複雜的權益玩法，好比一些遊戲類權益，避免投入大量精力去開發。

上圖是兩種領取模式的流程對比圖，能夠看到每一步的三方對接都是經過異步方式進行的，這樣當第三方系統出現異常不會影響到馬蜂窩的正常服務，使系統可用性獲得保證。

2.1.4 會員積分

成長體系對於搭建完整的會員體系很是重要，之內容社區起家的馬蜂窩在這方面有自然的優點。咱們決定引入已有的用戶積分體系「蜂蜜」來承載一部分會員積分的功能。經過與會員中心打通加強與會員用戶的線上互動，提升用戶活躍度和黏性。在不一樣的蜂蜜場景和蜂蜜策略下，用戶能夠賺取積分，知足相應條件後能夠兌換所需權益；此外，咱們也正在拓展更多蜂蜜和 B 端的結合方式，但願促進平臺和商家的雙贏。

上圖是會員體系利用蜂蜜中心提供的服務以及一些近期規劃示意。如何利用好激勵機制使整個會員體系更加完善，實現對會員用戶更加精細化的運營，對於馬蜂窩「內容+交易」戰略的深化而言是一個重要的課題，也是研發團隊須要不斷探索的方向。

2.2 營銷活動的性能優化

實現了會員身份、權益中心、第三方權益接入、蜂蜜中心的改造後，會員中心也完成了升級之路的第一步。

爲了讓更多用戶瞭解會員機制並體驗會員權限，咱們推出了不少營銷活動。其中很多活動都存在秒殺的場景。如下部分就來重點介紹爲保障這些營銷活動的穩定可靠而進行的技術優化。

2.2.1 併發控制

在秒殺場景中，須要防止由高併發致使的庫存超賣。關於這個問題業界已經有很多成熟的解決方案，好比採用悲觀鎖、分佈式鎖、樂觀鎖、隊列串行、Redis 原子操做等等，固然最理想的是用分佈式鎖來實現。

考慮到目前的併發量級以及技術成本，咱們決定先採用 MySQL 樂觀鎖的方式來實現現階段的秒殺功能。你們知道數據庫內部 Update 同一行是不容許併發的，只有當該行被更新後纔會釋放。咱們的方案是經過增長惟一的 Version 來防止超賣的狀況發生：在每次數據 Update 的時候判斷版本號是否和數據庫中的一致，不一致則表示當前庫存已經被其餘用戶佔用，此時拋出異常；若是一致則完成當前用戶對庫存的佔用。

2.2.2 流量削峯

要緩解由瞬間流量爆發形成的數據庫壓力，咱們首先要明確會引發瞬間 QPS 劇增的場景。

一種狀況是接口被惡意重刷。因爲咱們的秒殺業務須要用戶必須登陸，僞造 Session 的可能性較低，所以若是這種狀況發生，頗有多是由同一個 UID 遍歷刷接口致使的。這裏只須要加上 UID 的 Redis 鎖，使一個 UID 在必定時間內只能透過一次請求，這樣絕大部分的遍歷刷接口行爲就能被攔住。

還有一種狀況是由流量突發引發，多是真實的搶購用戶數量巨大，也多是對方使用了大量設備請求，這纔是咱們目前面對的實際場景。前面咱們提到的加 MySQL 樂觀鎖來避免超賣，若是瞬時流量巨大 MySQL 的讀寫、鎖表等現象會比較嚴重，當數據庫壓力達到極限就會被打掛。所以爲了減少數據庫的瞬時壓力，咱們須要在服務層作好限流。好比當庫存只有 1000 件，可是有 1w 請求打到數據庫時，其實後面的請求都沒有意義。咱們知道不管是 Memcache 仍是 Redis，單機下每秒扛住 10w 請求都不會有太大問題。因此在沒有完成分佈式鎖的狀況下，咱們是用 Redis 來作最基本的限流，使大部分的請求被攔截在服務層，只有少許請求會穿透到數據庫。

上圖是當前秒殺體系簡單的流程圖。後續若是這類會員營銷活動依舊是業務重點，咱們仍是會採用 Redis 分佈式鎖的方式來優化，搭建更爲完善的秒殺體系。

2.3 風險控制

關於支撐模塊的部分主要分享與風險控制相關的內容。爲了保證享受到會員服務的是真實用戶，咱們須要識別並抵禦由黑產帶來的潛在風險，保障系統的正常運行，嚴控由此帶來的損失。

上圖是目前會員體系中安全控制的結構示意。API 路由層主要負責數據收集和風險預估，收集上來的數據統一寫入到公司的日誌系統 MES 中存儲。咱們使用了滑窗模式的限流方式，當發現總訪問量超過必定閾值則會將大流量或者過快的請求記錄到會員疑似黑名單的表中，再進行路由層的限流處理並接入公司級別風控體系，根據對不一樣業務場景的識別採用相關風控策略；最終經過郵件、短信等方式通知到路由層相應的技術負責人，儘快處理。