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

发布于:2019 年 8 月 24 日 08:00

基于通用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 命令),来保证业务唯一流水落到存储中,在业务设置的超时时间前,控制业务流水的幂等。当发现重复流水时,按照一定的策略返回。在任务中心系统落地时,同时保留了两种模式,并且还要考虑接入方依赖的存储的拓展性和快速接入。

3.1.2 幂等组件的规则

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

3.1.3 幂等组件的设计

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

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

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

由于多个任务中,很多基础组件能力都可以直接复用。比如发放奖励中:发放成长值、发放积分、优惠券等等,很多任务都有相同的逻辑,为了达到无需重复开发,新任务快速接入的目的。我们开发了一套基于 db+xml 配置流程编排引擎,可以快速编排已有逻辑,减少重复开发工作。

编排还提供的基础能力:

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

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

3.3 动态配置变更组件

目前很多基础配置都是通过依赖配置文件,或者 apollo 的动态配置。

但是这两种方式都是有一定优缺点的:配置文件的方式,虽然存储容量没有限制,但是配置变更后,需要重启应用,比较复杂。而 apollo 开关的方式虽然可以动态变更,但是存储的配置信息很少,有一定长度限制。对于任务中心这种多任务平台型的配置,有一定影响。

所以最后使用了基于 jvm+apollo 的延时加载的策略,即保证了不用频繁发布,同时可以动态变更配置信息。

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

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

四、未来,我们还在砥砺前行:

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

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

本文转载自公众号有赞 coder(ID:youzan_coder)

原文链接

https://mp.weixin.qq.com/s/O_Zlvx1XPVZWMRhZvi-lUg

阅读数:4355 发布于:2019 年 8 月 24 日 08:00

更多 语言 & 开发、设计模式、最佳实践 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 应⽤:检测 SKU 抠图与分类标注流程

    2020 年 7 月 16 日

  • 为什么需要消息队列?

    我们在单体应用里面需要用队列解决的问题,在分布式系统中大多都可以用消息队列来解决。

    2019 年 7 月 23 日

  • 探寻繁杂定时任务的解决方案:分布式任务调度系统

    本文介绍腾讯云分布式任务调度系统TCT如何实现任务调度的精准实时、稳定高效,以及任务的切分和编排。

    2020 年 5 月 21 日

  • 分布式任务调度平台的研究(下)

    分布式服务一般都要考虑高可用方案

    2020 年 2 月 10 日

  • 电商系统表设计优化案例分析

    以电商系统中的表结构设计为例,详解在设计表时都需要考虑哪些因素。

    2019 年 8 月 17 日

  • 商城个人中心页模块开发

    2019 年 11 月 29 日

  • 余昭辉:去哪儿网任务调度中心

    在大型系统中,任务调度是一项基础性的需求。对于一些需要重复、定时执行或者耗时比较长的任务经常会被剥离出来单独处理,而随着任务规模与复杂性的上升,任务调度系统也就随需而生。设计良好的任务调度系统具备可靠性及伸缩性,它可以管理并监控任务的执行流程,以保证任务的正确执行。去哪儿网的工程师余昭辉曾参与开发了去哪儿网的任务调度中心基础组件,InfoQ就任务调度中心对他进行了采访。

    2014 年 6 月 30 日

  • QQ 红包技术方案全解密

    自2015年春节以来,QQ春节红包经历了企业红包(2015年)、刷一刷红包(2016年)和AR红包(2017年)几个阶段,通过不断创新玩法,活跃度节节攀升,成为春节一大玩点,给火红的春节带来一抹亮色。2017年除夕,AR红包、刷一刷红包再创新高,抢红包用户数达 3.42 亿,共刷出红包 37.77 亿个。 那么,QQ红包的技术方案究竟是怎样的?其整体架构如何?重要的系统是如何设计的?为了保证用户的体验,手Q终端做了哪些优化?今年的QQ红包又做了哪些新的尝试,遇到的问题是如何解决的呢?本文将从架构开始,到手Q终端优化,再到个性化红包和AR新玩法,为大家全面解密QQ红包技术方案。

    2017 年 4 月 17 日

  • 去哪儿网支付系统架构演进

    去哪儿支付系统自2011年搭建以来,在五年的时间里逐渐从一个高耦合的单一系统发展为众多子系统组成的高并发、高可用、支持多种交易支付业务的分布式系统。业务从最初的非代收到现在多种非代收、代收场景的支持,B2B业务的从无到有,支付方式从单一网银支付到现在银行卡、拿去花、代金券、红包、立减、积分、趣游宝等多种的组合,订单从单笔支付到多个订单同时支付和多次付款。下面对整体的演变过程进行简单的介绍。

    2017 年 1 月 9 日

  • 动态调整的基础 —— 配置中心

    不要写死,一个永恒的话题。动态化,也是一个涵盖了界面,功能,数据,配置诸多方面的一个宽泛话题。这篇文章就跟大家聊一聊手机天猫在配置动态化上的心路历程。

    2016 年 5 月 8 日