基于通用jar、动态配置、组件编排的会员任务中心系统设计

1、聊聊本文想说什么：

为更好帮助商家的会员快速成长，保持用户活性，完善用户的成长体系，有赞用户中心-会员成长团队基于现有的业务场景，设计了一套较完备任务中心系统。同时也有不少通用技术组件可以落地。接下来本文会简单分享下这些经常使用的技术组件，抛砖引玉。

在开始以前咱们会先提几个问题：

• 1.任务中心对于普通商户有什么用处？
• 2.如何实现任务中心，作到快速接入，扩展性好？
• 3.有哪些技术能够结合任务中心一块儿落地？

1.1 咱们内部的一些黑话

#2、为何要作任务中心？

2.1 任务中心的出发点：

• a、用户激活：提高用户体验，增长客户活跃，方便商户进行用户信息采集，完善本身的信息网。
• b、提升留存：引导客户每日参与任务，经过会员体系+积分红长值奖励，提升用户粘性。
• c、提升用户复购和客单价：设置购买任务和结合积分购买等特权。
• d、老带新传播：经过拉新任务或者拼团任务等活动，持续拉新。

2.2 任务中心的目标：

• B端： 商户可视的任务配置中心，方便管理控制任务。
• C端：用户领取完成任务，异步或同步处理完成，提供：定时任务、阶段任务。
• 接入、使用方：快速可视化接入，任务完成回执简单。
• 系统自己：对于新任务接入，可拓展性，尽可能保证主流程改动最小。

3、咱们是如何实现的？

3.1 咱们的技术方案

咱们从现有的业务体系中，剥离出B端的配置中心和C端的任务处理中心，集合一些经常使用的系统组件，尽可能作到接口原子化，可编排、能力内聚；在结合通用工具jar，是业务系统接入足够快速；同时设置了平台型通用配置，使用基于apollo的动态加载配置信息到本地缓存，达到不用发布应用，就能够快速接入新任务。

3.2 如何串联平台、商户、用户？

有赞虽然是一家saas公司，可是在有赞内部平台、商户、用户的概念是都有维护的，能够说三者相辅相成，不会独立出现。

• 1.平台侧能够经过后台系统快速接入，给产品同窗进行审批和配置落地。
• 2.商户端能够在页面，快速配置任务信息和任务奖励。
• 3.给业务方提供多种任务快速接入方式，通用的任务调度完成以及商户维度的通用奖励发放能力。

  

3.2 咱们还提供了哪些能力？

3.3 任务的经常使用状态

通用的合理的状态流转，能够快速定位区分C端用户的任务完成状况，失败和终止的业务能够依赖定时任务作任务完成重放，快速推动到完结，并发放奖励，规避异常给用户带来的奖励信息不一样步的问题，保证系统内的一致性。

4、咱们使用了哪些核心技术组件

4.1 幂等控制组件

4.1.1 为何要要使用幂等组件

在任务中心落地中，不少场景须要控制任务的惟一幂等，屡次发放不会重发等等。以前咱们主要是经过db幂等表，插入业务惟一索引来保证幂等，可是须要数据库的事务保证，即幂等流水和业务要一块儿提交，失败即回滚。当使用到多库的场景时，业务系统每一个库都要增长一张流水表，而且控制本分片内业务id和分片id一致，比较繁琐。

还有一部份内部系统使用分布式存储(好比redis)，来保存业务请求记录。服务端在接收到请求后，用原子性的查询和保存操做(好比redis的setnx命令)，来保证业务惟一流水落到存储中，在业务设置的超时时间前，控制业务流水的幂等。当发现重复流水时，按照必定的策略返回。

在任务中心系统落地时，同时保留了两种模式，而且还要考虑接入方依赖的存储的拓展性和快速接入。

4.1.2 幂等组件的规则

• 幂等使用支持注解方式快速接入+spEL表达式拼接幂等入参信息。
• 基于apollo的动态配置推送。
• 幂等存储策略:
  • 1.缓存redis存储（优先）2.mysql存储 等
• 幂等拒绝策略:
  • 1.屡次返回相同结果 2.返回幂等码 3.抛出异常 等

4.1.3 幂等组件的设计

经过基础的工具jar包，承载整个幂等组件逻辑，达到快速接入的目的，经过apollo能够动态推送相关配置，达到业务系统快速切换分支，随时线上应急。

4.2 集成了通用缓存能力流程编排组件

因为多个任务中，不少基础组件能力均可以直接复用。好比发放奖励中：发放成长值、发放积分、优惠券等等，不少任务都有相同的逻辑，为了达到无需重复开发，新任务快速接入的目的。

咱们开发了一套基于db+xml配置流程编排引擎，能够快速编排已有逻辑，减小重复开发工做。

编排还提供的基础能力：

• 1.持续开发基于热加载的模板动态加载机制。进一步增长流程的动态可配置能力。
• 2.同时在通用模板中，实现了缓存通用逻辑以及热点缓存功能，在大促或者商家有营销活动时，任务中心也能够稳定支持。

4.3 动态配置变动组件

目前不少基础配置都是经过依赖配置文件，或者apollo的动态配置。

可是这两种方式都是有必定优缺点的：配置文件的方式，虽然存储容量没有限制，可是配置变动后，须要重启应用，比较复杂。而apollo开关的方式虽然能够动态变动，可是存储的配置信息不多，有必定长度限制。对于任务中心这种多任务平台型的配置，有必定影响。

因此最后使用了基于jvm+apollo的延时加载的策略，即保证了不用频繁发布，同时能够动态变动配置信息。

4.4 独立的异步日志流水记录

传统的同步日志记录，占用系统资源，而且因为任务中心的特性，C端任务完成流水信息会不少。 因此任务中心落地时转化为日志的异步流水事件，由单独的日志系统提供日志采集、上传、可视化、检索等通用能力。

5、将来，咱们还在砥砺前行：

本着可视化、配置化的原则，为了让外围接入更容易，同时减小内部开发量的原则。接下来咱们还会去继续完善系统：

• 1.任务中心运维产品化（在建中）：单独开发的一套产品层应用，使用可视化的页面后台管理。方便业务接入和平常运维。能够独立经过页面完成配置+上线。
• 2.基于回调和配置的扩展点+流程共建（在建中）：经过扩展点共建方式，将流程编排的能力，暴露给内外部的开发者，完成任务中心的共建。

有你有赞，将来可期(附内推邮箱：sunchang@youzan.com，欢迎加入有赞业务中台-用户中心） 预览