一、前言

随着商城业务渠道不断扩展,促销玩法不断增多,原商城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互联网官方商城开发团

vivo商城促销系统架构设计与实践-概览篇的更多相关文章

  1. vivo 全球商城:优惠券系统架构设计与实践

    一.业务背景 优惠券是电商常见的营销手段,具有灵活的特点,既可以作为促销活动的载体,也是重要的引流入口.优惠券系统是vivo商城营销模块中一个重要组成部分,早在15年vivo商城还是单体应用时,优惠券 ...

  2. vivo 全球商城:商品系统架构设计与实践

    一.前言 随着用户量级的快速增长,vivo官方商城v1.0的单体架构逐渐暴露出弊端:模块愈发臃肿.开发效率低下.性能出现瓶颈.系统维护困难. 从2017年开始启动的v2.0架构升级,基于业务模块进行垂 ...

  3. vivo 服务端监控架构设计与实践

    一.业务背景 当今时代处在信息大爆发的时代,信息借助互联网的潮流在全球自由的流动,产生了各式各样的平台系统和软件系统,越来越多的业务也会导致系统的复杂性. 当核心业务出现了问题影响用户体验,开发人员没 ...

  4. Java生鲜电商平台-积分,优惠券,会员折扣,签到、预售、拼团、砍价、秒杀及抽奖等促销模块架构设计

    Java生鲜电商平台-积分,优惠券,会员折扣,签到.预售.拼团.砍价.秒杀及抽奖等促销模块架构设计 说明:本标题列举了所有目前社会上常见的促销方案,目前贴出实际的业务运营手段以及架构设计,包括业务说明 ...

  5. Slickflow.NET 开源工作流引擎基础介绍(六)--模块化架构设计和实践

    前言:在集成Slickflow.NET 引擎组件过程中,引擎组件需要将用户,角色等资源数据读取进来,供引擎内部调用:而企业客户都是有自己的组织架构模型,在引入模块化架构设计后,引擎组件的集成性更加友好 ...

  6. 基于Struts2,Spring4,Hibernate4框架的系统架构设计与示例系统实现

    笔者在大学中迷迷糊糊地度过了四年的光景,心中有那么一点目标,但总感觉找不到发力的方向. 在四年间,尝试写过代码结构糟糕,没有意义的课程设计,尝试捣鼓过Android开发,尝试探索过软件工程在实际开发中 ...

  7. HRMS(人力资源管理系统)-SaaS架构设计-概要设计实践

    一.开篇 前期我们针对架构准备阶段及需求分析这块我们写了2篇内容<HRMS(人力资源管理系统)-从单机应用到SaaS应用-架构分析(功能性.非功能性.关键约束)-上篇><HRMS(人 ...

  8. Atitit.数据库表的物理存储结构原理与架构设计与实践

    Atitit.数据库表的物理存储结构原理与架构设计与实践 1. Oracle和DB2数据库的存储模型如图: 1 1.1. 2. 表数据在块中的存储以及RowId信息3 2. 数据表的物理存储结构 自然 ...

  9. 新零售SaaS架构:商品系统架构设计

    SaaS产品就像一座冰山,冰山以上的部分是功能.数据(可见部分).用户界面,冰山以下是系统架构.完整的数据模型.开放体系.非功能性需求(扩展性.可维护性.性能.安全等). 短期内想要快速上线产品,可能 ...

随机推荐

  1. Jenkins 基础篇 - 基础设置

    站点设置 刚搭建好 Jenkins 环境,你还需要做一些简单设置,让我们的 Jenkins 看起来是这么一回事,特别是你要用于生产环境的时候.首先就是域名配置,如果你为 Jenkins 服务分配了一个 ...

  2. 面试遇到的坑CSS篇 1

    ------------恢复内容开始------------ 1.display: none和 visibility: hidden 代码 <style type="text/css& ...

  3. chardet模块

    import chardet chardet.detect(f.read())检测哪种编码

  4. 记一次 .NET 某外贸Web站 内存泄漏分析

    一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了 ...

  5. Ubuntu 配置本地源

    Ubuntu 配置本地源 操作系统 Ubuntu 20.04.2 LTS 一.挂载 iso 到本地 mount -t iso9660 -o loop /dev/sr0 /media/cdrom //- ...

  6. 002.Ansible之Inventory文件

    一 简介 在使用Ansible来批量管理主机的时候,通常我们需要先定义要管理哪些主机或者主机组,而这个用于管理主机与主机组的文件就叫做Inventory,也叫主机清单.该文件默认位于/etc/ansi ...

  7. 测usb读写

    dd if=/dev/sda of=/dev/null bs=1M count=1000每次测完 清一下 memory cacheecho 3 > /proc/sys/vm/drop_cache ...

  8. linux(centos 7)下安装JDK,Tomcat,mysql 运行Maven 项目

    一.在Linux中安装JDK 1. 将JDK上传到root下(任何位置均可以). 如图: 2. 用解压命令解压JDK tar -xvf (此处为jdk文件名) 如果是rpm包,执行rpm -i jdk ...

  9. redis 处理缓存击穿以及缓存雪崩

    缓存击穿 1. 缓存击穿简述 某一个热点数据在缓存中失效,请求穿过redis到达DB,造成DB压力过大 2. 怎么解决缓存击穿 1. 使用redis 作为分布式互斥锁(mutex lock) 实现步骤 ...

  10. K8s之二进制安装高可用集群

    1.环境准备 #二进制部署安装文档# https://github.com/easzlab/kubeasz/blob/master/docs/setup/00-planning_and_overall ...