20 September 2018

买赠业务架构演变

1.授权服务+会员产品买赠

1.负责非爱奇艺端的和爱奇艺端会员产品买赠的权益开通代理服务
2.模块划分:api(端上接口的同步调用);worker(异步任务)
3.访问量:单台qps100,10台机器

2.系统业务流程图

3.系统为什么要这么设计

1.买赠基于订单维度,和订单消息异步解耦,进行会员产品的买赠,以前的买赠方案平铺直序,代码耦合严重,不清晰,难扩展,考虑到后面还有很多需求,需要维护
2.因为每新增一种买赠,在原有大if else基础上操作,维护成本太高,提出一种解决方案,把共性的代码抽象出来,利用策略 + 模板双模式,把代码组件化,达到效果,易扩展,易维护,特殊逻辑采用插拔式,符合归一,开闭原则。
3.继续开发,发现买赠规则的条件判断,奖励规则可以继续抽象,考虑到java可以利用js语言的特性,ScriptEngineManager可以做到规则配置化,动态化
4.公共方法match条件,每次都需要访问数据库,考虑到买赠规则不多,启动定时任务放到内存中
5.因为系统发展,订单量增加,amq切换成rocketmq,抗堆积,易扩展,支持组消费,组和组互不影响。

4.业务痛点

1.任务工具打垮权益系统,不是分布式任务框架,任务量大的时候影响权益系统本身service的业务逻辑处理,可以对服务进行service和worker分组


blog comments powered by Disqus