查看原文
其他

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

Ju Changjiang vivo互联网技术 2022-03-18
作者:vivo官网商城开发团队-Ju Changjiang


一、前言


随着用户量级的快速增长,vivo官方商城v1.0的单体架构逐渐暴露出弊端:模块愈发臃肿、开发效率低下、性能出现瓶颈、系统维护困难。


从2017年开始启动的v2.0架构升级,基于业务模块进行垂直的系统物理拆分,拆分出来业务线各司其职,提供服务化的能力,共同支撑主站业务。


商品模块是整个链路的核心,模块的增多严重影响系统的性能,服务化改造势在必行。


本文将介绍vivo商城商品系统建设的过程中遇到的问题和解决方案,分享架构设计经验。


二、商品系统演进


将商品模块从商城拆分出来,独立为商品系统,逐渐向底层发展,为商城,搜索,会员、营销等提供基础标准化服务。


商品系统架构图如下:



前期商品系统比较杂乱,包含业务模块比较多,如商品活动业务、秒杀业务,库存管理,随着业务的不断发展,商品系统承载更多的业务不利于系统扩展和维护。


故思考逐渐将商品业务逐渐下沉并作为最底层、最基础的业务系统,并为众多调用方提供高性能的服务,下面介绍商品系统的升级历史。


2.1 商品活动、赠品剥离


随着商品活动的不断增多,玩法多样,同时与活动相关的额外属性也相应增加,这些都并不是与商品信息强关联,更偏向于用户营销,不应该与核心商品业务耦合在一起,故将其合并入商城促销系统。


赠品不仅仅是手机、配件,有可能会是积分、会员等,这些放在商品系统都不合适,也不属于商品模块的内容,故同步将其合并入商城促销系统。


2.2 秒杀独立


众所周知,秒杀活动的特点是:


  • 限时:时间范围很短,超过设置的时间就结束了

  • 限量:商品数量很少,远低于实际库存

  • 访问量大:价格低,可以吸引非常多的用户


基于以上特性,做好一个秒杀活动不是一蹴而就,由于系统资源共享,当突发的大流量冲击会造成商品系统其他业务拒绝服务,会对核心的交易链路造成阻塞的风险,故将其独立为单独的秒杀系统,单独对外提供服务。


2.3 代销系统成立


我们商城的主要销售品类还是手机以及手机配件等,商品的品类比较少,为了解决非手机商品品类不丰富的问题,运营考虑与知名电商进行合作,期望引入更多的商品品类。


为了方便后续扩展,以及对原有系统的不侵入性,我们经过考虑专门独立出一个子系统,用于承接代销业务,最后期望做成一个完备平台,后续通过提供开放API的方式让其他电商主动接入我们业务。


2.4 库存剥离


库存管理的痛点:


  • 由于我们的库存都是到商品维度,仅仅一个字段标识数量,每次编辑商品都需要为商品调整库存,无法动态实现库存管理;

  • 同时营销系统也有自己活动库存管理机制,入口分散,关联性较弱;

  • 可售库存和活动库存管理的依据都是实际库存,造成容易配置错误。


基于以上痛点,同时为了更方便运营管理库存,也为未来使用实际库存进行销售打下基础,我们成立库存中心,并提供以下主要功能:


  • 与ecms实际库存进行实时同步;

  • 可以根据实际库存的仓库分布情况,计算商品的预计发货仓库和发货时间,从而计算商品预计送达时间;

  • 完成低库存预警,可以根据可用库存、平均月销等进行计算,动态提醒运营订货。


三、挑战


作为最底层的系统,最主要的挑战就是具备稳定性,高性能,数据一致性的能力。


3.1 稳定性


  • 避免单机瓶颈:根据压测选择合适的节点数量,不浪费,同时也能保证沟通,可以应对突发流量。

  • 业务限流降级:对核心接口进行限流,优先保证系统可用,当流量对系统压力过大时将非核心业务进行降级,优先保证核心业务。

  • 设置合理的超时时间:对Redis、数据库的访问设置合理超时时间,不宜过长,避免流量较大时导致应用线程被占满。

  • 监控&告警:日志规范化,同时接入公司的日志监控和告警平台,做到主动发现问题并及时。

  • 熔断:外部接口接入熔断,防止因为外部接口异常导致本系统受到影响。



3.2 高性能


多级缓存

为了提升查询速度,降低数据库的压力,我们采用多级缓存的方式,接口接入热点缓存组件,动态探测热点数据,如果是热点则直接从本地获取,如果不是热点则直接从redis获取。


读写分离

数据库采用读写分离架构,主库进行更新操作,从库负责查询操作。


接口限流

接入限流组件, 直接操作数据库的接口会进行限流,防止因为突发流量、或者不规范调用导致数据库压力增加,影响其他接口。


不过早期也踩过一些坑:


1、商品列表查询造成redis key过多,导致redis内存不够的风险


由于是列表查询,进行缓存的时候是对入参进行hash,获取唯一的key,由于入参商品较多,某些场景下入参是随时变化的,根据排列组合,会造成基本每次请求都会回源,再缓存,可能造成数据库拒绝服务或者redis内存溢出。


方案一:循环入参列表,每次从redis获取数据,然后返回;



这个方案解决了key过多导致内存溢出的问题,但是很明显,它增加了很多的网络交互,如果有几十个key,可想而知,对性能会有不小的影响,那有什么其他办法能减少网络交互呢,下面我们看方案二。


方案二:我们通过对原有的Redis 组件进行增强,由于Redis集群模式不支持mget,故我们采用pipeline的方式实现,先根据key计算出其所在的slot,然后聚合一次性提交,这样每个商品数据只需缓存一次即可,同时采用mget也大大提升了查询速度。



这就即解决了key值过多的问题,也解决了方案一中多次网络交互的问题,经过压测对比,方案二比方案一性能提升50%以上,key越多,效果越明显。


2、热点数据,导致redis单机瓶颈


商城经常有新品发布会,发布会结束后会直接跳转到新品商详页,此时新品商详页就会出现流量特别大且突发、数据单一,这就导致Redis节点负载不平衡,有些10%不到,有些达到90%多,而一些常规的扩容是没有效果的。


针对热点问题我们有以下解决方案:


  • key的散列,将key分散到不同的节点

  • 采用本地缓存的方式


开始我们采用的是基于开源的Caffeine完成本地缓存组件,本地自动计算请求量,当达到一定的阀值就缓存数据,根据不同的业务场景缓存不同的时间,一般不超过15秒,主要解决热点数据的问题。


后来替换成我们自己研发的热点缓存组件,支持热点动态探测,热点上报,集群广播等功能。


3.3 数据一致性


1、对于Redis的数据一致性比较好解决,采用“Cache Aside Pattern”:


对于读请求采用先读缓存,命中直接返回,未命中读数据库再缓存。对于写请求采用先操作数据库,再删除缓存。


2、由于库存剥离出去,维护入口还是在商品系统,这就导致存在跨库操作,平常的单库事务无法解决。


开始我们采用异常捕获,本地事务回滚的方式,操作麻烦点,但也能解决这个问题。


后来我们通过开源的seata完成分布式事务组件,通过改写代码引入公司的基础组件,目前已经接入使用。


四、总结


本篇主要介绍商城商品系统如何进行拆分、并慢慢下沉为最基础的系统,使其职责更加单一,能够提供高性能的商品服务,并分享在此过程中遇到的技术问题和解决方案,后续会有库存系统的演进历史、分布式事务相关内容,敬请期待。


END

猜你喜欢

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存