共计 2814 个字符,预计需要花费 8 分钟才能阅读完成。
一、前言
随着用户量级的快速增长,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 实现分布式事务组件,通过改写代码引入公司的根底组件,目前曾经接入应用。
四、总结
本篇次要介绍商城商品零碎如何进行拆分、并缓缓下沉为最根底的零碎,使其职责更加繁多,可能提供高性能的商品服务,并分享在此过程中遇到的技术问题和解决方案,后续会有库存零碎的演进历史、分布式事务相干内容,敬请期待。
作者:vivo 官网商城开发团队 -Ju Changjiang