java订单超时取消设计_解构电商、O2O：平台的“生命中轴线”-订单系统

设计订单系统时包含几个大的方向需要考虑，这些内容决定了订单系统的稳定性和可持续性。

订单字段

订单字段包含了订单中需要记录的信息，他的作用主要用于沟通其他系统，为下游系统提供信息依据。结构如图

订单信息包括订单号和订单状态机。订单号作为订单识别的标识，往往由一串数字组成，根据订单的增加进行自增，也可以在设计订单号的时候考虑订单加密设置（否则别人通过订单编号就能计算出对应的销售量）。订单号后续用作订单唯一标示用于对接WMS和TMS时的订单识别。订单状态机在下面章节会详细描述，这里不做展开。

用户信息这里指购买人的相关信息，主要包括姓名、地址、手机号。O2O还会多一种情况就是自提点，这样地址则会变为自提点的地址。地址信息在后续会作用在WMS和TMS上用于区分区域和配送安排。

购买商品信息指购买商品的基本信息和库存，金额由于比较特殊所以我把金额独立在商品信息以外说，不过逻辑上其实都属于商品信息范畴。商品信息主要影响库存更新和WMS生产。

金额信息是记录订单产生的商品金额。除了要记录最终的金额，过程金额也需要记录。比如商品分摊的优惠金额、支付金额，应付金额等。在后续的订单结算、退换货、财务等环节都需要使用。

时间信息是记录订单每个节点的触发时间。

这里我们特别说下关于订单标识位的概念，订单标识位有的地方叫服务标记，有的地方叫SendPay，其实从逻辑上来说都是一样的意义。标识位是一串若干位数的字符串，通过对不同位定义来代表不同的含义。比如我们在订单中设置一个字段，这个字段具备100位数字，每一位数据可以从1到9，代表不同含义。这样我们就就可以可以通过这100位字符串代表订单的不同含义和标记，比如第14位代表预售，如果是0则代表正常订单，如果是1代表预售订单。标识位主要用于对订单的特殊逻辑进行标记处理，以便下游系统在接收订单后可以根据标记为判断进行业务处理，比如分拣、仓配类型、是否大小件贵品等。

订单流程

订单流程是指整个订单从产生到完成整个流转过程。他包括正向流程和逆向流程。

正向流程是订单正常生产到配送的过程如下图。下述列举的模块是一般电商通用的功能，部分可能根据实际业务场景有所增加调整。020场景下出库、合包裹、发票准备等工作是由商家方进行，部分工作是属于线下场景。

整个流程涉及到的环节非常多。这里面提几个细节上需要注意的地方：

• 订单生成环节存在超时未支付自动取消的过程。库存的占用会在订单取消后释放。
• 如果选择COD（货到付款）则支付环节相应转移到订单配送之后，而过程中所有与款项相关的逻辑变为只操作金额数字，不对结算和账户进行打退款操作。
• 金额分摊需要到品，这个在上文有说明，这里就不做赘述。
• 订单系统审核主要用户对恶意用户或者刷单情况进行处理。系统可根据白名单、黑名单、消费频次、促销品购买量当方面做风控规则。如果后续会进入到人工审核，则规则上可以适当从宽。当触发规则需要进行订单退订的行为。此处设计时要小心对用户体验的损害，往往前台文案上说明当前节点是审核状态或者是等待接单。
• 在O2O领域有催单的概念，而传统电商则是通过关联第三方物流的物流信息进行跟踪。催单触发考虑到实际场景，一般会设定一定的时间间隔，间隔时间内只触发一次催单的请求。
• 预售等货和移仓需要做成SOA服务，以便在交易页面计算预计时间和预计到货时间。移仓处理依赖仓库的情况，也会涉及到后续拆分和合并包裹的逻辑。
• 订单生产时先要判断报缺情况，如果出现报缺问题则要考虑整单报缺、部分报缺、换货或者换转退的情况（库存，仓促调拨和退款）。报缺情况分为系统报缺和实物报缺，这是承接但相对独立的两个环节。
• 电商系统要考虑7天无理由退货的场景，即订单状态完成后申请退货。此时主要涉及的是金额上的计算以及一些财务程序（如发票等）问题的处理。

逆向流程则指订单发生取消、退货等情况时引发的订单流程过程，如下图2-43。在设计逆向流程时建议和正向独立分开，通过订单号等信息进行关联，避免耦合过多逻辑无法延展设计。

逆向流程的触发主要有几种情况：

• 用户自主取消订单（整单）
• 风控系统触发取消订单（整单）
• 客服接到客诉仲裁后触发取消订单（整单）
• 超时未支付取消订单（整单）
• 换货报缺转为退单（整单、部分报缺）

触发条件考虑两个方面

• 订单状态机（某一节点后如订单生产后不允许取消订单）。
• 订单生成时间（主要是O2O方面，考虑到配送时间和线下流程的不规范，有可能出现状态机没触发更新但实际流程在流转的情况）

其他要注意的一些内容：

• 当退单被商家拒绝后需要转入客服仲裁的环节
• 部分退的订单促销一般保持享用状态，但金额按照分摊的金额进行退款。

从业务流程上来看是按照上述的节点进行流转的，但从系统结构来看订单系统的流程其实拆分成若干的步骤完成。从生成到最终完成所有相关订单处理后选定对应的仓库推送给WMS进行生产、配送，主要的处理逻辑如下图

上图列举的是一些主要的订单功能，不过不是所有的，每个电商的订单系统都会有一些自己独有的系统拆分，不过逻辑上来说是一样的。首先是生成订单，从交易系统获取基本的数据进行生产订单，包括母单和子单。生成的订单信息会提交给订单中心，风控模块首先会针对订单信息进行判断是否属于恶意订单，如果属于恶意订单则申请系统取消并回告用户。非恶意的订单则根据所属仓库、支付方式、订单类型等维度判断拆单和需要下传的下游信息。同时管道服务会将对应的订单信息同步给相关的非业务系统比如台账记账，发票等。在拆单和预分拣的时候有些情况会出现用户订单生成后但暂时没有匹配到对应的仓库进行下发的情况，那么在订单的状态节点中可以增加一个订单转移的概念，未转移的订单认为还是仅仅完成的生成，而转移后的订单才会下发仓库进行生产。订单还有两个模块是属于全局性质的，即promise和订单跟踪或者也叫状态回告。Promise主要负责提供计算预计送达时间，他会根据仓配情况和供应商情况整体计算。而订单跟踪可以理解为对应订单状态机在发生变化时需要通知相关业务系统，订单回告可以通过MQ的方式由业务系统订阅，一旦有变更则有订单系统主动推送业务系统信息以保证及时性。这里的回告图上由于篇幅只画了回告交易，其实其他业务系统也可以接受回告信息。

订单状态机

关于状态机，在百度百科的定位为:

关于状态机的一个极度确切的描述是它是一个有向图形，由一组节点和一组相应的转移函数组成。状态机通过响应一系列事件而“运行”。每个事件都在属于“当前” 节点的转移函数的控制范围内，其中函数的范围是节点的一个子集。函数返回“下一个”（也许是同一个）节点。这些节点中至少有一个必须是终态。当到达终态， 状态机停止。

由上述定义可以看到，状态机的概念是用来表示按照一定的方向通过触发不同节点产生数据流转的过程。在订单中通过情景触发订单状态的变化来表达订单流转的过程就是订单状态机。如下图

电商

O2O

电商和O2O的主体流程是相同的，不同的在于物流配送环节电商较O2O更为复杂。此处只表明了主要的订单状态机，仓储物流内的物流单流转不在此范围内。状态机原则上使用结果值而不使用过程值，比如使用支付成功作为节点而不使用支付中作为节点。

订单状态机要融合订单流程来设计触发节点，订单流程的逻辑点要多于状态机，一般在当前流程环节完成后最后更新状态机。

订单推送

当状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况。这就是订单推送的作用。订单推送和回告的区别在于回告是周知系统，而推送是通过触达手段推送给具体的人。

订单推送的触发依赖于状态机的变化，涉及到的信息包括

• 推送对象（用户、物流人员、商家）
• 推送方式（push，短信）
• 推送节点（状态机）