前言
为更好帮助商家的会员快速成长, 保持用户活性, 完善用户的成长体系, 有赞用户中心 - 会员成长团队基于现有的业务场景, 设计了一套较完备任务中心系统. 同时也有很多通用技术组件能够落地. 接下来本文会简单分享下这些常用的技术组件, 抛砖引玉.
在开始之前我们会先提几个问题:
任务中心对于普通商户有什么用处?
如何实现任务中心, 做到快速接入, 扩展性好?
有哪些技术可以结合任务中心一起落地?
1.1 我们内部的一些黑话
一, 为什么要做任务中心?
1.1 出发点
用户激活: 提升用户体验, 增加客户活跃, 方便商户进行用户信息采集, 完善自己的信息网.
提高留存: 引导客户每日参与任务, 通过会员体系 + 积分成长值奖励, 提高用户粘性.
提高用户复购和客单价: 设置购买任务和结合积分购买等特权.
老带新传播: 通过拉新任务或者拼团任务等活动, 持续拉新.
1.2 任务中心的目标
B 端: 商户可视的任务配置中心, 方便管理控制任务.
C 端: 用户领取完成任务, 异步或同步处理完成, 提供: 定时任务, 阶段任务.
接入, 使用方: 快速可视化接入, 任务完成回执简单.
系统本身: 对于新任务接入, 可拓展性, 尽量保证主流程改动最小.
二, 我们是如何实现的?
2.1 我们的技术方案
我们从现有的业务体系中, 剥离出 B 端的配置中心和 C 端的任务处理中心, 集合一些常用的系统组件, 尽量做到接口原子化, 可编排, 能力内聚; 在结合通用工具 jar, 是业务系统接入足够快速; 同时设置了平台型通用配置, 使用基于 apollo 的动态加载配置信息到本地缓存, 达到不用发布应用, 就可以快速接入新任务.
2.2 如何串联平台, 商户, 用户
有赞虽然是一家 saas 公司, 但是在有赞内部平台, 商户, 用户的概念是都有维护的, 可以说三者相辅相成, 不会独立出现.
平台侧可以通过后台系统快速接入, 给产品同学进行审批和配置落地.
商户端可以在页面, 快速配置任务信息和任务奖励.
给业务方提供多种任务快速接入方式, 通用的任务调度完成以及商户维度的通用奖励发放能力.
2.3 我们还提供了哪些能力
2.4 任务的常用状态
通用的合理的状态流转, 可以快速定位区分 C 端用户的任务完成情况, 失败和终止的业务可以依赖定时任务做任务完成重放, 快速推进到完结, 并发放奖励, 规避异常给用户带来的奖励信息不同步的问题, 保证系统内的一致性.
三, 我们使用了哪些核心技术组件?
3.1 幂等控制组件
3.1.1 为什么要要使用幂等组件
在任务中心落地中, 很多场景需要控制任务的唯一幂等, 多次发放不会重发等等. 之前我们主要是通过 db 幂等表, 插入业务唯一索引来保证幂等, 但是需要数据库的事务保证, 即幂等流水和业务要一起提交, 失败即回滚. 当使用到多库的场景时, 业务系统每个库都要增加一张流水表, 并且控制本分片内业务 id 和分片 id 一致, 比较繁琐. 还有一部分内部系统使用分布式存储 (比如 Redis), 来保存业务请求记录. 服务端在接收到请求后, 用原子性的查询和保存操作 (比如 Redis 的 setnx 命令), 来保证业务唯一流水落到存储中, 在业务设置的超时时间前, 控制业务流水的幂等. 当发现重复流水时, 按照一定的策略返回. 在任务中心系统落地时, 同时保留了两种模式, 并且还要考虑接入方依赖的存储的拓展性和快速接入.
3.1.2 幂等组件的规则
幂等使用支持注解方式快速接入 +spEL 表达式拼接幂等入参信息.
基于 apollo 的动态配置推送.
幂等存储策略:
1. 缓存 Redis 存储 (优先)2.MySQL 存储等
幂等拒绝策略:
1. 多次返回相同结果 2. 返回幂等码 3. 抛出异常等
3.1.3 幂等组件的设计
通过基础的工具 jar 包, 承载整个幂等组件逻辑, 达到快速接入的目的, 通过 apollo 可以动态推送相关配置, 达到业务系统快速切换分支, 随时线上应急.
3.2 集成了通用缓存能力流程编排组件
由于多个任务中, 很多基础组件能力都可以直接复用. 比如发放奖励中: 发放成长值, 发放积分, 优惠券等等, 很多任务都有相同的逻辑, 为了达到无需重复开发, 新任务快速接入的目的. 我们开发了一套基于 db+xml 配置流程编排引擎, 可以快速编排已有逻辑, 减少重复开发工作.
编排还提供的基础能力:
持续开发基于热加载的模板动态加载机制. 进一步增加流程的动态可配置能力.
同时在通用模板中, 实现了缓存通用逻辑以及热点缓存功能, 在大促或者商家有营销活动时, 任务中心也可以稳定支持.
3.3 动态配置变更组件
目前很多基础配置都是通过依赖配置文件, 或者 apollo 的动态配置.
但是这两种方式都是有一定优缺点的: 配置文件的方式, 虽然存储容量没有限制, 但是配置变更后, 需要重启应用, 比较复杂. 而 apollo 开关的方式虽然可以动态变更, 但是存储的配置信息很少, 有一定长度限制. 对于任务中心这种多任务平台型的配置, 有一定影响.
所以最后使用了基于 jvm+apollo 的延时加载的策略, 即保证了不用频繁发布, 同时可以动态变更配置信息.
3.4 独立的异步日志流水记录
传统的同步日志记录, 占用系统资源, 并且由于任务中心的特性, C 端任务完成流水信息会很多. 所以任务中心落地时转化为日志的异步流水事件, 由单独的日志系统提供日志采集, 上传, 可视化, 检索等通用能力.
四, 未来, 我们还在砥砺前行:
本着可视化, 配置化的原则, 为了让外围接入更容易, 同时减少内部开发量的原则. 接下来我们还会去继续完善系统:
任务中心运维产品化 (在建中): 单独开发的一套产品层应用, 使用可视化的页面后台管理. 方便业务接入和日常运维. 可以独立通过页面完成配置 + 上线.
基于回调和配置的扩展点 + 流程共建 (在建中): 通过扩展点共建方式, 将流程编排的能力, 暴露给内外部的开发者, 完成任务中心的共建.
本文转载自公众号有赞 coder(ID:youzan_coder).
来源: http://www.tuicool.com/articles/eUniyqA