作者：vivo 官网商城开发团队 - Cheng Kun、Liu Wei
(资料图)
一、背景
vivo官方商城经过了七年的迭代，从单体架构逐步演进到微服务架构，我们的开发团队沉淀了许多宝贵的技术与经验，对电商领域业务也有相当深刻的理解。
去年初，团队承接了O2O商城的建设任务，还有即将成立的礼品中台，以及官方商城的线上购买线下门店送货需求，都需要搭建底层的商品、交易和库存能力。
为节约研发与运维成本，避免重复造轮子，我们决定采用平台化的思想来搭建底层系统，以通用能力灵活支撑上层业务的个性化需求。
包括交易平台、商品平台、库存平台、营销平台在内的一整套电商平台化系统应运而生。
本文将介绍交易平台的架构设计理念与实践，以及上线后持续迭代过程中的挑战与思考。
二、整体架构
2.1 架构目标
除了高并发、高性能、高可用这三高外，还希望做到：
低成本
注重模型与服务的可重用性，灵活支撑各业务的个性化需求，提高开发效率，降低人力成本。
高扩展
系统架构简单清晰，应用系统间耦合低，容易水平扩展，业务功能增改方便快捷。
2.2 系统架构
（1）电商平台整体架构中的交易平台
（2）交易平台系统架构
2.3 数据模型
三、关键方案设计
3.1 多租户设计
（1）背景和目标
交易平台面向多个租户（业务方），需要能够存储大量订单数据，并提供高可用高性能的服务。
不同租户的数据量和并发量可能有很大区别，要能根据实际情况灵活分配存储资源。
（2）设计方案
考虑到交易系统OLTP特性和开发人员熟练程度，采用MySQL作为底层存储、ShardingSphere作为分库分表中间件，将用户标识(userId)作为分片键，保证同一个用户的订单落在同一个库中。
接入新租户时约定一个租户编码(tenantCode)，所有接口都要带上这个参数；租户对数据量和并发量进行评估，分配至少满足未来五年需求的库表数量。
租户与库表的映射关系：租户编码 -> {库数量,表数量,起始库编号,起始表编号}。
通过上面的映射关系，可以为每个租户灵活分配存储资源，数据量很小的租户还能复用已有的库表。
示例一：
新租户接入前已有4库*16表，新租户的订单量少且并发低，直接复用已有的0号库0号表，映射关系是：租户编码-> 1,1,0,0
示例二：
新租户接入前已有4库*16表，新租户的订单量多但并发低，用原有的0号库中新建8张表来存储，映射关系是：租户编码-> 1,8,0,16
示例三：
新租户接入前已有4库*16表，新租户的订单量多且并发高，用新的4库*8表来存储，映射关系是：租户编码-> 4,8,4,0
用户订单所属库表计算公式
库序号 = Hash(userId) / 表数量 % 库数量 + 起始库编号表序号 = Hash(userId) % 表数量 + 起始表编号
可能有小伙伴会问：为什么计算库序号时要先除以表数量？下面的公式会有什么问题？
库序号 = Hash(userId) % 库数量 + 起始库编号表序号 = Hash(userId) % 表数量 + 起始表编号
答案是，当库数量和表数量存在公因数时，会存在倾斜问题，先除以表数量就能剔除公因数。
以2库4表为例，对4取模等于1的数，对2取模也一定等于1，因此0号库的1号表中不会有任何数据，同理，0号库的3号表、1号库的0号表、1号库的2号表中都不会有数据。
路由过程如下图所示：
（3）局限性和应对办法
全局唯一ID
问题：分库分表后，数据库自增主键不再全局唯一，不能作为订单号来使用。且很多内部系统间的交互接口只有订单号，没有用户标识这个分片键。
方案：如下图所示，参考雪花算法来生成全局唯一订单号，同时将库表编号隐含在其中（两个5bit分别存储库表编号），这样就能在没有用户标识的场景下，从订单号中获取库表编号。
全库全表搜索
问题：管理后台需要根据各种筛选条件，分页查询所有满足条件的订单。
方案：将订单数据冗余存储一份到搜索引擎Elasticsearch中，满足各种场景下的快速灵活查询需求。
3.2 状态机设计
（1）背景
之前做官方商城时，由于是定制化业务开发，各类型的订单和售后单的状态流转都是写死的，比如常规订单在下单后是待付款，付款后是待发货，发货后是待收货；虚拟商品订单不需要发货，没有待发货状态。
现在要做的是平台系统，不可能再为每个业务方做定制化开发，否则会导致频繁改动发版，代码错综冗余。
（2）目标
引入订单状态机，能为每个业务方配置多套差异化的订单流程，类似于流程编排。
新增订单流程时，尽可能不改动代码，实现状态和操作的可复用性。
（3）方案
在管理后台为每个租户维护一系列订单类型，数据转化为JSON格式存储在配置中心，或存储在数据库并同步到本地缓存中。
每个订单类型的配置包括：初始订单状态，以及每个状态下允许的操作和操作之后的目标状态。
当订单在执行某个动作时，使用订单状态机来修改订单状态。
订单状态机的公式是：
StateMachine（E,S —> A,S’）
表示订单在事件E的触发下执行动作A，并从原状态S转化为目标状态S’
每个订单类型配置完成后，生成数据的结构是
