前言
两年来,整个订单管理系统经过大大小小的重构,定下来了总体框架,系统也逐渐稳定下来,23年也快结束了,总结一下自己这两年的成果,顺便锻炼下文笔。
一.订单管理系统的架构设计
先简单介绍一下什么是订单管理系统,订单管理系统用于处理和跟踪销售订单的系统,涵盖从订单接收到订单履行的整个流程,我司由于是做跨境电商的,下面的场景都是基于国外平台的业务场景,在系统设计初期基于的原则便是高内聚,低耦合,强调的是可维护性与可重用性,通俗来说 就是订单中心的逻辑尽量不做修改,灵活对接各大平台,适应各种业务场景。
我们系统主要承接了三部分的订单:第三方电商平台,toB订单,手工单,第三方电商平台主要是订单量较大的国外平台,例如亚马逊,shopify等,进行了平台API对接,对公订单是公司间购买发货的订单,对接了公司内部的TOB订单模块,手工单分两种1.是基于订单的补重改发,2.平台由于单量不够,还未到开发需要对接平台的量,创建对应的平台手工单进行发货
![](https://i-blog.csdnimg.cn/blog_migrate/3b82b7a3f41251f391a413191b2fd5f1.png)
我们将未进入订单中心的订单称为SP订单,进入到订单中心的称为SO订单,SP订单进入到订单中心时,必定会有自己的平台归属
每个平台微服务都会定义一个平台订单转化器,把SP订单转化成标准的SO订单,在第一二版重构中,我们主要是规范了进入订单中心的标准字段,保证其通用性,第三次重构中,在重构中在转化器中定义了各种开关,对订单进行更加精细的控制,而不用对订单中心进行改动,比如是否需要物流地址校验,是否需要扣减库存等,这样在业务发生变动时,不用改动订单中心,只需要对平台微服务进行定制开发即可。
![](https://i-blog.csdnimg.cn/blog_migrate/2ba509a839524e732a2c0c7755d88568.png)
二.订单系统的详细设计
订单系统主要分为四个大表,分别为 订单主表,订单明细表,包裹主表,包裹明细表
当订单进入到订单中心时,会生成一个包含所有订单明细的包裹并推送给下游业务系统,订单中心与下游发货系统通过包裹进行交互,订单系统通过包裹进行各种操作,包裹反向影响订单状态
1.拆分
一.平台订单进入到订单系统时,可能会生成包含多个sku的一个包裹,当某个sku暂时不需要发运时,则可以使用包裹拆分的功能,把不需要发货的sku拆分为一个新的包裹
二.当仓储系统发现某个sku暂时没有库存时,也可以使用拆分逻辑,把有库存的sku生成一个包裹先进行发运。
2.换货
换货操作一般发生在客服和客户共同协商需要更换货物,但是不需要重新下单的情况下,此时只要更换包裹内的sku即可,此时订单的sku不会发生变化,只会变更包裹明细的sku。
3.发货
包裹会继承订单的发运信息以及关键信息,并向下游系统发起创建出库请求
4.拦截
包裹向下游系统发起了出库请求后,客服进行拦截操作,则会向下游系统发起拦截请求,此时下游系统则会向第三方仓库发起取消(自营仓则判断是否出库,未出库则直接取消),然后作废本次的出库请求
5.取消
取消操作和拦截操作逻辑上是一样的,不过唯一不同的就是进行过取消操作的订单,无法再进行操作
6.物流回传
下游系统完成发货后,通知订单中心发货明细,订单中心通过发货明细中的sku再去通知对应的平台系统,完成平台履约
PS:订单中心和下游系统的一次出入库交互应该视为是一次完整请求,请求中应包含所有的出入库信息,两个系统之间相互独立,下游系统根据出入库请求参数即可完成一次出入库操作,下游系统不应中途再通过RPC,MQ等方式再去请求订单中心获取相关参数,以便后期的需求变动和防止下游系统和订单中心的过度耦合。
三.订单系统的订单状态流转
我们将系统订单状态分为初始状态,中间状态,异常状态,终态
初始状态
订单进入订单管理系统时最开始的状态,未生成包裹信息,在生成包裹信息时自动转换成中间状态,这个状态下,会根据平台订单状态进行更新变更
中间状态
订单生成包裹后,推送给下游系统,下游系统未返回处理信息或者返回部分发货时,订单会处于这个状态,中间状态最终会流转成异常状态或者终态,中间状态的订单不再依据平台订单状态而改变,例如 订单A处于待发货状态,平台上面变成已完成,则订单A在订单管理系统还是待发货状态,由下游系统决定订单A的订单状态扭转
异常状态
异常状态分为 1.根据下游系统返回的信息而变更的异常状态。 2.订单管理系统主动操作导致的异常状态。异常状态在下游系统都是处于无法出库的状态,需要进行人工操作后,转化成中间状态或者终态
终态
终态则表示订单已经结束了,不能进行人工操作,订单不能进行任何数据变更。
![](https://i-blog.csdnimg.cn/blog_migrate/376aac7ce3800898f0234bd467749d91.png)
四.订单系统的关键代码逻辑
订单管理系统会对接各种电商,无论是技术人员听过的,还是未听过,那我们经常需要快速对接各大平台的订单,同时兼容订单管理系统的内部逻辑,不应因为平台增加而改变原本稳定的系统,从而增加技术债务.
平台订单通过订单转化器转换成系统订单,当系统订单出库完成,需要进行物流上传时,通过平台工厂类反射生成对应的平台实现类,而每一个平台实现类都是相对独立的,当某个平台发生变化时,只需要修改对应的平台实现类即可,内部逻辑调用的抽象类提供的统一的对应接口,这样在新增平台时并不需要进行修改内部业务逻辑。
![](https://i-blog.csdnimg.cn/blog_migrate/500c6609e8d12a766bd2bd54478ca8a1.png)
五.结语
拖拖拉拉写了半个月,这份总结总算写完了,比写代码难太多了,不知不觉也当了快7年的程序员,无论是业务层面还是代码层面,依旧觉得自己是管中窥豹,路漫漫其修远兮,吾将上下而求索。