订单系统作为电商系统的“纽带”贯穿了整个电商系统的关键流程。其他模块都是围绕订单系统进行构建的。订单系统的演变也是随着电商平台的业务变化而逐渐演变进化着,接下来就和大家一起来解析电商平台的“生命纽带”。
订单系统的作用是:管理订单类型、订单状态,收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据,进行库存更新、订单下发等一系列动作。订单系统业务的基本模型涉及用户、商品(库存)、订单、付款,订单基本流程是下订单——>减库存,这两步必须同时完成,不能下了订单不减库存(超卖),或者减了库存没有生成订单(少卖)。超卖商家库存不足,消费者下了单买不到东西,体验不好;少卖商家库存积压或者需要反复修改商品信息,反复麻烦,体验也不好。
订单管理就是从电商平台上获取买家订单,对订单进行一些处理后,将订单分配给仓库发货。电商订单的整个链路大致如下图所示,在复杂的商业模式下,商家订单类型多样,不同类型的订单的处理不尽相同。本文将探讨OMS系统关于B2C订单处理的产品设计思路。
设计订单系统时包含几个大的方向需要考虑,这些内容决定了订单系统的稳定性和可持续性。
订单的多样性特点
主要由来源和操作的多样导致了订单多样性点。
订单字段
订单字段包含了订单中需要记录的信息,他的作用主要用于沟通其他系统,为下游系统提供信息依据。
订单信息
订单号作为订单识别的标识,一般按照某种特定规则生成,根据订单的增加进行自增,同时在设计订单号的时候考虑订单无序设置(防止竞争者或者第三方来估算订单量)。订单号后续用作订单唯一标示用于对接WMS(仓存管理系统)和TMS(运输管理系统)时的订单识别。
订单状态
订单状态在下面章节会详细描述
用户信息
指买家的相关信息,包括名称、地址、手机号。O2O还会多一种情况就是自提点,这样地址则会变为自提点的地址。地址信息在后续会作用在WMS和TMS上用于区分区域和配送安排。
商品信息
商品的基本信息和库存,金额由于比较特殊所以我把金额独立在商品信息以外说,不过逻辑上其实都属于商品信息范畴。商品信息主要影响库存更新和WMS产生。
金额信息
订单产生的商品信息,这里面除了要记录最终的金额,过程金额也需要记录。比如商品分摊的优惠金额、支付金额,应付金额等。在后续的订单结算、退换货、财务等环节都需要使用。
时间信息
记录订单每个状态节点的触发时间。
订单流程是指整个订单从产生到完成整个流转过程,包括了正向和逆向流程的过程。
正向流程
商品下单后流程:
在存储订单信息中,主要包含以下内容:用户信息、订单基础信息、收货信息、商品信息、优惠信息、支付信息、物流信息、其他信息等等。
订单内容复杂精细,在存储时,除了表结构的设置,还应该注意信息冗余 。特别是商品信息,由于商品的内容不断发生编辑变化,要保存下单快照,避免过长时间后,商品信息丢失。
这里面主要是涉及主流电商系统中的通用订单流程,部分细节可以根据自己平台的特殊性进行调整。
需要注意的地方
如果从购物车选中多件商品时,例如选中三个商家的商品,会将这次购买行为拆分为三个订单,这次整体购买行为记录在父订单下。当系统首次提交订单结算时,会合并自订单,针对父订单进行结算,当提交提交订单后 ,结算中断,或者结算之后,系统在更新订单状态,物流跟踪,针对的是子订单。
逆向流程
逆向流程指订单发生取消、退货等情况时引发的订单流程过程。
触发逆向流程的触发主要有几种情况:
关注点
订单状态
从订单状态设计目的和存在价值去分析和理解它背后设计机制:维度及维度颗粒度大小。
正向和逆向流程维度
服务对象维度
订单推送
当状态发生变化时,需要将对应的变化情况告知给相关人员以便了解当前订单的情况,这就是订单推送的作用。
订单推送的触发依赖于状态机的变化,涉及到的信息包括
商城订单支付后,同步订单信息生成履约单;通过业务相关节点(打标签、物流商匹配、报关规则匹配、拆合单、配货)处理后推送履约订单至WMS内进行履约流程。
订单系统需求演变
第一步:实现购买流程
第二步:提供服务
第三步:支持不同营销手段下的订单类型
平台发展到足够大的规模,提效、稳定变成一个重要的话题。可以提供不同营销场景下的订单,如:团购、预购等。
订单系统架构的演变
最佳实践
实践1: 重试和补偿
实践2: 幂等性
实践3: 一致性实践
系统优化
数据库读写分离
基本的原理是让主数据库处理事务性查询,而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 当然,主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。
好处
数据库分库分表
不管是采用何种分库分表框架或者平台,其核心的思路都是将原本保存在单表中太大的数据进行拆分,将这些数据分散保存到多个数据库的多个表中,避免因为单表数据量太大给数据的访问带来读写性能的问题。所以在分库分表场景下,最重要的一个原则就是被拆分的数据尽可能的平均拆分到后端的数据库中,如果拆分的不均匀,还会产生数据访问热点,同样存在热点数据因为增长过快而又面临数据单表数据量过大的问题。
而对于数据以什么样的纬度进行拆分,大家看到很多场景中都是对业务数据的ID(大部分场景此ID是以自增长的方式)进行HASH取模的方式将数据进行平均拆分,这个简单的方式确实在很多场景下都是非常合适的拆分方法,但并不是在所有的场景中这样拆分的方式都是最优的选择。也就是说数据如何拆分并没有所谓的金科玉律,更多的是需要结合业务数据的结构和业务场景来决定。
下面以大家最熟悉的电商订单数据拆分为例,订单是任何一个电商平台都有的业务数据,每个平台用户提交订单都会在平台后端生成订单相关的数据,一般记录一条订单数据的数据库表结构如下:
订单数据主要由三张数据库表组成,主订单表对应的就是用户的一个订单,每提交一次都会生成一条主订单表的数据。在有些情况下,用户可能在一个订单中选择不同卖家的商品,而每个卖家又会按照该订单中自己提供的商品计算相关的商品优惠(如满100元减10元)以及按照不同的收货地址设置不同的物流配送,所以会出现子订单的相关概念,即一个主订单会由多个子订单组成,而真正对应到具体每个商品订单信息,则保存在订单详情表中。
如果一个电商平台的业务发展健康的话,订单数据是比较容易出现因为单个数据库表中的数据量过大而造成性能的瓶颈,所以需要对他进行数据库的拆分。此时从理论上对订单拆分是可以由两个纬度进行的,一个纬度是通过订单ID(一般为自增长ID)取模的方式,即以订单ID为分库分表键;一个是通过买家用户ID的纬度进行哈希取模,即以买家用户ID为分库分表键。
方案
所以从对『数据尽可能平均拆分』这条原则来看,按照订单ID取模的方式看起来更能保证订单数据的平均拆分,但我们暂时不要这么快下结论,也要根据不同的业务场景和最佳实践角度多思考不同纬度带来的优缺点。
电商平台的需求一直在变化,随之订单系统的架构也会随之变化,架构设计就是一个持续改进的过程,这篇文章还有好多细节未提及,如果你想把订单系统做的更好,需要更加深入系统的每一个环节,比如:容灾、灾备、分流、流控都需要慢慢雕琢,在架构中没有完美的架构只有平衡的架构,不要追求单点的完美,而是要追求多点的平衡。
页面更新:2024-05-09
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号