流量紅利正逐漸走向終結，這已經不再是什麼祕密。後互聯網時代，如何維繫住用戶羣，提升用戶在平臺上的體驗是整個行業都需要考慮的事情。正是出於這一原因，現在全行業都在關注會員體系的搭建，這也是馬蜂窩 2019 年重點投入的方向之一。
面對這個全行業都在發力的會員市場，要對「馬蜂窩特色」的會員體系進行有力的支撐，無疑對會員體系的架構設計提出更高的要求。
馬蜂窩會員體系建設從 2018 年 9 月份開始啓動，經過前期對會員身份和會員權益的摸索，伴隨業務的快速發展，到 2019 年上半年，爲了讓更多用戶體驗到馬蜂窩高質量的會員服務，公司推出了更靈活、維度更多、權益更豐富的會員模式。在這樣的背景下，初期較爲粗曠的底層技術也需要及時做出調整，對核心架構和服務進行升級。
一、會員身份策略改造
早期的會員身份模塊由會員產品、用戶屬性和時間屬性共同構成：
可以看到早期的會員產品比較單一，因此將產品信息設計成一級結構。這種設計的好處是邏輯簡單，可以快速實現，但不易擴展，一旦新增會員類別以及不同卡種之間出現複雜關係時，不論是對項目或者對代碼本身而言，維護成本都將成倍增長。
從 2019 年年初開始，馬蜂窩會員體系進行了全面升級，主要體現在以下幾個方面：
- 更完善的獲客渠道，增加了在小程序端的服務展示；
- 更豐富的會員類別，新增了非常多卡種，在最初的年度金卡和體驗金卡基礎上，增加了季度金卡、 7 日卡、「蜂享卡」，未來還計劃推出月度金卡、學生卡等；
- 更低的獲取門檻，早期的會員身份只能通過在 App 中購買獲得，爲了讓更多用戶享受到品質更高的服務，增加了通過完成用戶激勵任務、供應商合作、產品搭售、線下實體卡等會員獲取方式。
這也意味着，同一時間段內用戶的會員身份將變得愈發複雜，早期單一的會員身份策略和模型設計已經不能滿足需求。重新設計會員身份的時候，我們明確了未來無論業務線如何劃分會員身份，底層結構都要能夠較好地支持，因此決定把會員模塊身份抽離出來。會員體系升級後，產品信息調整爲以 SKU 作爲最小粒度重新劃分，同時增加了用戶信息中的來源以及獲取渠道信息：
二、會員中心架構設計和優化
在明確了新的會員身份策略後，我們對整個會員體系進行了梳理，將現階段的會員中心架構設計如下：
合上面的架構圖來看，目前馬蜂窩會員中心繫統主要劃分爲數據存儲、核心服務、接口層、應用層四大部分：
-
數據儲存：主要基於 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 折、馬蜂窩優惠券、接送機等。這些權益的發放和消費在站內建立的統一規則下完成，接入起來相對容易。
權益池中有一部分是站內權益，比如核心的金卡商品 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 中存儲。我們使用了滑窗模式的限流方式，當發現總訪問量超過一定閾值則會將大流量或者過快的請求記錄到會員疑似黑名單的表中，再進行路由層的限流處理並接入公司級別風控體系，根據對不同業務場景的識別採用相關風控策略；最終通過郵件、短信等方式通知到路由層相應的技術負責人，儘快處理。
三、總結和展望
在進行馬蜂窩會員體系架構的搭建的實戰過程中，我們積累了很多有價值的經驗，其中感受最深的就是切忌盲目優化，系統層面上的重構更要首先以業務爲導向去關注核心框架的升級和技術體系的演進，不要因爲過度陷入技術細節而迷失方向。
今後，我們還將積極調研和應用更多主流、前沿技術，比如會員標籤、用戶畫像體系的引入，真正把這些技術用好用活，使會員中心發揮更大價值。
