來(lái)自公眾號(hào)：馬蜂窩技術(shù)
作者：會(huì)員項(xiàng)目研發(fā)團(tuán)隊(duì)
流量紅利正逐漸走向終結(jié)，這已經(jīng)不再是什么秘密。后互聯(lián)網(wǎng)時(shí)代，如何維系住用戶群姐呐，提升用戶在平臺(tái)上的體驗(yàn)是整個(gè)行業(yè)都需要考慮的事情。正是出于這一原因典蝌，現(xiàn)在全行業(yè)都在關(guān)注會(huì)員體系的搭建曙砂，這也是馬蜂窩 2019 年重點(diǎn)投入的方向之一。
面對(duì)這個(gè)全行業(yè)都在發(fā)力的會(huì)員市場(chǎng)骏掀，要對(duì)「馬蜂窩特色」的會(huì)員體系進(jìn)行有力的支撐鸠澈，無(wú)疑對(duì)會(huì)員體系的架構(gòu)設(shè)計(jì)提出更高的要求。
馬蜂窩會(huì)員體系建設(shè)從 2018 年 9 月份開(kāi)始啟動(dòng)截驮，經(jīng)過(guò)前期對(duì)會(huì)員身份和會(huì)員權(quán)益的摸索笑陈，伴隨業(yè)務(wù)的快速發(fā)展，到 2019 年上半年葵袭，為了讓更多用戶體驗(yàn)到馬蜂窩高質(zhì)量的會(huì)員服務(wù)涵妥，公司推出了更靈活、維度更多坡锡、權(quán)益更豐富的會(huì)員模式蓬网。在這樣的背景下，初期較為粗曠的底層技術(shù)也需要及時(shí)做出調(diào)整鹉勒，對(duì)核心架構(gòu)和服務(wù)進(jìn)行升級(jí)帆锋。
Part 1
會(huì)員身份策略改造
早期的會(huì)員身份模塊由會(huì)員產(chǎn)品、用戶屬性和時(shí)間屬性共同構(gòu)成禽额。由于當(dāng)時(shí)的產(chǎn)品較為單一锯厢，因此產(chǎn)品信息設(shè)計(jì)成一級(jí)結(jié)構(gòu)：
可以看到早期的會(huì)員產(chǎn)品比較單一柴罐，因此將產(chǎn)品信息設(shè)計(jì)成一級(jí)結(jié)構(gòu)惊搏。這種設(shè)計(jì)的好處是邏輯簡(jiǎn)單，可以快速實(shí)現(xiàn)涤伐，但不易擴(kuò)展盔憨，一旦新增會(huì)員類別以及不同卡種之間出現(xiàn)復(fù)雜關(guān)系時(shí)徙菠，不論是對(duì)項(xiàng)目或者對(duì)代碼本身而言，維護(hù)成本都將成倍增長(zhǎng)郁岩。
從 2019 年年初開(kāi)始婿奔，馬蜂窩會(huì)員體系進(jìn)行了全面升級(jí)，主要體現(xiàn)在以下幾個(gè)方面：
更完善的獲客渠道问慎，增加了在小程序端的服務(wù)展示萍摊；
更豐富的會(huì)員類別，新增了非常多卡種如叼，在最初的年度金卡和體驗(yàn)金卡基礎(chǔ)上冰木，增加了季度金卡、 7 日卡、「蜂享卡」踊沸，未來(lái)還計(jì)劃推出月度金卡歇终、學(xué)生卡等；
更低的獲取門(mén)檻逼龟，早期的會(huì)員身份只能通過(guò)在 App 中購(gòu)買獲得评凝，為了讓更多用戶享受到品質(zhì)更高的服務(wù)，增加了通過(guò)完成用戶激勵(lì)任務(wù)腺律、供應(yīng)商合作奕短、產(chǎn)品搭售、線下實(shí)體卡等會(huì)員獲取方式匀钧。
這也意味著翎碑，同一時(shí)間段內(nèi)用戶的會(huì)員身份將變得愈發(fā)復(fù)雜，早期單一的會(huì)員身份策略和模型設(shè)計(jì)已經(jīng)不能滿足需求榴捡。重新設(shè)計(jì)會(huì)員身份的時(shí)候杈女，我們明確了未來(lái)無(wú)論業(yè)務(wù)線如何劃分會(huì)員身份，底層結(jié)構(gòu)都要能夠較好地支持吊圾，因此決定把會(huì)員模塊身份抽離出來(lái)达椰。會(huì)員體系升級(jí)后，產(chǎn)品信息調(diào)整為以 SKU 作為最小粒度重新劃分项乒，同時(shí)增加了用戶信息中的來(lái)源以及獲取渠道信息：
Part 2
會(huì)員中心架構(gòu)設(shè)計(jì)和優(yōu)化
在明確了新的會(huì)員身份策略后啰劲，我們對(duì)整個(gè)會(huì)員體系進(jìn)行了梳理，將現(xiàn)階段的會(huì)員中心架構(gòu)設(shè)計(jì)如下：
結(jié)合上面的架構(gòu)圖來(lái)看檀何，目前馬蜂窩會(huì)員中心系統(tǒng)主要?jiǎng)澐譃閿?shù)據(jù)存儲(chǔ)蝇裤、核心服務(wù)、接口層频鉴、應(yīng)用層四大部分：
數(shù)據(jù)儲(chǔ)存：主要基于 MySQL 和 Redis栓辜，以及馬蜂窩統(tǒng)一日志系統(tǒng) MES
-
核心服務(wù)：這是當(dāng)前馬蜂窩會(huì)員體系中最重要的一層。核心服務(wù)又可以分為三大塊：
（1）「四駕馬車」：會(huì)員身份垛孔、權(quán)益藕甩、增值服務(wù)接入、會(huì)員積分周荐，驅(qū)動(dòng)著整個(gè)會(huì)員體系的運(yùn)轉(zhuǎn)狭莱；
（2）交易營(yíng)銷：輔助四駕馬車快速往前跑；
（3）支撐模塊：與會(huì)員體系對(duì)接的公司級(jí)別支撐模塊概作，包括風(fēng)控腋妙、監(jiān)控、日志讯榕、消息總線骤素、商家結(jié)算對(duì)賬等
接口****層：會(huì)員體系對(duì)外暴露的接口匙睹，包括了會(huì)員身份、權(quán)益領(lǐng)取谆甜、蜂蜜消費(fèi)等接口
應(yīng)用層：主要是面向 C 端的應(yīng)用垃僚，包括會(huì)員頻道頁(yè)、蜂蜜中心规辱、用戶權(quán)益中心、任務(wù)中心等
下面重點(diǎn)圍繞「核心服務(wù)」層展開(kāi)介紹栽燕。
2.1「四駕馬車」
2.1.1 會(huì)員身份
目前罕袋，市面上很多常見(jiàn)的會(huì)員產(chǎn)品都是采用普通的續(xù)費(fèi)模式，比如一些視頻平臺(tái)的年度會(huì)員碍岔、季度會(huì)員浴讯。這種模式的特點(diǎn)是只進(jìn)行時(shí)間的區(qū)分，在會(huì)員身份后生效后享受的權(quán)益完全相同蔼啦，通過(guò)續(xù)費(fèi)使權(quán)益時(shí)效得到相應(yīng)延長(zhǎng)榆纽。
但是馬蜂窩由于業(yè)務(wù)的特殊性，會(huì)員體系需要設(shè)計(jì)得更為立體捏肢。如果只采用單純的續(xù)費(fèi)模式奈籽，會(huì)影響高忠誠(chéng)度用戶的使用體驗(yàn)。
首先鸵赫，在同一類別的會(huì)員身份下衣屏，時(shí)長(zhǎng)不同的產(chǎn)品對(duì)應(yīng)的權(quán)益也不同。以金卡會(huì)員為例辩棒，季度金卡狼忱、年度金卡這種同類別下的會(huì)員身份，可以通過(guò)續(xù)費(fèi)升級(jí)一睁，但它們彼擁有的權(quán)益不完全相同钻弄，比如年度金卡 96 折抵額上限為 500 元，季度金卡只有 100 元者吁。
另外窘俺，同一用戶在同一時(shí)間內(nèi)，只要滿足條件砚偶，就可同時(shí)擁有不同類別的卡種批销，比如金卡和蜂享卡。
為了滿足上述需求染坯，我們決定引入用戶身份的疊加以及續(xù)費(fèi)模型均芽。通過(guò)增加會(huì)員 SKU 疊加、續(xù)費(fèi)關(guān)系表单鹿，使用戶在一個(gè)時(shí)間段內(nèi)不僅可以同時(shí)擁有多種身份掀宋，還可以續(xù)費(fèi)已有卡種。
上圖是會(huì)員身份的時(shí)間軸示意。橫軸代表時(shí)間劲妙，縱軸代表不同的卡種湃鹊。我們通過(guò)最終 SKU 時(shí)間軸便可以確認(rèn)用戶當(dāng)前的會(huì)員身份。
我們將用戶已有的每個(gè) SKU 時(shí)間軸拉平镣奋，當(dāng)用戶在某個(gè)時(shí)間點(diǎn)發(fā)出購(gòu)買新卡種的請(qǐng)求時(shí)币呵，查看當(dāng)前生效的時(shí)間軸中是否已有用戶正在購(gòu)買的 SPU，如果沒(méi)有則疊加侨颈，如已有則需要再判斷 SKU 之間的配置策略余赢，決定是疊加還是續(xù)費(fèi)；然后繼續(xù)計(jì)算出正在購(gòu)買的 SKU 生效時(shí)間軸哈垢；接下來(lái)根據(jù)配置好的規(guī)則妻柒，對(duì)比當(dāng)前購(gòu)買生效時(shí)間軸和已有 SKU 時(shí)間軸的身份關(guān)系，決定用戶是否可以完成此次購(gòu)買耘分，如：
前置身份：指必須已經(jīng)購(gòu)買某個(gè) SKU举塔，才可以購(gòu)買當(dāng)前 SKU
沖突身份：指如果已經(jīng)購(gòu)買某個(gè) SKU，就不可以購(gòu)買當(dāng)前 SKU
為了滿足不同的業(yè)務(wù)需求求泰，這里的疊加央渣、續(xù)費(fèi)關(guān)系都是可以通過(guò)運(yùn)營(yíng)來(lái)配置的。整個(gè)流程大致示意如下：
為了讓用戶的體驗(yàn)更好拜秧，當(dāng)同時(shí)擁有多重身份的時(shí)候痹屹，我們會(huì)根據(jù)數(shù)據(jù)分析結(jié)果調(diào)整會(huì)員 SPU 權(quán)重，優(yōu)先展示權(quán)重高的權(quán)益枉氮。比如當(dāng)前會(huì)員同時(shí)擁有金卡和門(mén)票卡志衍，數(shù)據(jù)顯示金卡權(quán)益的使用率或者關(guān)注度高于其他產(chǎn)品，則提升金卡權(quán)重聊替，金卡身份和相關(guān)權(quán)益會(huì)在用戶進(jìn)入會(huì)員頻道頁(yè)時(shí)首先展示楼肪。
2.1.2 權(quán)益中心
除了身份體系，最重要的就是會(huì)員權(quán)益惹悄，它直接體現(xiàn)會(huì)員的不同級(jí)別春叫。會(huì)員項(xiàng)目發(fā)展初期，一切都是從零開(kāi)始泣港，對(duì)拓展性要求不高暂殖，每出現(xiàn)一種新的身份、卡種当纱，都需要從頭設(shè)計(jì)其所含權(quán)益呛每，開(kāi)發(fā)效率很低，后臺(tái)的配置也很分散坡氯。后期為了支撐業(yè)務(wù)快速發(fā)展晨横，我們開(kāi)始考慮將權(quán)益中心進(jìn)行拆分洋腮，分成兩部分進(jìn)行改造。
第一步是權(quán)益池的搭建手形，下圖是權(quán)益池的基本模型：
我們將會(huì)員權(quán)益中通用的屬性抽象出來(lái)啥供，定義為原則上不變的基礎(chǔ)屬性，形成「權(quán)益物料」存放在權(quán)益池中库糠，通用的屬性主要包括：
權(quán)益類型：主要有兌換碼伙狐、折扣購(gòu)買、優(yōu)惠券曼玩、三方跳轉(zhuǎn) 4 種鳞骤，目前能支持到馬蜂窩所有的權(quán)益類型
供應(yīng)商：不同供應(yīng)商提供了不同的權(quán)益，甚至還有不同的權(quán)益接入流程和權(quán)益消費(fèi)流程黍判，同時(shí)和涉及了不同的供應(yīng)商結(jié)算模式
下發(fā)時(shí)機(jī)：主動(dòng)下發(fā)或者被動(dòng)下發(fā)，例如金卡 96 折權(quán)益篙梢，是用戶購(gòu)買會(huì)員的核心權(quán)益顷帖，這種權(quán)益在用戶購(gòu)卡之后便直接下發(fā)至用戶賬戶。其他的權(quán)益例如機(jī)場(chǎng)貴賓廳渤滞、QQ 綠鉆贬墩、騰訊視頻季卡等則需要用戶主動(dòng)領(lǐng)取。
基礎(chǔ)屬性：權(quán)益的基礎(chǔ)屬性依賴于權(quán)益類型妄呕、下發(fā)時(shí)機(jī)陶舞、供應(yīng)商，也就是說(shuō)不同的供應(yīng)商或者不同的權(quán)益類型和下發(fā)時(shí)機(jī)绪励，都會(huì)組合出不同的權(quán)益基礎(chǔ)屬性肿孵，這里的屬性大多是這些權(quán)益的固定屬性。最終這 4 大屬性共同組成了基本的權(quán)益物料疏魏。
下圖是用戶開(kāi)卡及權(quán)益發(fā)放的流程示意：
當(dāng)會(huì)員產(chǎn)品支付完成后停做，會(huì)員中心會(huì)通知權(quán)益中心發(fā)放權(quán)益；權(quán)益中心進(jìn)行權(quán)益過(guò)濾之后通知優(yōu)惠中心大莫，最終由優(yōu)惠中心完成被動(dòng)權(quán)益的發(fā)放蛉腌；需要用戶主動(dòng)領(lǐng)取的權(quán)益則只為用戶發(fā)放使用權(quán)利，最終由用戶決定是否領(lǐng)取只厘。
第二步權(quán)益規(guī)則的配置烙丛。有了第一步的基礎(chǔ)之后，會(huì)員中心為權(quán)益池中的權(quán)益物料配置相應(yīng)的權(quán)益規(guī)則羔味，之后展示給用戶河咽。
權(quán)益規(guī)則主要?jiǎng)澐譃椋?/p>
條件規(guī)則：指確定權(quán)益的一些基本前提，主要指會(huì)員身份介评、前求來(lái)源库北、當(dāng)前業(yè)務(wù)等
通用規(guī)則：指對(duì)外展示的標(biāo)準(zhǔn)爬舰，包括文案、排序寒瓦、上下線時(shí)間情屹、權(quán)益說(shuō)明等等
運(yùn)營(yíng)規(guī)則：這是權(quán)益規(guī)則中變動(dòng)最多，也是體現(xiàn)權(quán)益中心精細(xì)化運(yùn)營(yíng)的一部分杂腰。不同的用戶身份擁有不同的權(quán)益價(jià)格垃你、兌換價(jià)格以及不同的標(biāo)簽，差異化地顯示用戶的身份特權(quán)
我們抽象出了權(quán)益規(guī)則中的通用屬性喂很，形成權(quán)益對(duì)外展示統(tǒng)一的標(biāo)準(zhǔn)惜颇。當(dāng)然，只有通用的權(quán)益規(guī)則配置是遠(yuǎn)遠(yuǎn)不夠的少辣，因此在不影響核心權(quán)益規(guī)則的前提下凌摄，在后臺(tái)加入了擴(kuò)展規(guī)則模板的配置，以便滿足特殊權(quán)益不同規(guī)則的需求漓帅，實(shí)現(xiàn)動(dòng)態(tài)規(guī)則配置锨亏，使用起來(lái)更加靈活。
2.1.3 第三方權(quán)益接入
權(quán)益池中有一部分是站內(nèi)權(quán)益忙干，比如核心的金卡商品 96 折器予、馬蜂窩優(yōu)惠券、接送機(jī)等捐迫。這些權(quán)益的發(fā)放和消費(fèi)在站內(nèi)建立的統(tǒng)一規(guī)則下完成乾翔，接入起來(lái)相對(duì)容易。
另外一部分是需要接入的站外權(quán)益施戴，也就是為會(huì)員供提的增值服務(wù)反浓，比如機(jī)場(chǎng)貴賓廳、旅行保險(xiǎn)等暇韧。不同的第三方都有自己權(quán)益規(guī)則的特殊性勾习，目前無(wú)法抽象成統(tǒng)一標(biāo)準(zhǔn)，也就無(wú)法采用 OpenAPI 的方式接入懈玻。
現(xiàn)階段我們把第三方權(quán)益的接入進(jìn)行了流程上的整合巧婶，最終形成了兩大類方式：
一類是權(quán)益領(lǐng)取在馬蜂窩內(nèi)完成，用戶所有的操作完全在我們的應(yīng)用里進(jìn)行涂乌，完成后異步再調(diào)用第三方接口為用戶發(fā)放權(quán)益艺栈。
第二類是權(quán)益領(lǐng)取過(guò)程完全在第三方系統(tǒng)中進(jìn)行，主要針對(duì)一些積分兌換的權(quán)益湾盒。用戶點(diǎn)擊領(lǐng)取權(quán)益后跳轉(zhuǎn)至第三方頁(yè)面湿右，交互完成之后異步回調(diào)馬蜂窩接口，馬蜂窩系統(tǒng)根據(jù)回調(diào)情況進(jìn)行積分的增加或者扣減罚勾。這種方式的弊端是用戶體驗(yàn)完全由第三方?jīng)Q定毅人，可控性不高吭狡；但優(yōu)勢(shì)在于能夠快速接入一些復(fù)雜的權(quán)益玩法，比如一些游戲類權(quán)益丈莺，避免投入大量精力去開(kāi)發(fā)划煮。
上圖是兩種領(lǐng)取模式的流程對(duì)比圖，可以看到每一步的三方對(duì)接都是通過(guò)異步方式進(jìn)行的缔俄，這樣當(dāng)?shù)谌较到y(tǒng)出現(xiàn)異常不會(huì)影響到馬蜂窩的正常服務(wù)弛秋，使系統(tǒng)可用性得到保證。
2.1.4 會(huì)員積分
成長(zhǎng)體系對(duì)于搭建完整的會(huì)員體系非常重要俐载，以內(nèi)容社區(qū)起家的馬蜂窩在這方面有天然的優(yōu)勢(shì)蟹略。我們決定引入已有的用戶積分體系「蜂蜜」來(lái)承載一部分會(huì)員積分的功能。通過(guò)與會(huì)員中心打通增強(qiáng)與會(huì)員用戶的線上互動(dòng)遏佣，提高用戶活躍度和黏性挖炬。在不同的蜂蜜場(chǎng)景和蜂蜜策略下，用戶可以賺取積分状婶，滿足相應(yīng)條件后可以兌換所需權(quán)益茅茂；此外，我們也正在拓展更多蜂蜜和 B 端的結(jié)合方式太抓，希望促進(jìn)平臺(tái)和商家的共贏。
上圖是會(huì)員體系利用蜂蜜中心提供的服務(wù)以及一些近期規(guī)劃示意令杈。如何利用好激勵(lì)機(jī)制使整個(gè)會(huì)員體系更加完善走敌，實(shí)現(xiàn)對(duì)會(huì)員用戶更加精細(xì)化的運(yùn)營(yíng)，對(duì)于馬蜂窩「內(nèi)容+交易」戰(zhàn)略的深化而言是一個(gè)重要的課題逗噩，也是研發(fā)團(tuán)隊(duì)需要不斷探索的方向掉丽。
實(shí)現(xiàn)了會(huì)員身份、權(quán)益中心异雁、第三方權(quán)益接入捶障、蜂蜜中心的改造后，會(huì)員中心也完成了升級(jí)之路的第一步纲刀。
2.2 營(yíng)銷活動(dòng)的性能優(yōu)化
為了讓更多用戶了解會(huì)員機(jī)制并體驗(yàn)會(huì)員權(quán)限项炼，我們推出了很多營(yíng)銷活動(dòng)。其中不少活動(dòng)都存在秒殺的場(chǎng)景示绊。以下部分就來(lái)重點(diǎn)介紹為保障這些營(yíng)銷活動(dòng)的穩(wěn)定可靠而進(jìn)行的技術(shù)優(yōu)化锭部。
2.2.1 并發(fā)控制
在秒殺場(chǎng)景中，需要防止由高并發(fā)導(dǎo)致的庫(kù)存超賣面褐。關(guān)于這個(gè)問(wèn)題業(yè)界已經(jīng)有不少成熟的解決方案拌禾，比如采用悲觀鎖、分布式鎖展哭、樂(lè)觀鎖湃窍、隊(duì)列串行闻蛀、Redis 原子操作等等，當(dāng)然最理想的是用分布式鎖來(lái)實(shí)現(xiàn)您市。
考慮到目前的并發(fā)量級(jí)以及技術(shù)成本觉痛，我們決定先采用 MySQL 樂(lè)觀鎖的方式來(lái)實(shí)現(xiàn)現(xiàn)階段的秒殺功能。大家知道數(shù)據(jù)庫(kù)內(nèi)部 Update 同一行是不允許并發(fā)的墨坚，只有當(dāng)該行被更新后才會(huì)釋放秧饮。我們的方案是通過(guò)增加唯一的 Version 來(lái)防止超賣的情況發(fā)生：在每次數(shù)據(jù) Update 的時(shí)候判斷版本號(hào)是否和數(shù)據(jù)庫(kù)中的一致，不一致則表示當(dāng)前庫(kù)存已經(jīng)被其他用戶占用泽篮，此時(shí)拋出異常盗尸；如果一致則完成當(dāng)前用戶對(duì)庫(kù)存的占用。
2.2.2 流量削峰
要緩解由瞬間流量爆發(fā)造成的數(shù)據(jù)庫(kù)壓力帽撑，我們首先要明確會(huì)引起瞬間 QPS 劇增的場(chǎng)景泼各。
一種情況是接口被惡意重刷。由于我們的秒殺業(yè)務(wù)需要用戶必須登錄亏拉，偽造 Session 的可能性較低扣蜻，因此如果這種情況發(fā)生，很有可能是由同一個(gè) UID 遍歷刷接口導(dǎo)致的及塘。這里只需要加上 UID 的 Redis 鎖莽使，使一個(gè) UID 在一定時(shí)間內(nèi)只能透過(guò)一次請(qǐng)求，這樣絕大部分的遍歷刷接口行為就能被攔住笙僚。
還有一種情況是由流量突發(fā)引起芳肌，可能是真實(shí)的搶購(gòu)用戶數(shù)量巨大，也可能是對(duì)方使用了大量設(shè)備請(qǐng)求肋层，這才是我們目前面對(duì)的實(shí)際場(chǎng)景亿笤。前面我們提到的加 MySQL 樂(lè)觀鎖來(lái)避免超賣，如果瞬時(shí)流量巨大 MySQL 的讀寫(xiě)栋猖、鎖表等現(xiàn)象會(huì)比較嚴(yán)重净薛，當(dāng)數(shù)據(jù)庫(kù)壓力達(dá)到極限就會(huì)被打掛。因此為了減小數(shù)據(jù)庫(kù)的瞬時(shí)壓力蒲拉，我們需要在服務(wù)層做好限流肃拜。比如當(dāng)庫(kù)存只有 1000 件，但是有 1w 請(qǐng)求打到數(shù)據(jù)庫(kù)時(shí)全陨，其實(shí)后面的請(qǐng)求都沒(méi)有意義爆班。我們知道不論是 Memcache 還是 Redis，單機(jī)下每秒扛住 10w 請(qǐng)求都不會(huì)有太大問(wèn)題辱姨。所以在沒(méi)有完成分布式鎖的情況下柿菩，我們是用 Redis 來(lái)做最基本的限流，使大部分的請(qǐng)求被攔截在服務(wù)層雨涛，只有少量請(qǐng)求會(huì)穿透到數(shù)據(jù)庫(kù)枢舶。
上圖是當(dāng)前秒殺體系簡(jiǎn)單的流程圖懦胞。后續(xù)如果這類會(huì)員營(yíng)銷活動(dòng)依舊是業(yè)務(wù)重點(diǎn)，我們還是會(huì)采用 Redis 分布式鎖的方式來(lái)優(yōu)化凉泄，搭建更為完善的秒殺體系躏尉。
2.3 風(fēng)險(xiǎn)控制
關(guān)于支撐模塊的部分主要分享與風(fēng)險(xiǎn)控制相關(guān)的內(nèi)容。為了保證享受到會(huì)員服務(wù)的是真實(shí)用戶后众，我們需要識(shí)別并抵御由黑產(chǎn)帶來(lái)的潛在風(fēng)險(xiǎn)胀糜，保障系統(tǒng)的正常運(yùn)行，嚴(yán)控由此帶來(lái)的損失蒂誉。
上圖是目前會(huì)員體系中安全控制的結(jié)構(gòu)示意教藻。API 路由層主要負(fù)責(zé)數(shù)據(jù)收集和風(fēng)險(xiǎn)預(yù)估，收集上來(lái)的數(shù)據(jù)統(tǒng)一寫(xiě)入到公司的日志系統(tǒng) MES 中存儲(chǔ)右锨。我們使用了滑窗模式的限流方式括堤，當(dāng)發(fā)現(xiàn)總訪問(wèn)量超過(guò)一定閾值則會(huì)將大流量或者過(guò)快的請(qǐng)求記錄到會(huì)員疑似黑名單的表中，再進(jìn)行路由層的限流處理并接入公司級(jí)別風(fēng)控體系绍移，根據(jù)對(duì)不同業(yè)務(wù)場(chǎng)景的識(shí)別采用相關(guān)風(fēng)控策略悄窃；最終通過(guò)郵件、短信等方式通知到路由層相應(yīng)的技術(shù)負(fù)責(zé)人蹂窖，盡快處理轧抗。
Part 3
總結(jié)和展望
在進(jìn)行馬蜂窩會(huì)員體系架構(gòu)的搭建的實(shí)戰(zhàn)過(guò)程中，我們積累了很多有價(jià)值的經(jīng)驗(yàn)瞬测，其中感受最深的就是切忌盲目?jī)?yōu)化鸦致，系統(tǒng)層面上的重構(gòu)更要首先以業(yè)務(wù)為導(dǎo)向去關(guān)注核心框架的升級(jí)和技術(shù)體系的演進(jìn)，不要因?yàn)檫^(guò)度陷入技術(shù)細(xì)節(jié)而迷失方向涣楷。
今后，我們還將積極調(diào)研和應(yīng)用更多主流抗碰、前沿技術(shù)狮斗，比如會(huì)員標(biāo)簽、用戶畫(huà)像體系的引入弧蝇，真正把這些技術(shù)用好用活碳褒，使會(huì)員中心發(fā)揮更大價(jià)值。
本文作者：馬蜂窩電商會(huì)員項(xiàng)目研發(fā)團(tuán)隊(duì)看疗。
