黑马程序员技术交流社区

标题: 聊聊「订单」业务的设计与实现 [打印本页]
作者: 黄埔小灰灰    时间: 2023-7-3 17:37
标题: 聊聊「订单」业务的设计与实现
聊聊「订单」业务的设计与实现



一、背景简介
订单业务一直都是系统研发中的核心模块，订单的产生过程，与系统中的很多模块都会高度关联，比如账户体系、支付中心、运营管理等，即便单看订单本身，也足够的复杂；





业务在发展的过程中，必然会导致订单量的持续增加，订单自身、数据体量、实现流程，都需要不断的迭代更新，如果在订单流程的研发初期，没有相对全面的考量，那么很有可能导致中后期的重构；


从实践经验上说，围绕订单业务：建议过度设计，轻量级分步实现；


在产品初期先做好全面的设计，场景和流程上做好可扩展性的保留，在数据层面规划好不同体量的应对方案，走在订单业务的前面避免被动，尽量不要被业务的发展和演变甩在身后；


二、订单业务
1、订单体系
订单体系从角色上看，主要涉及：用户、商户、平台三个核心参与方，其订单流程的搭建就是围绕三方的交易场景展开；





这里需要说明一些细节：商户可以是第三方商家，也可以是平台方自己，不影响概念上的划分；商品也存在多种形式，所以用交付来描述，可以覆盖物流的定义；


用户：通过应用端，进行商品的选择和下单；平台：实现订单交易链路和支付能力，以及对整个流程的调度；商户：提供商品和交付能力；


在图中，只是围绕订单体系做一个框架性的宽泛描述，在成熟的订单业务中，其复杂程度远超上图，下面围绕核心节点来细致分析；


2、流程管理
2.1 流程拆分
订单的业务属性是极高的，流程本身也比较复杂，从不同的参与方来看，其流程分段策略完全不一样，这里仅站位研发视角，把订单逻辑分为：创建、支付、交付三个阶段；





订单创建：围绕用户的下单路径做管理，从商品的访问点击并选中，到购车下单或者直接下单，从而完成订单的创建；
订单支付：各种支付渠道的对接是交易场景的基础功能，订单的核心状态即支付成功；
订单交付：在订单支付完成之后，开始进行商品的交付流程，可能是商家的发货或者服务提供，交付成功即订单完成；
如果将整个订单场景统筹起来看的话，还存在很多隐性的流程，与订单衔接的上下游业务还有很多，这里只是专注于订单功能自身的边界做划分；


2.2 正向流程
在理想的状态下，订单从购物车结算下单开始，到交易支付完成，最终到商家完成交付，是非常复杂的流程链路；





在实现上，订单的正向流程链路都是分段管理的，比如购物车、订单创建之后、支付完成、交付等诸多关键节点，并不是一个即时的流程；


2.3 逆向流程
对于订单这种极度复杂的流程，导致订单流程逆向的情况，要细致的考虑并且提供相应的解决方案，尽量确保程序可以兜底流程逆向，人工干预的成本和风险都极高；





取消动作：用户主动取消订单，发起退款流程等；商户因为交付失败，主动发起流程退回等动作；
超时情况：订单创建后，指定时间内没有支付；订单支付后，指定时间内商家没有交付等多个超时场景；
节点异常：系统平台的在订单调度时的业务异常，或者程序异常，又或者支付等第三方渠道异常等；
这些常见的异常问题，在一般的场景下可能不会引发效应问题，对于订单这种异步解耦的复杂场景中，需要一个稳定的机制快速执行逆向流程；比如下单后未支付导致持续锁定库存，或者交付超时影响用户体验等；


2.4 调度与监控
订单属于核心流程又兼具复杂的特性，自然依赖系统平台的调度与监控手段，无论是正向还是逆向流程，都依赖调度手段提高订单的完成率，或者促使逆向流程有序执行，在这个过程中需要对订单路径有完整的监控能力；





调度机制：更侧重订单被动状态的处理，多见于各种超时的场景，用来提前对用户和商户进行消息提醒触达，或者进行订单流程的处理；


监控策略：更侧重对订单的主动干预处理，在发现订单中断或者异常时，可以通过产品层面的入口进行主动修复，或者系统层面的主动重试，当然也不排除最后的手动干预；


3、结构设计
围绕订单场景，涉及的数据结构非常复杂，不论是商品还是支付，亦或是订单自身的结构，在具体的业务中都会拓展出很多关联表；





订单结构的设计和管理，基于场景复杂度考虑，可能要融合商家、仓储货架、用户、渠道和类型等；在订单量增长之后，还需要结合业务场景，进行数据体量层面的拆分处理；







欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) 黑马程序员IT技术论坛 X3.2