一、背景简介
订单业务一直是系统研发中的核心模块。订单的产生过程与系统中的许多模块高度关联，例如账户体系、支付中心、运营管理等等。即使仅单独考虑订单本身，它也足够复杂了。
在业务发展过程中，订单量必然会持续增加，订单自身、数据量和实现流程都需要不断迭代更新。如果在订单流程的研发初期没有全面考虑，很可能导致中后期需要重构。
基于实践经验，围绕订单业务，建议过度设计，采用轻量级分步实现。
在产品初期，应该先做好全面的设计，保留场景和流程的可扩展性，规划不同数据量的应对方案，走在订单业务前沿，避免被动，尽量不要被业务发展和演变甩在身后。
二、订单业务
1、订单体系
从角色上看，订单体系主要涉及用户、商户和平台三个核心参与方。订单流程的搭建就是围绕三方的交易场景展开。
这里需要说明一些细节：商户可以是第三方商家，也可以是平台方自己，不影响概念上的划分；商品也存在多种形式，因此用“交付”一词来描述可以覆盖物流的定义；
用户通过应用端选择商品并下单，平台则负责实现订单交易链路和支付能力，并对整个流程进行调度；商户则提供商品和交付能力。
在图中，只是围绕订单体系做了一个框架性的宽泛描述。在成熟的订单业务中，其复杂程度远超上图。下面将围绕核心节点进行细致分析。
2、流程管理
2.1 流程拆分
订单的业务属性非常高，流程本身也比较复杂。从不同的参与方来看，其流程分段策略完全不一样。在这里，我们仅从研发视角，把订单逻辑分为三个阶段：创建、支付和交付。
- 订单创建：通过管理用户的下单路径，从商品的访问点击和选中，到购物车下单或直接下单，从而完成订单的创建。
- 订单支付：各种支付渠道的对接是交易场景的基础功能，订单的核心状态即支付成功。
- 订单交付：在订单支付完成后，开始进行商品的交付流程，可能是商家的发货或服务提供，交付成功即订单完成。
如果将整个订单场景统筹起来看的话，还存在很多隐性的流程，与订单衔接的上下游业务还有很多，这里只是专注于订单功能自身的边界做划分；
2.2 正向流程
在理想的状态下，订单从购物车结算下单开始，到交易支付完成，最终到商家完成交付，是非常复杂的流程链路；
在实现上，订单的正向流程链路都是分段管理的，比如购物车、订单创建之后、支付完成、交付等诸多关键节点，并不是一个即时的流程；
2.3 逆向流程
针对订单这种极度复杂的流程，可能导致订单流程逆向的情况，需要仔细考虑并提供相应的解决方案，以确保程序可以兜底流程逆向。人工干预的成本和风险都极高，因此需要尽量避免。
- 取消动作：用户主动取消订单，发起退款流程等；商户因为交付失败，主动发起退款流程等动作；
- 超时情况：订单创建后，指定时间内没有支付；订单支付后，指定时间内商家没有交付等多个超时场景；
- 节点异常：系统平台在订单调度时的业务异常，或者程序异常，又或者支付等第三方渠道异常等。
这些常见的异常问题，在一般场景下可能不会引起效果问题。但是，在像订单这样异步解耦的复杂场景中，需要一个稳定的机制来快速执行逆向流程。例如，下单后未支付导致持续锁定库存，或者交付超时会影响用户体验等问题。
2.4 调度与监控
订单属于核心流程，同时具有复杂的特性，因此自然而然地依赖于系统平台的调度和监控手段。无论是正向流程还是逆向流程，都需要调度手段来提高订单的完成率，或者促使逆向流程有序执行。在这个过程中，需要具备对订单路径的完整监控能力。
调度机制
：侧重处理订单的被动状态，通常用于各种超时场景，旨在提前向用户和商家发送通知消息或处理订单流程。
监控策略
：主要处理订单的主动干预，当订单中断或出现异常时，可以通过产品入口进行主动修复，或通过系统层面的主动重试，最终也可以进行手动干预。
3、结构设计
围绕订单场景，涉及的数据结构非常复杂，不论是商品还是支付，亦或是订单自身的结构，在具体的业务中都会拓展出很多关联表；
订单结构的设计和管理，基于场景复杂度考虑，可能要融合商家、仓储货架、用户、渠道和类型等；在订单量增长之后，还需要结合业务场景，进行数据体量层面的拆分处理；
三、技术方案
1、订单ID
订单主体的唯一ID标识，在数据量不大的情况下，可以使用表的自增ID主键。但从长期来看，这并不是一个友好的方式。如果订单量大，可能需要进行分库分表的流程，这时需要制定ID生成策略。
有以下几种ID生成策略可供选择：
-
UUID
：生成唯一字符串识别码，直接使用订单ID即可。 -
雪花算法
：分布式ID生成算法策略，生成的ID遵循时间的顺序。 -
自定义ID
：除了唯一的属性外，在订单ID中添加其他的关键业务标识。
2、并行与异步
在订单详情的加载过程中，有很多查询信息需要涉及，如商品、商户、订单、用户等。这些查询信息可以用并行操作的方式来处理，以提高响应时间。如果采用串行方式，则接口性能会大幅下降。在并行操作中，可以采用多线程或多进程的方式并行处理不同的查询信息，从而使整个查询过程更加高效。此外，为了保证并行操作的正确性，还需要考虑并发控制和同步机制等问题。
异步操作
是指将复杂的流程分成多个步骤进行处理，以提高服务性能。在订单处理中，采用分段异步的常规方式，可以通过使用MQ消息来实现。这种方式可以大大提高服务性能。无论是订单的正向流程还是逆向流程，都可以采用基于状态、事件和动作的异步解耦处理方法。因此，可以在订单处理中采用分段异步的方式，以确保流程的高效性和可靠性。
3、超时问题
订单超时问题的本质在于，需要在指定时间段之后执行一个动作。举个例子，在最经典的场景中，如果下单之后超过
15||30
分钟未支付，订单将自动取消并关闭，释放商品的库存，并通知用户。
实现动作延迟执行的方式有很多，比如延迟队列、过期监听、消息延时消费等。但在复杂的订单系统中，这些方式并不常见。相对来说，采用定时任务调度的方式更为主流。
在任务调度过程中，对订单的处理同样需要确保业务流程操作的幂等性和数据层面的一致性等问题。如果出现异常单，则需要进行重试，并不断分析异常原因以优化流程。
如果订单体量很大，任务调度还能胜任吗？
订单体量和订单实时量不是同一个概念。系统中积累的订单量和任务要处理的量也不是同一级别的。通过对数据进行分库分表的设计和查询优化，就可以有效处理体量较大的订单，不会成为调度任务的瓶颈问题。
如果订单数据实时体量很大，比如每天超过千万？
这已经不是应用问题了。如果订单量每天达到千万级别，公司会提前很长时间将数据团队引入应用团队中，以解决这种核心的难题。我曾在数据公司工作时，每天单量刚刚过百万，就已经安排数据团队制定解决方案了。
4、分布式事务
订单涉及支付对接、库存管理、结算对账等各种复杂的流程，因此对数据一致性有极高的要求。如果数据层面出现问题导致异常单出现，难免需要人工介入处理。因此，对流程的各阶段做好细致的事务和逻辑管理非常重要。
订单流程是异步解耦的方式推进的。在分布式事务的策略上，我们追求的是最终结果的一致性，这并不妨碍在分段的流程中进行局部的事务管理。事务成功则流程正向推进，事务失败则流程重试或逆向回滚。
四、数据方案
1、转化分析
经典的订单指标体系可用于深度分析用户下单过程中的路径统计，以解决转化率问题。通过不断优化流程和场景，可以提高成交量。一些例子包括：
- 优化购物车页面，使其更加用户友好，以提高用户的购买意愿。
- 为新用户提供优惠券，以吸引他们尝试购买。
- 稳定的供应链管理，以确保产品能够及时到达客户手中。
- 通过多种方式提供付款选项，以满足不同用户的需求。
- 与社交媒体平台合作，以增加品牌曝光率，吸引更多用户。
交易的转化路径分析，是产品和运营重点关注的指标体系，在数据层面，埋点采集的数据通常是上传第三方平台，方便进行用户和业务分析，并且有助于同类客群的营销推广；
2、分库分表
随着数据量的逐渐增大，数据的管理和维护变得越来越困难。如果不进行有效的处理，可能会导致性能下降，甚至系统崩溃。因此，我们需要对数据进行分库分表的操作，以便更好地管理和维护数据。
分库分表是一种将数据按照特定的规则分散到不同的数据库中的处理方式。这种方式可以有效地解决数据库读写瓶颈问题，并提高数据库的性能和稳定性。通过对订单数据进行分流，我们可以将数据分散到不同的库表中，从而实现数据的高效管理和维护。
在进行分库分表操作时，需要考虑到数据的一致性和可靠性。因此，我们需要设计合理的数据分配策略，确保数据的完整性和准确性。同时，还需要制定有效的备份和恢复策略，以防数据丢失或损坏。
总之，分库分表是一种有效的数据管理和维护方式，可以提高系统的性能和稳定性。在处理大量数据时，我们应该考虑采用这种方式，以便更好地管理和维护数据。
基于订单ID计算拆分的逻辑是最常见的，在特殊情况下，也会基于用户ID或商户ID进行计算，从而将相关的数据堆放在一起，如果有必要，也可以考虑多维度拆分的多写模式；
3、数据同步
订单数据分库分表虽然解决存储问题，但是也带来了很多查询方面的阻碍，通过搜索引擎来解决查询问题也是常用的技术选型；
订单数据在库和搜索引擎之间的同步方法有很多，每种方法都有其优缺点和适用场景。以下是几种同步方式的详细介绍：
- 同步双写：这种方法对数据的实时性要求极高，可以保证库和搜索引擎之间的数据同步几乎是实时的。但是，由于要在两个系统之间进行频繁的数据同步，可能会影响系统性能，需要考虑系统的扩展性和稳定性。
- 异步解耦：这种方法将数据同步过程解耦，流程存在轻微的延迟，但可以保证系统的稳定性和性能。适用于数据同步量较大，但对实时性要求不是特别高的场景。
- 定时任务：这种方法通过定时任务来同步数据，可以保证数据同步的时效性，但存在明显的时效问题，可能会造成数据的不一致。适用于对实时性要求不高，但对数据准确性要求较高的场景。
- 组件同步：这种方法采用第三方数据同步组件来进行数据同步，可以保证系统的稳定性和性能，同时减少开发和维护成本。适用于数据同步量较大，但对实时性和数据准确性要求都比较高的场景。
根据订单场景的特点，推荐使用同步双写的方式进行数据同步。但是，在实际应用过程中，还需要根据具体情况进行分析和优化，以达到最佳的数据同步效果。