设计一个简易的订单系统

前言

在电商系统中,订单系统往往承载着非常重要的角色。在极光商城项目的准备阶段,最耗费我时长的就是订单系统了(毕竟实力也不咋样😅。这期间我也查阅了大量资料,为这一块的设计做了些准备。只能说第一次设计,还是挺想做出个好东西来,但是这要考虑的东西,可比单纯的写业务代码要多得多了呀。

业务关系

订单系统

先来看看订单系统在整个极光商城中扮演的角色,实际上是负责管理平台交易的订单处理系统。

订单管理

订单管理模块,主要的体现就是在后台的订单管理模块了。主要功能为订单列表、订单详情、订单定时任务、订单操作、订单跟踪、订单售后、订单流水等。

订单服务

订单服务模块,为整个商城的业务支撑,负责的业务也是较复杂的。主要有订单创建,订单支付、订单确认、取消订单、发起售后、订单跟踪等流程。其中的规则较为复杂,比如说在用户提交订单时,得根据相应的规则判断订单是否合法,也可以理解为风控吧。然后要计算订单的金额,购买了东西,相应的库存也要变化,还要考虑超卖问题。其中某些步骤可能是需要异步调用的,举个例子:我用12306买票时,付款后,先收到邮件,然后12306APP这边的状态过几秒钟能看到购买成功,这里发邮件的功能,可能就是用的异步调用。

订单信息

整个订单的设计,是采取的主表和子表。主表主要会存放订单的基本信息、用户信息、订单流水,物流信息、促销信息、等。但是考虑到一个订单可能包含多个商品,所以说子订单就是用来存放这些不同商品的信息的,当然,也可以进行订单拆分业务,但是即使这么设计,也要考虑到用户只应该付一次款的问题。

数据库设计

数据库里面,目前只对订单系统设计了6张表,以目前的业务来看的话,是绰绰有余了,以后业务变更了再修改吧。

订单流程

就以正常下单的流程来说吧,售后的订单这里就不过多介绍了。

订单创建

用户登录商城,挑选想要购买的商品,然后选择地址和促销信息并提交订单。然后生成订单前,我们需要获取用户信息、商品信息、促销信息等。当然,并不是所有的数据都从前端接收的,不然的话用户传个假的价格过来,岂不是0元购了😂。获取完信息后,这时后台的风控系统,可以进行一系列的规则校验。咱们还得判断库存吧,库存不够了也不能卖,这里的业务设计,以提交订单为准进行库存的扣除。最后生成订单信息和支付信息,同步当前订单即创建完成。

订单支付

支付的话,肯定就是对接第三方平台做一个支付功能了,具体的可以去看支付宝开放平台的文档做个参考。这里主要阐述下订单拆分问题。根据订单里面的商品的性质等原因,可以进行不同的订单拆分。但是,订单建议设计成同时支付和绑定订单。不然的话,很容易被凑单,从而造成一定的损失。除非你的业务就是想弄成淘宝那种,为了凑单拼到300元,然后付款了秒退凑单商品,从而达到优惠的效果。最后根据订单支付的结果,对订单进行操作,成功了就走订单生产流程,失败了就走失败订单的流程,还原被扣除的库存。

订单生产

如果有多个仓库,可根据用户收货地址等因素来调配仓库的货物。并将商品打包寄出,同时更新快递状态实时同步。

订单完成

用户收到商品后,确认收货,订单至此完成。

用户体验

在订单的整个生命周期,都可以通过消息队列来异步操作。比如订单状态更新了,可以给用户发邮件或者短信通知,在商城系统的用户中心也可以推送通知等。

最后

将订单系统进行拆分,也就是订单的管理和订单的处理这两个模块是分开的。主要是考虑到用户下单,和客服进行订单管理的业务区别有点大,前者操作很频繁,后者可能更多的只是看看,做的操作较少。虽然移动端我现在还不会开发,但是得想到一个问题,不同的平台,对应的订单系统的处理逻辑肯定无法保证100%相同的。那么将逻辑拆分,统一管理,我觉得可能是较好的一个方案(目前也只能想到这一步了😅),脚踏实地,一步步来吧,毕竟自己要学的东西也很多。

大公司的经验和成功模式固然重要,值得学习借鉴,但如果因此而变得盲从,就失去了坚持自我的勇气,在架构演化的道路上迟早会迷路。

​ 《大型网站技术架构:核心原理与案例分析》——李智慧

updatedupdated2021-04-112021-04-11
加载评论