订单中心架构设计与实践

不同的业务采用不同的系统架构，会有自己的一些特色架构难题。今天我们来学习下电商业务中的订单中心的架构设计，以及会遇到哪些技术挑战。

一、背景

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

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

订单模块是电商系统的交易核心，不断累积的数据即将达到单表存储瓶颈，系统难以支撑新品发布和大促活动期间的流量，服务化改造势在必行。

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

二、系统架构

将订单模块从商城拆分出来，独立为订单系统，使用独立的数据库，为商城相关系统提供订单、支付、物流、售后等标准化服务。

系统架构如下图所示：

三、技术挑战

3.1 数据量和高并发问题

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

• 数据量问题

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

  我们知道InnoDB存储引擎的存储结构是B+树，查找时间复杂度是O(log n)，因此当数据总量n变大时，检索速度必然会变慢， 不论如何加索引或者优化都无法解决，只能想办法减小单表数据量。

  数据量大的解决方案有：数据归档、分表

• 高并发问题

  商城业务处于高速发展期，下单量屡创新高，业务复杂度也在提升，应用程序对MySQL的访问量越来越高。

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

  并发量高的解决方案有：使用缓存、读写分离、分库

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

• 数据归档

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

  那么就可以将新老数据分开存储，将历史订单移入另一张表中，并对代码中的查询模块做一些相应改动，便能有效解决数据量大的问题。

• 使用缓存

  使用Redis作为MySQL的前置缓存，可以挡住大部分的查询请求，并降低响应时延。

  缓存对商品系统这类与用户关系不大的系统效果特别好，但对订单系统而言，每个用户的订单数据都不一样，缓存命中率不算高，效果不是太好。

• 读写分离