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

作者：vivo官网商城开发团队-Ju Changjiang

一、前言

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

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

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

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

二、商品系统演进

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

商品系统架构图如下：

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

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

2.1 商品活动、赠品剥离

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

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

2.2 秒杀独立

众所周知，秒杀活动的特点是：

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

• 限量：商品数量很少，远低于实际库存

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

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

2.3 代销系统成立

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

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

2.4 库存剥离

库存管理的痛点：

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

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

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

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

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

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

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

三、挑战

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

3.1 稳定性

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

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

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

• 监控