作者：閑魚技術-齊悟
玩法平台背景
在閑魚内我們把供給使用者的閑魚紅包、支付寶紅包、包郵券、寶卡等統稱為使用者權益。是閑魚使用者營運的重要政策，在拉新、留存、促活、裂變等方面都展現了其重要價值。在阿裡内部管理權益的平台是拉菲，拉菲對外提供機率抽獎和領獎兩種能力。各個業務使用方根據自己的訴求結合拉菲的能力，定制自己業務側玩法，基于此建立了閑魚權益玩法平台——哆啦A夢。
痛點分析
早期閑魚的營銷活動有兩個重要特點：低頻、人工，閑魚是c2c的二手交易平台，營銷活動本身就不多，每年不超過10次。每次營銷活動玩法都是簡單的抽獎玩法，給中獎使用者發獎，需要營運同學逐個聯系然後發放權益。随着業務發展集團有了權益相關的平台，其中包括wlp、mrp、拉菲到最終統一的權益平台拉菲2，權益平台的目的就是收斂集團内的權益，簡單的了解平台不生産權益、隻是權益的搬運工。随着業務的豐富，平台也有了更豐富的權益包括支付寶紅包、淘寶單品優惠券、淘寶店鋪優惠券、淘寶滿減券、閑魚紅包、包郵券等。閑魚也更關注業務玩法産生了大轉盤、翻牌子、九宮格等玩法。随着閑魚業務的發展在玩法側有了更多訴求産生了百币奪寶、PK賽、排行榜、簽到領币等更複雜的玩法。同時也暴露出了越來越多的問題。
開發側遇到的問題：
a.開發周期長，活動業務層并不複雜，但每次活動都要考慮系統安全性、穩定性、資料一緻性問題。
b.發現和定位問題難，缺少監控和對賬體系，導緻活動中難以及時發現問題，往往是後知後覺。
營運側遇到的問題：
a.配置流程複雜，從前端頁面配置到活動規則配置分散在多個系統。
b.溝通成本高，開發側概念不統一，每次營運對接不同的開發都要接受一套概念。
c.活動效果無法實時關注，往往都是活動後才開始跑效果資料。
測試側遇到的問題：
a.測試成本高，在測試時需要構造多個測試用例條件的賬戶，用來測試不同情況，此時往往需要開發共同配合。
b.回報鍊路長，黑盒測試時遇到問題，但是不清楚具體問題是什麼，該如何保持現場複現。
對于開發來最難以接受的事情莫過于重複，如果再給我一次機會，我一定要搞一個玩法平台，就這樣閑魚玩法平台來了。根據上面總結的問題，給玩法平台一期定下了三個目标：
1.沉澱能力可複用，拒絕重複開發，把可複用的能力沉澱
2.營運易用，為營運提供可配置平台，可自己完成活動配置上線
3.快速發現、定位、回報問題，為測試提供測試工具
玩法平台1.0
一個平台怎麼也要有個名字，大家剛開始希望可以給力的解決閑魚玩法中遇到的問題，是以起了一個黑土味的名字——奧利給，後面想了想玩法平台主要追逐的是玩法，哆啦A夢的口袋裡面什麼都可以變出來，與玩法平台剛好契合，是以後面又改為——哆啦A夢。
業務架構
哆啦A夢的業務目标就是收斂閑魚内的所有權益相關的玩法，是以很多玩法都是基于已有的系統建立的。如下圖所示是哆啦A夢的整個業務架構主要分了三個層次，最底層是外部依賴、中間層是系統核心、最上層是業務。
外部系統依賴：哆啦A夢結合業務規則與這些已有的系統能力，開發了多種業務玩法。其中任務系統是玩法的一個重要依賴，其提供了父子任務、組合任務、有序任務等任務編排的能力；人群系統是進行使用者身份驗證的重要依賴，其提供了人群動态增加、删除、驗證的能力；使用者行為系統是進行使用者行為采集與回報的系統，其提供了行為編排與實時回報的能力。個性推薦系統是對不同使用者提供個性化的權益系統；對賬系統保證系統資料的一緻性；使用者通知系統提供實時觸達通知能力。
系統核心層：哆啦A夢用活動的概念把拉菲玩法和業務規則進行封裝，營運隻需要通過簡單的配置即可完成活動配置，同時哆啦A夢在活動進行中提供了日志采集、流量監控、資料對賬、資料報表的基礎能力保障活動的穩定安全運作。
業務層：前端提供了多種玩法元件，營運同學配置完活動後可以直接選擇可使用的玩法元件，給使用者呈現不同的玩法。
解決方案
營運配置平台
配置平台主要面向營運同學，目标是營運可以不依賴開發，通過配置平台就可以完成一個活動上線，在哆啦A夢中一次營銷稱為一個活動，在一個活動中會有多種業務規則，每個業務規則中對應一個拉菲權益，舉個例子：營運做一次營銷活動分别為閑魚的男性使用者發放一種權益，為女性發放一種權益，為未知性别使用者發放一種權益，那麼該活動中将會對應三個業務規則，分别是男性、女性、未知性别。一個使用者抽取權益時，首先判斷其性别，然後擷取對應規則下的權益。當一個使用者符合多個規則時，将會利用規則決策來決定使用者具體擷取哪個規則下面的權益。
業務決策有兩種方式一種是按照權重進行規則決策，一種是算法決策；算法決策目的是權益效率最大化。
開發基礎鍊路
營銷活動基礎鍊路主要關心的是流量和安全，流量是對整個系統性能的一個考驗，安全是對整個活動業務規則的考驗。流量包含正常流量和非法流量，正常流量需要關注活動開始瞬時流量和活動的峰值流量，做好系統擴容和限流保證活動期間伺服器不被打挂，非法流量需要關注類似爬蟲的機器流量，需要在進入業務層前進行攔截，防止幹擾正常的使用者。其中安全側包含業務邏輯和非業務邏輯，業務邏輯包括周期内限制中獎次數，業務規則條件等，非業務邏輯需要着重關注黑灰産的非法使用者，其中包括同人賬号、同裝置賬号、同IP賬号等，防止活動權益被刷。解決方案如下：
其中霸下校驗是集團提供的流量清洗工具，包含DDoS攻擊防護、CC攻擊防護、Web攻擊防護、批量機器行為防禦；限流校驗接入是集團提供的可以設定單機流量和總流量，超過門檻值則采用拒絕通路的限流平台；安全校驗接入集團的RMB系統，對同人賬号、同裝置、同IP的賬号進行防控；單使用者并發校驗利用全局分布式鎖，保證同一個賬号隻能有一個請求進入業務邏輯層，防止同使用者并發産生問題；活動碼校驗，其中活動碼是根據活動、時間、使用者三個次元生成，利用Base64簡單加密和解碼進行驗證；實時對賬主要關注業務規則，對每一個中獎使用者進行實時的規則校驗，防止規則編碼漏洞。小時離線對賬主要關注數量級，防止營運側的配置錯誤導緻獎品的超發。
測試工具
測試工具是面向測試同學的，需要解決兩個問題：第一能快速的構造符合測試用例的使用者，第二：快速發現、定位、回報問題。
其中測試用例是依據營運設定的營銷規則産生的，如果能靈活的給測試使用者添加或者跳過規則校驗即可滿足測試同學的邀請，本文采用的是白名單的方法去解決構造使用者測試用例，當使用者需要校驗規則時添加到校驗的白名單，當使用者需要跳過校驗時候則送出跳過的白名單，當不添加白名單時走正常的業務校驗邏輯。
發現問題方案本文采用的是通過在服務中打異常日志并日志監控系統完成，定位問題時日志打的越細越能快速的定位問題，但同時日志越細代表打的日志就越多，這對系統開銷又很大，是以如何做取舍是個關鍵的問題，本文在解決這個問題上，産出了詳細日志和粗略日志兩套日志方案，首先把整個抽獎流程分為如下幾個步驟如下圖所示：
對于線上的正常使用者隻需要列印最終成功日志和異常日志即可這裡采用的是粗略日志，對于測試使用者列印每個步驟的詳細日志這裡采用的是詳細日志。最終解決方案流程圖如下：
首先測試使用者在調用抽獎接口前，可以通過掃碼的方式加入白名單，在調用抽獎接口的流程中進行規則校驗時，會對該使用者進行白名單校驗，白名單使用者是個複雜對象裡面包含了是否校驗各個規則，通過校驗後最終調用抽獎接口。同時利用Spring的AOP能力在調用抽獎的每個階段都進行日志的列印，在列印的時候先校驗是否是白名單使用者，如果是白名單使用者則列印每個步驟的詳細入參出參，如果是正常線上使用者則隻需列印異常節點和最終的結果節點即可。為了提高校驗白名單的性能，白名單使用者資訊是存儲在記憶體中的，多台機器的白名單配置同步利用的是Diamond(外部zookeeper同樣具有該能力)。
業務效果
上面簡單的介紹了整個系統的業務架構和一些主要問題的解決方案，下面主要展示一下使用哆啦A夢平台承接的幾種玩法：
| 任務玩法 | PK玩法 | 累計玩法 |
|---|---|---|
| 使用者通過任務清單頁到達具體任務頁面，完成任務後就可以得到對應的獎勵，在閑魚的閑魚币場景就使用了這種玩法模式，通過完成任務擷取閑魚币 | 營運營造兩個隊伍，讓使用者分别支援各自的隊伍，哪個隊伍勝利，哪個隊伍就會擷取對應的獎勵，在高達跑活動中使用的就是該玩法 | 使用者通過任務積累抽獎次數，然後進行抽獎，在二次元活動中使用的就是該玩法 |
| | | |
玩法平台持續探索
本文通過對日常營銷活動中遇到的問題進行整理，針對這些問題提出相應的解法，進而形成一個業務側的玩法平台。限于篇幅限制本文主要介紹了系統的整體架構和幾個重點解決的問題，對于系統中沉澱出的玩法、測試工具的實作細節、安全體系單獨進行分享。後面規劃中期望可以把玩法和玩法平台解耦開，作為一種玩法能力對外輸出。