分布式场景下的OMS系统设计

一、OMS所处位置

通常我们所谈论的网上购物为狭义电商,属于广义电商的一种,即以电子化手段进行商品交易的一种行为。

狭义电商简单可以描述为货、款、以及货与款的关系。同样,转化为电商系统主要核心模块可以分为WMS仓储系统、FMS财务系统、OMS订单系统。

产品经理,产品经理网站

在电商的三大核心模块中OMS订单系统又可以看作核心中的核心,所有系统以围绕着订单模块进行构建,如果整个电商系统比作人体器官,那么OMS当之无愧可以比作人的心脏,所以OMS系统设计的好坏,直接影响着其他系统的构建。

产品经理,产品经理网站

二、OMS作用

OMS系统承上启下处在电商系统业务链的中游。通过各个平台聚集到OMS的订单,系统通过会员信息、收货信息、优惠信息、商品、积分、支付等条件对订单提供后续处理,如合单、拆单、第三方推送、分发仓库、通知扣减积分,库存、创建退款,退货申请单等操作。同时具备从其他系统上报收集追踪订单变化。如出库、物流信息,并对其他系统运营分析提供数据支撑。

可见OMS系统要具备数据快速聚集、加工、分发、跟踪汇总的能力。

三、OMS设计

了解了OMS所处位置和作用,接下来谈谈如何设计一个稳健的、可持续性的OMS系统。

我们知道建设大楼,会考虑地基、主体结构、周围环境、承载以及抗震能力等各种因素。系统搭建也一样,对达到什么样的预期目标也需提前做出制定,制定的要求越高,设计考虑的因素就越多。

1. 订单相关表字段

产品经理,产品经理网站

2. 前后端数据读写分离

根据用户群体的特点,前后端数据库主从读写分离、应用服务分开灵活部署。主数据库处理相关业务事务,大量的查询转移到从数据库。一是减轻主数据库的压力,二是前后端物理隔离一方宕机可降低对另一方作业的影响。

产品经理,产品经理网站

BDMS 业务+数据(中台)库与OMS 订单库特点对比:

产品经理,产品经理网站

3. 分表归档

根据C端用户特性查询订单以会员维度区分,所以缓解前端访问数据压力,分表设计是个不错的选择。按照订单号1024取模方式,会员编号尾号数字1位,2位取模方式等等。

产品经理,产品经理网站

4. 业务解耦

架构从单体、三层、再到分布式微服务的变化,业务边界也从领域驱动建模开始制定到最终分而治之,各得其所。各个分拆模块更具独立性和可扩展性。所以设计时其他业务模块数据不应混到单独某一业务模块中,数据交换传递统一通过服务接口形式获取。这也体现了分布式系统一切皆服务的思想。

业务拆分后的三大模块主要变化时间轴:

产品经理,产品经理网站

从客户角度分析,C端用户界面可操作性较低,要求简洁、直观、易懂。如会员中心订单tab分类:查看全部、待付款、待发货、待收货、待评价、退款/售后。

产品经理,产品经理网站

上图分类由两种或三种业务状态的组合而成,如下图为后端订单和支付状态值组合到前端状态值以及显示的算法。

产品经理,产品经理网站

其中,会员中心的退款/售后为逆向状态,可与其他tab正向状态区分开。

5. 缩短业务链

OMS系统主线是从建立订单开始为仓库提供发货依据到配送完成,最终实现可预知的业务闭环。

产品经理,产品经理网站

其他事务如推送第三方商户、扣减库存、创建应收、释放积分,库存、退回优惠券,创建退款申请单等事务,可归纳到分支,实现可控的由订单状态流转异步创建单据和事件进行处理。一是缩短业务链长度可使系统更具稳定和强健性,二是可根据活动、秒杀情况控制分支事务处理频次,使资源更好的集中到业务主线上。

例如,双十一活动期间,阿里把会员等级,芝麻信用计算等附加业务暂停服务。甚至在双十一凌晨秒杀阶段,延迟退款退花呗等逆向行为。

→正向状态流(每种状态分别由定时任务异步处理当前状态下的后续业务):

产品经理,产品经理网站

→逆向状态(由定时任务异步处理取消订单后续业务):

产品经理,产品经理网站

6. 自动审单

系统根据审单配置规则对订单金额、地址、地区、收货人,指定会员、手机号等信息进行合法性校验,校验通过的则正常流转后续流程。不符合规则的订单,以及包含备注的订单转人工,通过人工再次审核。

7. 拆单

拆单主要原因涉及店铺、品类、跨境商品、商品超重以及仓库的不同。系统根据拆单配置规则实现对订单拆分。

拆单一般时间节点在支付前和支付后两种情况。拆单需要把运费、优惠、积分分摊到正价单一商品上,方便退款退货以及财务结算。

同时需要考虑部分退情况。如果存在满减、累计消费金额,跨店铺消费等优惠限制时,要注意是否满足部分退。不满足,则需要连带其他拆分子订单一起退,否则驳回。

8. 合单

当买家编号、收货人手机号、地址、姓名一致时,系统自动合并生成新订单。需要注意的是合并订单为虚拟订单,并不是多个订单的合并生成父订单,实质只是合并发货,降低物流成本。

9. 自动取消超时未支付订单

实现方式如定时轮询任务,延时消息。当数量少时使用定时任务即可满足设计。当数量过大时可采用延时消息,订单生成后发延时消息,到设置临界点时判断是否支付,未支付则取消订单。

10. 虚拟出库

一般针对虚拟商品,无需推送到仓库实物发货的订单。如手机充值、购买游戏币等等系统可主动变更订单为已出库,减少人工干预。

11. 异常订单拦截

异常订单拦截一般有别于自动审单校验,可看作是对自动审单规则的补充加强。如收货地址临时变更、商品破损、库存不足、部分地区管控物流限行等等。拦截可以是系统和人工拦截两种。

12. 订单开票

开票分为纸质和电子两种,纸质一般由仓库随发货一起开具,电子发票则由订单发货后,出库状态上报到OMS后,由OMS系统调用税务平台开具蓝色发票。退货逆向流程则开具红冲发票。

13. 补偿机制

如第三方消息队列事务消息机制,TCC补偿方案等等,同时需要注意接口设计时一定要做到幂等性。

14. 换货

换货实质是订单商品的变化,同时也可以理解为新订单加退货或部分退的方式,因此也会涉及到商品单价、优惠券、积分的重新分摊。这也是为什么换货功能设计到OMS的原因。换货主要包含同类商品、不同类商品之间,以及数量的变化,同时还会涉及到旧商品、新商品库存和应收、实收财务结算上的变化。

15. 其他

最后,还要与日志监控、数据分析等系统配合做好预警服务防止恶意下单,最大程度保证商家利益。OMS作为整个电商核心系统,在设计时需要充分分析具体涵盖的业务场景,以及与其他系统的融合,这样才能设计出符合自己企业的OMS系统。

四、总结

分布式场景下系统设计是一个不断摸索前进的过程。只有对架构设计和业务解耦的粒度大小等合理构思,才能使后续系统更具有迭代性和可扩展性。

 

本文作者 @莫名

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部