为更好帮助商家的会员快速成长,保持用户活性,完善用户的成长体系,有赞用户中心-会员成长团队基于现有的业务场景,设计了一套较完备任务中心系统。同时也有很多通用技术组件能够落地。接下来本文会简单分享下这些常用的技术组件,抛砖引玉。
在开始之前我们会先提几个问题:
![eToqXD.png](https://imgchr.com/i/eToqXD)
![eToH1K.png](https://imgchr.com/i/eToH1K)
我们从现有的业务体系中,剥离出B端的配置中心和C端的任务处理中心,集合一些常用的系统组件,尽量做到接口原子化,可编排、能力内聚;在结合通用工具jar,是业务系统接入足够快速;同时设置了平台型通用配置,使用基于apollo的动态加载配置信息到本地缓存,达到不用发布应用,就可以快速接入新任务。![eTo7p6.png](https://imgchr.com/i/eTo7p6)
有赞虽然是一家saas公司,但是在有赞内部平台、商户、用户的概念是都有维护的,可以说三者相辅相成,不会独立出现。
![eToofx.png](https://imgchr.com/i/eToofx)
通用的合理的状态流转,可以快速定位区分C端用户的任务完成情况,失败和终止的业务可以依赖定时任务做任务完成重放,快速推进到完结,并发放奖励,规避异常给用户带来的奖励信息不同步的问题,保证系统内的一致性。![eToOne.png](https://imgchr.com/i/eToOne)
在任务中心落地中,很多场景需要控制任务的唯一幂等,多次发放不会重发等等。之前我们主要是通过db幂等表,插入业务唯一索引来保证幂等,但是需要数据库的事务保证,即幂等流水和业务要一起提交,失败即回滚。当使用到多库的场景时,业务系统每个库都要增加一张流水表,并且控制本分片内业务id和分片id一致,比较繁琐。
还有一部分内部系统使用分布式存储(比如redis),来保存业务请求记录。服务端在接收到请求后,用原子性的查询和保存操作(比如redis的setnx命令),来保证业务唯一流水落到存储中,在业务设置的超时时间前,控制业务流水的幂等。当发现重复流水时,按照一定的策略返回。
在任务中心系统落地时,同时保留了两种模式,并且还要考虑接入方依赖的存储的拓展性和快速接入。
通过基础的工具jar包,承载整个幂等组件逻辑,达到快速接入的目的,通过apollo可以动态推送相关配置,达到业务系统快速切换分支,随时线上应急。![eToX0H.png](https://imgchr.com/i/eToX0H)
由于多个任务中,很多基础组件能力都可以直接复用。比如发放奖励中:发放成长值、发放积分、优惠券等等,很多任务都有相同的逻辑,为了达到无需重复开发,新任务快速接入的目的。
我们开发了一套基于db+xml配置流程编排引擎,可以快速编排已有逻辑,减少重复开发工作。
编排还提供的基础能力:
![eToj7d.png](https://imgchr.com/i/eToj7d)
目前很多基础配置都是通过依赖配置文件,或者apollo的动态配置。
但是这两种方式都是有一定优缺点的:配置文件的方式,虽然存储容量没有限制,但是配置变更后,需要重启应用,比较复杂。而apollo开关的方式虽然可以动态变更,但是存储的配置信息很少,有一定长度限制。对于任务中心这种多任务平台型的配置,有一定影响。
所以最后使用了基于jvm+apollo的延时加载的策略,即保证了不用频繁发布,同时可以动态变更配置信息。
传统的同步日志记录,占用系统资源,并且由于任务中心的特性,C端任务完成流水信息会很多。 所以任务中心落地时转化为日志的异步流水事件,由单独的日志系统提供日志采集、上传、可视化、检索等通用能力。
本着可视化、配置化的原则,为了让外围接入更容易,同时减少内部开发量的原则。接下来我们还会去继续完善系统:
有你有赞,未来可期(附内推邮箱:sunchang@youzan.com,欢迎加入有赞业务中台-用户中心)预览