行业案例：vivo 全球商城 亿级订单中心、优惠券中心架构设计与实践-v1.pdfVIP

文章一：vivo全球商城亿级订单中心架构设计与实践

截止2021，vivo在全球已覆盖4亿多用户，服务60多个国家和地区，

vivo在菲律宾、马来、印度等国家的市场份额名列前三，在国内出货量始终保持领先地位，并通过vivo

X70系列的推出，成功跻身2021年第三季度4000+以上高端手机市场份额的Top3。

一、背景

从2017年开始，随着用户量级的快速增长，vivo官方商城v1.0的单体架构逐渐暴露出弊端：

模块愈发臃肿

开发效率低下

性能出现瓶颈

系统维护困难。

从2017年开始启动的v2.0架构升级和全面的解耦，基于业务模块进行垂直的系统物理拆分，

拆分出来业务线各司其职，提供服务化的能力，共同支撑主站业务。

订单模块是电商系统的交易核心，不断累积的数据即将达到单表存储瓶颈，

系统难以支撑新品发布和大促活动期间的流量，服务化改造势在必行。

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

二、系统架构

将订单模块从商城拆分出来，独立为订单系统，使用独立的数据库，

为商城相关系统提供订单、支付、物流、售后等标准化服务。

系统架构如下图所示：

page:1/27of尼恩Java硬核架构班：狠卷3高架构，卷透底层技术，走向技术自由！

三、技术挑战

1、数据量和高并发问题

首先面对的挑战来自存储系统：

1、数据量问题

随着历史订单不断累积，MySQL中订单表数据量已达千万级。

我们知道InnoDB存储引擎的存储结构是B+树，查找时间复杂度是O(logn)，

因此当数据总量n变大时，检索速度必然会变慢，

不论如何加索引或者优化都无法解决，只能想办法减小单表数据量。

数据量大的解决方案有：

数据归档

分表

2、高并发问题

page:2/27of尼恩Java硬核架构班：狠卷3高架构，卷透底层技术，走向技术自由！

商城业务处于高速发展期，下单量屡创新高，业务复杂度也在提升，

应用程序对MySQL的访问量越来越高，但是，单机MySQL的处理能力是有限的，

当压力过大时，所有请求的访问速度都会下降，甚至有可能使数据库宕机。

并发量高的解决方案有：

使用缓存

读写分离

分库

下面对这些方案进行简单描述：

1）数据归档

订单数据具备时间属性，存在热尾效应，大部分情况下检索的都是最近的订单，而订单表里却存储了大

量使用频率较低的老数据。

那么就可以将