vivo商城促销系统架构设计与实践-概览篇
source link: https://my.oschina.net/vivotech/blog/5114555
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
随着商城业务渠道不断扩展,促销玩法不断增多,原商城v2.0架构已经无法满足不断增加的活动玩法,需要进行促销系统的独立建设,与商城解耦,提供纯粹的商城营销活动玩法支撑能力。
我们将分系列来介绍vivo商城促销系统建设的过程中遇到的问题和解决方案,分享架构设计经验。
二、系统框架
2.1 业务梳理
在介绍业务架构前我们先简单了解下vivo商城促销系统业务能力建设历程,对现促销能力进行梳理回顾。在商城v2.0中促销功能存在以下问题:
1. 促销模型不够抽象,维护混乱,没有独立的活动库存;
2. 混乱的活动共融互斥关系管理,缺乏统一的促销计价能力。
商城核心交易链路中商详页、购物车、下单这三块关于计价逻辑是分开独立维护的,没有统一,如下图所示。显然随着促销优惠的增加或者玩法的变动,商城侧业务重复开发量会显著加大。
(图2-1. 促销计价统一前)
3. 促销性能无法满足活动量级,往往会影响商城主站的性能。
因与商城系统耦合,无法提供针对性的性能优化,造成系统无法支撑越来越频繁的大流量场景下大促活动。
基于这些痛点问题,我们一期完成促销系统的独立,与商城解耦,搭建出促销系统核心能力:
优惠活动管理
对所有优惠活动抽象出统一的优惠模型和配置管理界面,提供活动编辑、修改、查询及数据统计等功能。并独立出统一的活动库存管理,便于活动资源的统一把控。
促销计价
基于高度灵活、抽象化的计价引擎能力,通过定义分层计价的促销计价模型,制定统一的优惠叠加规则与计价流程,实现vivo商城促销计价能力的建设。推动完成vivo商城所有核心链路接入促销计价,实现全链路优惠价格计算的统一,如下图:
(图2-2. 促销计价统一后)
随着一期促销系统核心能力的完成,极大的满足了业务需要,各类优惠玩法随之增多。但伴随而来的就是各种运营痛点:
-
维护的促销活动无法提前点检,检查活动效果是否符合预期;
-
随着优惠玩法的增多,一个商品所能享受的优惠越来越多,配置也越来越复杂,极易配置错误造成线上事故;
为此我们开始促销系统二期的能力建设,着重解决以上运营痛点:
-
提供时光穿越功能,实现用户能够“穿越”至未来某个时间点,从而实现促销活动的提前点检;
-
提供价格监控功能,结合「商城营销价格能力矩阵」规划的能力,通过事前/事中/事后多维度监控措施,来“降低出错概率,出错能及时止损”。
2.2 促销与优惠券
促销的主要目的就是向用户传递商品的各种优惠信息,提供优惠利益,吸引用户购买,从而起到促活拉新、提高销量的目的。从这种角度来看,优惠券也属于促销的一部分。
但因一些原因vivo商城促销系统独立过程中,并没有与促销系统放一块:
-
首先,优惠券系统在商城v2.0时就已独立,已经对接很多上游业务,已经是成熟的中台系统;
-
再者,就是优惠券也有相较与其它促销优惠的业务特殊性,如有发券、领券能力。
在考虑设计改造成本就未将优惠券包括在促销系统能力范畴,但优惠券毕竟也是商品价格优惠的一部分,因此促销计价需要依赖优惠券系统提供券优惠的能力。
2.3 业务架构&流程
至此我们也就梳理出整个促销系统的大概能力矩阵,整体架构设计如下:
(图2-3. 促销系统架构)
而随着促销系统独立,整个商城购物流程与促销系统的关系如下:
(图2-4. 最新商城购物流程)
三、技术挑战
作为中台能力系统,促销系统面临的技术挑战包括以下几方面:
-
面对复杂多变的促销玩法、优惠叠加规则,如何让系统具备可扩展性,满足日益多变的优惠需求,提升开发与运营效率。
-
面对新品发布、双11大为客户等大流量场景,如何满足高并发场景下的高性能要求。
-
面对来自上游业务方的不可信调用,以及下游依赖方的不可靠服务等复杂系统环境,如何提升系统整体的稳定性,保障系统的高可用。
我们结合自身业务特点,梳理出一些技术解决方案。
3.1 可扩展性
扩展性提升主要体现在两块:
-
优惠模型的定义,对所有优惠活动抽象出统一的优惠模型和配置管理界面;
-
促销计价引擎的建立,计价模型的统一。
相关的详细设计内容,会有后续文章进行说明。
3.2 高并发/高性能
缓存
缓存几乎就是解决性能问题的“银弹”,在促销系统中也大量使用缓存进行性能提升,包括使用redis缓存与本地缓存。而使用缓存就需要关注数据一致性问题,redis缓存还好解决,但本地缓存不就好处理了。因此本地缓存的使用要看业务场景,尽量是数据不经常变更且业务上能接受一定不一致的场景。
批量化
促销系统的业务场景属于典型的读多写少场景,而读的过程中对性能影响最大的就是IO操作,包括db、redis以及第三方远程调用。而对这些IO操作进行批量化改造,以空间换时间,减少IO交互次数也是性能优化的一大方案。
精简化/异步化
简化功能实现,将非核心任务进行异步化改造。如活动编辑后的缓存处理、资源预占后的消息同步、拼团状态流转的消息通知等等。
冷热分离
对于读多写少场景对性能影响最大的除了IO操作,还有就是数据量,在促销系统中也存在一些用户态数据,如优惠资源预占记录、用户拼团信息等。这些数据都具备时间属性,存在热尾效应,大部分情况下需要的都是最近的数据。针对这类场景对数据进行冷热分离是最佳选择。
3.3 系统稳定性
限流降级
基于公司的限流组件,对非核心的服务功能进行流量限制与服务降级,高并发场景下全力保障整体系统的核心服务
幂等性
所有接口均具备幂等性,避免业务方的网络超时重试造成的系统异常
熔断
使用Hystrix组件对外部系统的调用添加熔断保护,防止外部系统的故障造成整个促销系统的服务崩溃
监控和告警
通过配置日志平台的错误日志报警、调用链的服务分析告警,再加上公司各中间件和基础组件的监控告警功能,让我们能够第一时间发现系统异常
四、踩过的坑
4.1 Redis SCAN命令使用
在Redis缓存数据清除的处理过程中,存在部分缓存key是通过模糊匹配的方式进行查找并清除操作,底层依赖Redis SCAN命令。
SCAN命令是一个基于游标的迭代器,每次被调用之后都会向用户返回一个新的游标, 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数, 以此来延续之前的迭代过程。
对于使用KEYS命令,SCAN命令并不是一次性返回所有匹配结果,减少命令操作对Redis系统的阻塞风险。但并不是说SCAN命令就可以随便用,其实在大数据量场景下SCAN存在与KEYS命令一样的风险问题,极易造成Redis负载升高,响应变慢,进而影响整个系统的稳定性。
(图4-1 Redis负载升高)
(图4-2 Redis响应出现尖刺)
而解决方案就是:
-
优化Redis key设计,减少不必要的缓存key;
-
移除SCAN命令使用,通过精确匹配查找进行清除操作。
4.2 热点key问题
在促销系统中普遍使用redis缓存进行性能提升,缓存数据很多都是SKU商品维度。在新品发布、特定类型手机大促等业务场景下极容易产生热点Key问题。
热点Key具有聚集效应,会导致Redis集群内节点负载出现不均衡,进而造成整个系统不稳定。该问题是普通的机器扩容无法解决的。如下图某次线上摸排压测时redis负载情况:
常用的解决方案有两种:
-
散列方案:对Redis Key进行散列,平均分散到RedisCluster Nodes中,解决热点Key的聚集效应。
-
多级缓存方案:对热点Key增加使用本地缓存,最大限度加速访问性能,降低Redis节点负载。
我们是采用多级缓存方案,参照优秀的开源热点缓存框架,定制化扩展出一整套热点解决方案,支持热点探测 、本地缓存 、集群广播以及热点预热功能,做到准实时热点探测并将热点Key通知实例集群进行本地缓存,极大限度避免大量重复调用冲击分布式缓存,提升系统运行效率。
本篇属于vivo商城促销系统概览介绍篇,简单回顾了vivo商城促销系统业务能力建设历程及系统架构,并分享遇到的技术问题与解决方案。后续我们会对促销系统的核心功能模块(优惠活动管理、促销计价、价格监控和时光穿越)的设计实践进行逐个分享,敬请期待。
作者:vivo互联网官方商城开发团
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK