闲鱼把各种玩法做成了一个平台：哆啦A梦

原创齐悟闲鱼技术

玩法平台背景

在闲鱼内我们把供给用户的闲鱼红包、支付宝红包、包邮券、宝卡等统称为用户权益。是闲鱼用户运营的重要策略，在拉新、留存、促活、裂变等方面都展现了其重要价值。在阿里内部管理权益的平台是拉菲，拉菲对外提供概率抽奖和领奖两种能力。各个业务使用方根据自己的诉求结合拉菲的能力，定制自己业务侧玩法，基于此建立了闲鱼权益玩法平台——哆啦A梦。

痛点分析

早期闲鱼的营销活动有两个重要特点：低频、人工，闲鱼是c2c的二手交易平台，营销活动本身就不多，每年不超过10次。每次营销活动玩法都是简单的抽奖玩法，给中奖用户发奖，需要运营同学逐个联系然后发放权益。随着业务发展集团有了权益相关的平台，其中包括wlp、mrp、拉菲到最终统一的权益平台拉菲2，权益平台的目的就是收敛集团内的权益，简单的理解平台不生产权益、只是权益的搬运工。随着业务的丰富，平台也有了更丰富的权益包括支付宝红包、淘宝单品优惠券、淘宝店铺优惠券、淘宝满减券、闲鱼红包、包邮券等。闲鱼也更关注业务玩法产生了大转盘、翻牌子、九宫格等玩法。随着闲鱼业务的发展在玩法侧有了更多诉求产生了百币夺宝、PK赛、排行榜、签到领币等更复杂的玩法。同时也暴露出了越来越多的问题。

开发侧遇到的问题：

开发周期长，活动业务层并不复杂，但每次活动都要考虑系统安全性、稳定性、数据一致性问题。
发现和定位问题难，缺少监控和对账体系，导致活动中难以及时发现问题，往往是后知后觉。

运营侧遇到的问题：

配置流程复杂，从前端页面配置到活动规则配置分散在多个系统。
沟通成本高，开发侧概念不统一，每次运营对接不同的开发都要接受一套概念。
活动效果无法实时关注，往往都是活动后才开始跑效果数据。

测试侧遇到的问题：

测试成本高，在测试时需要构造多个测试用例条件的账户，用来测试不同情况，此时往往需要开发共同配合。
反馈链路长，黑盒测试时遇到问题，但是不清楚具体问题是什么，该如何保持现场复现。

对于开发来最难以接受的事情莫过于重复，如果再给我一次机会，我一定要搞一个玩法平台，就这样闲鱼玩法平台来了。根据上面总结的问题，给玩法平台一期定下了三个目标：

沉淀能力可复用，拒绝重复开发，把可复用的能力沉淀
运营易用，为运营提供可配置平台，可自己完成活动配置上线
快速发现、定位、反馈问题，为测试提供测试工具

玩法平台1.0

一个平台怎么也要有个名字，大家刚开始希望可以给力的解决闲鱼玩法中遇到的问题，所以起了一个黑土味的名字——奥利给，后面想了想玩法平台主要追逐的是玩法，哆啦A梦的口袋里面什么都可以变出来，与玩法平台刚好契合，所以后面又改为——哆啦A梦。

业务架构

哆啦A梦的业务目标就是收敛闲鱼内的所有权益相关的玩法，所以很多玩法都是基于已有的系统建立的。如下图所示是哆啦A梦的整个业务架构主要分了三个层次，最底层是外部依赖、中间层是系统核心、最上层是业务。

外部系统依赖：哆啦A梦结合业务规则与这些已有的系统能力，开发了多种业务玩法。其中任务系统是玩法的一个重要依赖，其提供了父子任务、组合任务、有序任务等任务编排的能力；人群系统是进行用户身份验证的重要依赖，其提供了人群动态增加、删除、验证的能力；用户行为系统是进行用户行为采集与反馈的系统，其提供了行为编排与实时反馈的能力。个性推荐系统是对不同用户提供个性化的权益系统；对账系统保证系统数据的一致性；用户通知系统提供实时触达通知能力。

系统核心层：哆啦A梦用活动的概念把拉菲玩法和业务规则进行封装，运营只需要通过简单的配置即可完成活动配置，同时哆啦A梦在活动进行中提供了日志采集、流量监控、数据对账、数据报表的基础能力保障活动的稳定安全运行。

业务层：前端提供了多种玩法组件，运营同学配置完活动后可以直接选择可使用的玩法组件，给用户呈现不同的玩法。

运营配置平台

配置平台主要面向运营同学，目标是运营可以不依赖开发，通过配置平台就可以完成一个活动上线，在哆啦A梦中一次营销称为一个活动，在一个活动中会有多种业务规则，每个业务规则中对应一个拉菲权益，举个例子：运营做一次营销活动分别为闲鱼的男性用户发放一种权益，为女性发放一种权益，为未知性别用户发放一种权益，那么该活动中将会对应三个业务规则，分别是男性、女性、未知性别。一个用户抽取权益时，首先判断其性别，然后获取对应规则下的权益。当一个用户符合多个规则时，将会利用规则决策来决定用户具体获取哪个规则下面的权益。

业务决策有两种方式一种是按照权重进行规则决策，一种是算法决策；算法决策目的是权益效率最大化。

开发基础链路

营销活动基础链路主要关心的是流量和安全，流量是对整个系统性能的一个考验，安全是对整个活动业务规则的考验。流量包含正常流量和非法流量，正常流量需要关注活动开始瞬时流量和活动的峰值流量，做好系统扩容和限流保证活动期间服务器不被打挂，非法流量需要关注类似爬虫的机器流量，需要在进入业务层前进行拦截，防止干扰正常的用户。其中安全侧包含业务逻辑和非业务逻辑，业务逻辑包括周期内限制中奖次数，业务规则条件等，非业务逻辑需要着重关注黑灰产的非法用户，其中包括同人账号、同设备账号、同IP账号等，防止活动权益被刷。解决方案如下：

其中霸下校验是集团提供的流量清洗工具，包含DDoS攻击防护、CC攻击防护、Web攻击防护、批量机器行为防御；限流校验接入是集团提供的可以设定单机流量和总流量，超过阈值则采用拒绝访问的限流平台；安全校验接入集团的RMB系统，对同人账号、同设备、同IP的账号进行防控；单用户并发校验利用全局分布式锁，保证同一个账号只能有一个请求进入业务逻辑层，防止同用户并发产生问题；活动码校验，其中活动码是根据活动、时间、用户三个维度生成，利用Base64简单加密和解码进行验证；实时对账主要关注业务规则，对每一个中奖用户进行实时的规则校验，防止规则编码漏洞。小时离线对账主要关注数量级，防止运营侧的配置错误导致奖品的超发。

测试工具

测试工具是面向测试同学的，需要解决两个问题：第一能快速的构造符合测试用例的用户，第二：快速发现、定位、反馈问题。

其中测试用例是依据运营设置的营销规则产生的，如果能灵活的给测试用户添加或者跳过规则校验即可满足测试同学的邀请，本文采用的是白名单的方法去解决构造用户测试用例，当用户需要校验规则时添加到校验的白名单，当用户需要跳过校验时候则提交跳过的白名单，当不添加白名单时走正常的业务校验逻辑。

发现问题方案本文采用的是通过在服务中打异常日志并日志监控系统完成，定位问题时日志打的越细越能快速的定位问题，但同时日志越细代表打的日志就越多，这对系统开销又很大，所以如何做取舍是个关键的问题，本文在解决这个问题上，产出了详细日志和粗略日志两套日志方案，首先把整个抽奖流程分为如下几个步骤如下图所示：

对于线上的正常用户只需要打印最终成功日志和异常日志即可这里采用的是粗略日志，对于测试用户打印每个步骤的详细日志这里采用的是详细日志。最终解决方案流程图如下：

首先测试用户在调用抽奖接口前，可以通过扫码的方式加入白名单，在调用抽奖接口的流程中进行规则校验时，会对该用户进行白名单校验，白名单用户是个复杂对象里面包含了是否校验各个规则，通过校验后最终调用抽奖接口。同时利用Spring的AOP能力在调用抽奖的每个阶段都进行日志的打印，在打印的时候先校验是否是白名单用户，如果是白名单用户则打印每个步骤的详细入参出参，如果是正常线上用户则只需打印异常节点和最终的结果节点即可。为了提高校验白名单的性能，白名单用户信息是存储在内存中的，多台机器的白名单配置同步利用的是Diamond(外部zookeeper同样具有该能力)。

业务效果

上面简单的介绍了整个系统的业务架构和一些主要问题的解决方案，下面主要展示一下使用哆啦A梦平台承接的几种玩法：

玩法平台持续探索

本文通过对日常营销活动中遇到的问题进行整理，针对这些问题提出相应的解法，进而形成一个业务侧的玩法平台。限于篇幅限制本文主要介绍了系统的整体架构和几个重点解决的问题，对于系统中沉淀出的玩法、测试工具的实现细节、安全体系单独进行分享。后面规划中期望可以把玩法和玩法平台解耦开，作为一种玩法能力对外输出。

继续滑动看下一个