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

流量紅利正逐漸走向終結，這已經不再是什麼秘密。後網際網路時代，如何維系住使用者群，提升使用者在平台上的體驗是整個行業都需要考慮的事情。正是出于這一原因，現在全行業都在關注會員體系的搭建，這也是馬蜂窩 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 中存儲。我們使用了滑窗模式的限流方式，當發現總通路量超過一定門檻值則會将大流量或者過快的請求記錄到會員疑似黑名單的表中，再進行路由層的限流處理并接入公司級别風控體系，根據對不同業務場景的識别采用相關風控政策；最終通過郵件、短信等方式通知到路由層相應的技術負責人，盡快處理。

三、總結和展望

在進行馬蜂窩會員體系架構的搭建的實戰過程中，我們積累了很多有價值的經驗，其中感受最深的就是切忌盲目優化，系統層面上的重構更要首先以業務為導向去關注核心架構的更新和技術體系的演進，不要因為過度陷入技術細節而迷失方向。

今後，我們還将積極調研和應用更多主流、前沿技術，比如會員标簽、使用者畫像體系的引入，真正把這些技術用好用活，使會員中心發揮更大價值。

本文作者：馬蜂窩電商會員項目研發團隊。

彩蛋

歡迎大家關注馬蜂窩技術公衆号背景，并針對本文積極留言，發表觀點或者進行更多相關的技術交流。截至 7 月 27 日 7:00 pm，我們将從公衆号背景篩選出留言品質最高的 7 位讀者贈送馬蜂窩季度金卡，千萬别錯過！（掃描下方二維碼關注公衆号）