导读:年初的一个晨会上,用户增长负责人湘翁问我说:一个周内上线50个增长策略,技术兄弟们能做到么?
闲鱼的卖家都是普通小卖家,而非专业的B类商家。因此无法统一组织起来参加营销活动带来买家活跃。这一点是与淘宝/天猫的差别。
我们目前DAU已经突破到2000W,如何承接好这么大体量的用户,对运营同学是个很大的考验。
研发周期长。一开始,我们先用最快的实现方案来做,主要是为了快速验证规则策略的有效性,并没有做大而全的设计,每个需求都是case by case地写代码来实现。那么从开始开发真正能到上线,很可能就是三周,主要因为客户端发版是有窗口的。
运营效率慢。因为上线慢,导致获取业务数据后再分析效果就很晚了,然后还要根据数据再去做调整那就更晚了。这样算下来,一年也上不了几个规则策略。
SQL已经是语义完备的编程语言,不用再去做额外的语法设计。
SQL是一门很简单的语言,不需要花太多时间就可以掌握。
我们闲鱼的运营同学会写SQL,这样会让上线效率更快。
增加了条件表达式。可以支持更丰富更复杂的事件描述,也就能支撑更多的业务场景。
增加了时间表达式。通过WITHIN关键字,定义了一个时间窗口。通过HAVING之后跟的DISTINCT等关键字,就可以针对时间窗口内的事件进行聚合计算。使用新的方案,就可以很好地解决上述C2C业务上的规则描述问题。
扩展性强。遵循了业界标准,与具体业务的输入和输出无关,便于推广。
业务应用。在这里是我们整个系统的业务方,已经在多个业务场景下做了落地。
任务投放。这里是对业务应用层提供DSL声明和投放的能力,能可以做简单的圈人,以及与用户触达模块的关联。
用户触达。这个模块用于接收来EPL引擎计算的结果,根据关联的Action来实施动作。同时这个模块也可以独立对业务应用提供服务,即各个业务方可以拥有自己的逻辑,通过用户触达模块来触达用户。
EPL引擎。目前已经实现了云上的解析和结算。用于接收来自任务投放里声明的DSL,再去解析和运行在Blink上。
事件采集。负责通过服务端日志和行为打点里采集行为事件,并归一化地输出给EPL引擎。
高性能。整条链路计算完毕平均耗时5秒。
高可靠。依托于Blink的高可靠性,承载了双十一上亿的流量。
对实时性要求高
强运营主导规则
能够用SQL表达
整条链路计算完毕平均需要5秒左右。如果放到对实时性要求更高的游戏任务场景下时,这就无法满足了。
闲鱼的业务已经连年保持了高增长,未来可能会面对比当下翻三番的用户流量,如果所有计算依然全部放在云上,则对云上的算力消耗是个极大的挑战。
目前我们的设计上,是没有算法接入的,只有简单的圈人。而为了让规则的投放更加精准,进而提升规则对用户的有效性,是需要与算法结合的。
闲鱼团队是Flutter+Dart FaaS前后端一体化新技术的行业领军者,就是现在!客户端/服务端java/架构/前端/质量工程师面向社会招聘,base杭州阿里巴巴西溪园区,一起做有创想空间的社区产品、做深度顶级的开源项目,一起拓展技术边界成就极致!
*投喂简历给小闲鱼→guicai.gxy@alibaba-inc.com