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

分布式系统(分布式场景中的OMS系统设计)
编辑OMS是订单管理中心 , 可以看作是电子商务系统的核心 。其功能包括数据收集、分发、跟踪和汇总等 。那么 , 如何根据实际的业务场景 , 构建一个可支持的、稳定的、强大的OMS系统呢?在本文中 , 作者总结了分布式场景中的OMS系统设计 , 让我们来看看 。
一、OMS的位置我们通常所说的网购是狭义的电子商务 , 属于广义的电子商务 , 即以电子手段进行商品交易的行为 。
狭义的电子商务可以简单的描述为商品 , 货币 , 以及商品和货币的关系 。同样 , 转化为电子商务系统的主要核心模块可以分为WMS仓储系统、FMS财务系统和OMS订单系统 。
在电子商务的三大核心模块中 , OMS订单系统可以说是核心中的核心 。所有系统都是围绕订单模块构建的 。如果把整个电子商务系统比作人体器官 , 那么OMS不愧为人类的心脏 。因此 , OMS系统的设计直接影响到其他系统的建设 。
第二 , OMS的作用OMS系统承上启下 , 处于电子商务系统业务链的中间 。在OMS通过各种平台聚集的订单 , 通过会员信息、收货信息、优惠信息、商品、积分、支付等条件 , 由系统进行处理 , 如关单、开单、第三方推送、配送仓、通知扣分、备货、创建退款、退回申请单等 。同时 , 它能够报告、收集和跟踪来自其他系统的订单变化 。如出库和物流信息 , 并为其他系统运行分析提供数据支持 。
可以看出 , OMS系统应该具备快速采集、处理、分发、跟踪和汇总数据的能力 。
第三 , OMS设计了解了OMS的地位和功能 , 我们将讨论如何设计一个稳健和可持续的OMS系统 。
我们知道 , 建筑时会考虑地基、主体结构、周边环境、承载力、抗震等各种因素 。制度建设也是如此 。应该提前制定什么样的预期目标 。要求越高 , 设计考虑的因素就越多 。
1.订单相关表字段2.前后台数据读写分离根据用户群体特点 , 前后台数据库主从读写分离 , 应用服务灵活部署 。主数据库处理相关的业务事务 , 大量的查询转移到从数据库 。一是减轻主数据库的压力 , 二是物理隔离前后端 , 可以减少对对方工作的影响 。
BDMS商务+数据(中间站)数据库与OMS订单数据库的特点比较:
3.按表格归档【分布式场景下的OMS系统设计 分布式系统】根据C端用户的特点 , 通过隶属度维度区分查询顺序 , 缓解前端访问数据的压力 , 设计单独的表是一个不错的选择 。根据订单号1024 , 会员号的号码是1位 , 会员号的号码是2位 。
4.业务脱钩从单一架构、三层架构 , 到分布式微服务 , 从领域驱动建模到分而治之 , 制定了业务边界 , 各得其所 。每个分离模块更加独立和可扩展 。因此 , 在设计中 , 其他业务模块的数据不应该混合到单个业务模块中 , 数据交换和传输应该通过服务接口获得 。这也体现了分布式系统服务一切的思想 。
业务拆分后三大模块主要变化时间表:
从客户的角度来看 , C端用户界面可操作性低 , 要求简单、直观、易懂 。例如:会员中心订单的页签分类:查看全部、待付款、待发货、待收货、待评估、退款/售后 。
上面的分类是由两个或三个业务状态组合而成的 , 下图显示了将后端订单和支付状态值组合成前端状态值并显示出来的算法 。
其中 , 会员中心的退款/售后状态为反向 , 可以与其他页签正向状态相区别 。
5.缩短业务链OMS系统的主线是从订单的建立到发货完成 , 为仓库提供发货依据 , 最终实现可预测的业务闭环 。
其他交易如推第三方商户、扣除库存、创建应收、释放积分、库存、返还优惠券、创建退款申请单等 。 , 可以归纳为分支 , 从而实现订单状态流转对文档和事件的可控异步创建进行处理 。第一 , 缩短业务链的长度可以使系统更加稳定和健壮;第二 , 可以根据活跃度和秒杀来控制分支交易的频率 , 让资源更好地集中在主业线上 。
比如双十一活动期间 , 阿里暂停了会员等级、芝麻信用计算等附加服务的服务 。甚至在双十一凌晨的秒杀阶段 , 延迟退款、退花等逆向行为也是一拖再拖 。
→前向状态流程(每个状态下 , 当前状态的后续业务由调度任务异步处理):
→反转状态(订单后续业务被调度任务异步处理取消):
6.自动文件审查检查订单金额、地址、地区、收货人、指定会员、手机号码等的合法性 。根据系统配置规则进行单据审批 。如果检查通过 , 后续流程正常进行 。不符合规则的订单以及带有注释的订单将被转移到人工部门 , 并重新进行人工审批 。
7.打开账单 。拆除原因主要涉及店铺、品类、跨境货物、超重货物、仓库的不同 。系统根据拆分配置规则拆分订单 。
一般打开单据有两种情况:付款前和付款后 。运费、折扣和积分需要以正常价格分配给单个商品 , 以便于退款和财务结算 。
同时 , 要考虑部分退出 。如有满减、累计消费金额、跨店消费等优惠限制 。 , 注意是否符合部分退款 。如果没有 , 需要和其他拆单一起退回;否则将被拒绝 。
8.合并表格当买家号、收货人手机号、地址、姓名一致时 , 系统会自动合并生成新的订单 。需要注意的是 , 合并订单是虚拟订单 , 不是多个订单合并生成的母订单 。本质上只是拼箱发货降低物流成本 。
9.自动取消加班未付订单例如定时轮询任务和延迟消息 。当数量较少时 , 可以使用定时任务来满足设计 。当数量过大时 , 可以使用延迟消息 。订单生成后 , 会发送延迟消息 。临界点定了 , 就要判断是否买单了 。如果订单未支付 , 订单将被取消 。
10.虚拟出站对于一般的虚拟商品 , 不需要将订单推送到仓库进行实物交割 。比如手机充值 , 游戏币购买等 。 , 系统可以主动更改要交付的订单 , 减少人工干预 。
1.异常订单拦截例外拦截一般不同于自动文档审查和验证 , 可以视为自动文档审查规则的补充 。比如临时更改收货地址 , 货物受损 , 库存不足 , 部分地区物流受限等等 。拦截可以是系统的 , 也可以是手动的 。
12.订单开票发票有两种类型:纸质发票和电子发票 。纸质发票一般是仓库随发货开具 , 电子发票是订单开具 。将出库状态报告给OMS后 , OMS系统调用税务平台开具蓝色发票 。在逆向退货流程中 , 会开具红字发票 。
3.补偿机制如第三方消息队列事务消息机制、TCC补偿方案等 。同时 , 需要注意等幂的接口设计 。
14.交换货物换货本质上是对已订购商品的变更 , 也可以理解为新订单加退货或部分退款 , 所以还会涉及到商品单价、优惠券、积分的重新分配 。这就是为什么OMS设计了替换功能 。商品交换主要包括同一种商品之间、不同种商品之间以及数量上的变化 。同时还涉及旧货变动、新货库存、应收、实收财务结算 。
15.其他的最后 , 还要配合日志监控、数据分析等系统 , 提供预警服务 , 防止恶意订单 , 最大程度保证商家利益 。作为整个电子商务的核心系统 , OMS在设计时需要充分分析具体的业务场景以及与其他系统的集成 , 从而设计出符合自己企业的OMS系统 。
四 。摘要分布式场景下的系统设计是一个不断探索的过程 。只有合理的架构设计理念和业务解耦粒度 , 才能使后续系统更具迭代性和可扩展性 。
本文由@莫名其妙原创发布 。每个人都是产品经理 。未经许可 , 禁止复制 。
来自Unsplash的图像 , 基于CC0协议 。

    推荐阅读