转载

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

前言

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

在开始之前我们会先提几个问题：

任务中心对于普通商户有什么用处？
如何实现任务中心，做到快速接入，扩展性好？
有哪些技术可以结合任务中心一起落地？

1.1 我们内部的一些黑话

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

一、为什么要做任务中心？

1.1 出发点

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

1.2 任务中心的目标

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

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

二、我们是如何实现的？

2.1 我们的技术方案

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

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

2.2 如何串联平台、商户、用户

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

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

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

2.3 我们还提供了哪些能力

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

2.4 任务的常用状态

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

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

三、我们使用了哪些核心技术组件？

3.1 幂等控制组件

3.1.1 为什么要要使用幂等组件

在任务中心落地中，很多场景需要控制任务的唯一幂等，多次发放不会重发等等。之前我们主要是通过 db 幂等表，插入业务唯一索引来保证幂等，但是需要数据库的事务保证，即幂等流水和业务要一起提交，失败即回滚。当使用到多库的场景时，业务系统每个库都要增加一张流水表，并且控制本分片内业务 id 和分片 id 一致，比较繁琐。还有一部分内部系统使用分布式存储 (比如 redis)，来保存业务请求记录。服务端在接收到请求后，用原子性的查询和保存操作 (比如 redis 的 setnx 命令)，来保证业务唯一流水落到存储中，在业务设置的超时时间前，控制业务流水的幂等。当发现重复流水时，按照一定的策略返回。在任务中心系统落地时，同时保留了两种模式，并且还要考虑接入方依赖的存储的拓展性和快速接入。