基于事件的订单业务处理方法及装置

技术领域

本申请涉及互联网技术领域，尤其涉及基于事件的订单业务处理方法及装置。

背景技术

随着网络的不断普及与发展，用户在电商平台下单以获得想要的资源或者服务已逐渐成为一个趋势。例如，网上购物行为已成为人们日常生活消费中不可或缺的部分。

相关技术中，用户在电商平台下单后，电商系统会围绕着订单的处理过程(例如售前，售中，售后)，对订单进行状态的变更和操作行为，例如订单状态为待支付变成已支付时，则操作订单发货。每次订单状态的变更和操作都会引发一系列的业务需求，例如给用户发短信，给运营人员发工单等。相关技术中，针对订单状态和操作行为的处理，一般采用串行式、阻塞式的模式，每次功能的增加都是在原有的流程上增加对应的程序处理逻辑，这样会导致订单核心流程越来越复杂，处理速度越来越慢，从而降低订单的处理性能，而且每次功能的变更都需要改动订单核心流程，会影响订单核心流程的稳定性。

发明内容

为解决或部分解决相关技术中存在的问题，本申请提供一种基于事件的订单业务处理方法及装置，能够高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

本申请第一方面提供一种基于事件的订单业务处理方法，包括：

接收客户端发送的用于触发订单事件的请求信息；

根据所述请求信息配置与所述订单事件匹配的订单事件处理器，其中，所述订单事件处理器为预先定义，且包含用于处理所述订单事件的处理逻辑；

执行所述订单事件处理器，对所述订单事件进行处理。

在其中一个实施方式中，所述根据所述请求信息配置与所述订单事件匹配的订单事件处理器，包括：

在预先定义的订单事件模型数据对象中获取所述订单事件的名称信息，根据所述名称信息配置与所述订单事件匹配的订单事件处理器。

在其中一个实施方式中，所述根据所述名称信息配置与所述订单事件匹配的订单事件处理器，包括：

根据所述名称信息判断与所述订单事件匹配的订单事件处理器是否存在；

若存在，则配置所述订单事件处理器；或，若不存在，则返回订单事件处理器不存在的提示信息。

在其中一个实施方式中，所述执行所述订单事件处理器，包括：

在预先定义的订单事件模型数据对象中获取订单事件驱动器的名称信息，根据所述名称信息确定出与所述订单事件匹配的订单事件驱动器，通过所述订单事件驱动器执行所述订单事件处理器。

在其中一个实施方式中，所述根据所述名称信息确定出与所述订单事件匹配的订单事件驱动器，通过所述订单事件驱动器执行所述订单事件处理器，包括：

根据所述名称信息和所述订单事件的不同类型确定出与所述订单事件匹配的订单事件驱动器，所述订单事件驱动器通过同步、异步或队列的方式执行所述订单事件处理器。

在其中一个实施方式中，还包括：

判断所述订单事件的处理记录是否存在；

若不存在，则在订单记录表中创建所述订单事件的处理记录；或，若存在，则返回所述订单事件已被记录的提示信息。

在其中一个实施方式中，所述判断所述订单事件的处理记录是否存在，包括：

将与所述订单事件的匹配的订单模型数据对象持久化到所述订单事件记录表，根据所述订单事件记录表中包含的与所述订单事件对应的唯一散列值判断所述订单事件的处理记录是否存在。

在其中一个实施方式中，所述接收客户端发送的用于触发订单事件的请求信息之后，还包括：

判断是否触发与当前订单事件不同的其他订单事件；

若触发其他订单事件，则通过订单事件裂变构成订单事件树。

本申请第二方面提供一种基于事件的订单业务处理装置，包括：

接收模块，用于接收客户端发送的用于触发订单事件的请求信息；

配置模块，用于根据所述接收模块接收的请求信息配置与所述订单事件匹配的订单事件处理器，其中，所述订单事件处理器为预先定义，且包含用于处理所述订单事件的处理逻辑；

执行模块，用于执行所述配置模块配置的订单事件处理器，对所述订单事件进行处理。

在其中一个实施方式中，获取子模块，用于在预先定义的订单事件模型数据对象中获取所述订单事件的名称信息；

配置子模块，用于根据所述获取子模块获取的名称信息配置与所述订单事件匹配的订单事件处理器。

本申请提供的技术方案可以包括以下有益效果：

本申请提供的方案，首先接收客户端发送的用于触发订单事件的请求信息；然后根据请求信息配置与订单事件匹配的订单事件处理器；最后执行订单事件处理器，对订单事件进行处理，这样处理后，由于订单事件的处理逻辑被预先定义被打包成订单事件处理器，可以高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

进一步地，本申请提供的方案，不同的系统在处理订单事件时，可以通过事件名称触发相应的订单事件处理器进行处理，而且订单事件处理器本身可以触发其他订单事件，而且订单事件处理流程中每次功能的变更不会改动订单的核心流程，不会影响订单核心流程的稳定性，避免了相关技术中订单核心流程越来越复杂的缺陷，提升订单处理的性能。另外，业务处理通过不同的订单事件处理器相隔离，实现了并行的处理流程，使得非常容易进行扩展，具有更好的灵活性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细地描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请实施例示出的基于事件的订单业务处理方法的流程示意图；

图2是本申请实施例示出的基于事件的订单业务处理方法的另一流程示意图；

图3是本申请实施例示出的基于事件的订单业务处理方法的另一流程示意图；

图4是本申请实施例示出的基于事件的订单业务处理方法的不同订单事件的关系图

图5是本申请实施例示出的基于事件的订单业务处理装置的结构示意图；

图6是本申请实施例示出的基于事件的订单业务处理装置的另一结构示意图；

图7是本申请实施例示出的基于事件的订单业务处理系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的实施方式。虽然附图中显示了本申请的实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相匹配的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

相关技术中，针对订单状态和操作行为的处理，一般采用串行式、阻塞式的模式，每次功能的增加都是在原有的流程上增加对应的程序处理逻辑，这样会导致订单核心流程越来越复杂，处理速度越来越慢，从而降低订单的处理性能，而且每次功能的变更都需要改动订单核心流程，会影响订单核心流程的稳定性。

针对上述问题，本申请实施例提供一种基于事件的订单业务处理方法、装置及系统，能够高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

以下结合附图详细描述本申请实施例的技术方案。

图1是本申请实施例示出的基于事件的订单业务处理方法的流程示意图。

参见图1，本申请实施例的方法，包括：

步骤S101，接收客户端发送的用于触发订单事件的请求信息。

该步骤中，接收到触发订单事件的请求信息后，可以获取与该请求信息匹配的订单模型数据对象，其中，订单模型数据对象可以预先定义，请求信息需符合订单事件模型数据对象。

步骤S102，根据请求信息配置与订单事件匹配的订单事件处理器，其中，订单事件处理器为预先定义，且包含用于处理订单事件的处理逻辑。

该步骤中，可以从订单模型数据对象中获取与订单事件对应的属性信息，通过该属性信息获取订单事件处理器，订单事件处理器可以为预先设定，且包含处理订单事件的具体逻辑。

步骤S103，执行订单事件处理器，对订单事件进行处理。

该步骤中，可以通过与订单事件处理器匹配的订单事件驱动器执行订单事件处理器，进而对订单事件进行处理。

可以看出，首先接收客户端发送的用于触发订单事件的请求信息；然后根据请求信息配置与订单事件匹配的订单事件处理器；最后执行订单事件处理器，对订单事件进行处理，这样处理后，由于订单事件的处理逻辑被预先定义被打包成订单事件处理器，可以高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

图2是本申请实施例示出的基于事件的订单业务处理方法的另一流程示意图，图2相比图1更进一步地介绍了本申请实施例的方案。

参见图2，本申请实施例的方法，包括：

步骤S201，接收客户端发送的用于触发订单事件的请求信息。

该步骤中，订单事件模型数据对象可以包含元数据和可变数据体两部分内容。其中，元数据包含订单ID字段、业务类型字段、链路ID字段、数据体类型字段、事件驱动名称字段、订单事件名称字段、订单父事件名称字段、订单事件记录ID字段。

可以通过元数据中的数据体类型字段定义可变数据体结构，并且设置订单事件处理器需要的参数数据。

步骤S202，在预先定义的订单事件模型数据对象中获取订单事件的名称信息，根据名称信息配置与订单事件匹配的订单事件处理器。

该步骤中，可以根据名称信息判断与订单事件匹配的订单事件处理器是否存在；若存在，则配置订单事件处理器；或，若不存在，则返回订单事件处理器不存在的错误提示信息。

步骤S203，在订单事件模型数据对象中获取订单事件驱动器的名称信息，根据名称信息确定出与订单事件匹配的订单事件驱动器。

该步骤中，可以根据名称信息和订单事件的不同类型确定出与订单事件匹配的订单事件驱动器，其中，可选的订单事件驱动器包含同步驱动器、异步驱动器、队列驱动器。

步骤S204，通过订单事件驱动器执行订单事件处理器。

该步骤中，根据不同类型的订单事件，订单事件驱动器可以通过同步、异步或队列的方式执行订单事件处理器，对订单事件进行处理。

本实施例中，不同的系统在处理订单事件时，可以通过事件名称触发相应的订单事件处理器进行处理，而且订单事件处理器本身可以触发其他订单事件。在当前订单事件的处理过程中，可以判断是否触发其他订单事件；若触发其他订单事件，则可产生多级订单事件裂变，并构成订单事件树。这样处理后，能高度复用相同的处理逻辑，极大地提升订单处理的性能，有效减少了研发和维护成本；而且订单事件处理流程中每次功能的变更不会改动订单的核心流程，不会影响订单核心流程的稳定性，避免了相关技术中订单核心流程越来越复杂的缺陷，提升订单处理的性能。

本申请实施例的方案，由于可以根据名称信息和订单事件的不同类型确定出与订单事件匹配的订单事件驱动器，因此，针对长时间的订单任务可以采用异步队列的方式，这样能有效提升订单处理的吞吐量和处理速度。

本申请实施例的方案，由于预先定义了订单事件处理器，即预先定义了订单事件的处理逻辑，订单状态的变更和行为的操作在不同的程序模块可以保持相同的处理思路，针对相类似的功能无需维护多种程序逻辑，提高了故障处理效率，降低了日常维护的成本和难度。

图3是本申请实施例示出的基于事件的订单业务处理方法的另一流程示意图；图3相比图2更详细地介绍了本申请实施例的方案。

参见图2，本申请实施例的方法，包括：

步骤S301，接收客户端发送的用于触发订单事件的请求信息。

该步骤中，请求信息包括客户端提交的和订单事件匹配的数据，该数据需符合预先定义的订单事件模型数据对象。

订单事件模型数据对象可以包含元数据和可变数据体两部分内容。其中，元数据包含订单ID字段、业务类型字段、链路ID字段、数据体类型字段、事件驱动名称字段、订单事件名称字段、订单父事件名称字段、订单事件记录ID字段。可以通过元数据中的数据体类型字段定义可变数据体结构，并且设置订单事件处理器需要的参数数据。

步骤S302，在预先定义的订单事件模型数据对象中获取订单事件的名称信息。

该步骤中，订单事件的名称信息包括订单事件名称字段。

该步骤中，可以获取与订单事件对应的订单事件名称和可变数据体数据，然后序列化为字符串，再计算出字符串的唯一散列值，其中，可以采用信息摘要算法计算出字符串的唯一散列值。

步骤S303，根据名称信息判断与订单事件匹配的订单事件处理器是否存在；若存在，则配置订单事件处理器；或，若不存在，则返回订单事件处理器不存在的提示信息。

该步骤中，订单事件处理器包含处理订单事件的具体逻辑，不同的订单事件可以对应不同的订单事件处理器。可以通过映射关系，以订单事件名称字段作为键，订单事件处理器作为值预先定义在配置文件，这样可以通过订单事件全名获知对应的订单事件处理器是否存在。

步骤S304，判断订单事件的处理记录是否存在，若不存在，则在订单记录表中创建订单事件的处理记录；或，若存在，则返回订单事件已被记录的提示信息。

该步骤中，可以将与订单事件的匹配的订单模型数据对象持久化到数据库的订单事件记录表。订单事件记录表可以包含订单事件记录ID字段、订单事件模型数据字段、订单ID字段、链路ID字段、唯一散列值字段、状态字段。

其中，可以先根据唯一散列值判断订单事件记录是否已经存在。如果已经存在，则返回事件已经处理过的错误提示；或者，如果不存在，则在订单事件记录表插入一条新的数据，标记该订单事件记录数据为未处理状态，并返回订单事件记录ID，然后将订单事件记录ID回写到订单事件模型数据对象的订单事件记录ID字段。

步骤S305，在预先定义的订单事件模型数据对象中获取订单事件驱动器的名称信息。

该步骤中，订单事件驱动器的名称信息可以包括订单事件驱动的名称字段。

步骤S306，根据名称信息确定出与订单事件匹配的订单事件驱动器。

该步骤中，可以根据名称信息和订单事件的不同类型确定出与订单事件匹配的订单事件驱动器，可选地，订单事件驱动器可以包括同步驱动器、异步驱动器及队列驱动器。

步骤S307，通过订单事件驱动器执行订单事件处理器。

该步骤中，每个订单事件处理器执行的时候可以配置选择对应的事件驱动器，进而通过同步、异步或队列的方式执行订单事件处理器。

例如，当选择出的订单事件驱动器为同步驱动器时，将订单事件模型数据对象作为订单事件的处理参数注入订单事件处理器，然后执行订单处理器。

当选择出的订单事件驱动器为异步驱动器时，将订单事件模型数据对象作为订单事件的处理参数注入订单事件处理器，从异步驱动器内的线程池获取空闲线程，然后执行订单事件处理器。例如，针对长时间任务可以通过异步驱动器以异步队列的方式进行处理，有效提升了订单处理的吞吐量和处理速度。

当订单事件驱动器为队列驱动器时，将订单事件模型数据对象序列化为字符串，作为消息数据推入队列。同时，系统启动的消费者线程，从队列中读取消息数据，反序列化为订单事件模型数据对象。通过订单事件配置器获取订单事件名匹配的订单事件处理器，将订单事件模型数据作为订单事件处理器参数注入订单事件处理器，从异步驱动器内的线程池获取空闲线程，执行订单事件处理器。

步骤S308，更新订单处理记录表中的订单处理状态，并收集订单事件的链路日志。

该步骤中，订单事件处理器返回处理结果后，根据订单事件记录ID标记订单事件记录表的订单事件的为已处理状态。

在每次订单事件被处理完成后，可以收集订单事件的链路日志，每次收集的日志都包含订单事件模型数据对象的链路ID字段，该链路ID字段与订单事件记录表的链路ID字段相对应，进而可以通过订单事件记录表可以查询到全部的链路日志。这样处理后，由于在单处理记录表中记录了每一个事件的处理情况，这样通过一个订单号可以查看到整个订单处理流程全部的事件处理，提升了排查问题的效率。

一些实施例中，订单事件处理器包括通用订单事件处理器和业务定制订单事件处理器。通用订单事件处理器用于处理所有业务共同需要处理的订单事件。业务定制订单事件处理器用于处理具有业务定制化需求的订单事件。这样处理后，使得不同的业务可以单独定制订单事件处理器，可以定制订单通用事件的子事件，不会影响到正在运行的程序，业务处理通过不同的事件处理器隔离，非常容易进行扩展，不同的订单事件可以排列组合成树状结构，具有更好的灵活性。

值得说明的是，本实施例中，在当前的订单处理流程中，如果触发了其他订单事件，可以获取与其他订单事件对应的订单事件模型数据对象，并订单事件处理器需要的参数数据，然后重复执行上述的步骤S302至步骤S307，能产生多级订单事件裂变，构成订单事件树，进而使得订单事件的处理流程由相关技术中的串行处理转化为相互隔离的并行处理流程，提升订单处理的性能。

图4是本申请实施例示出的基于事件的订单业务处理方法的订单事件关系图，图4介绍了本申请实施例中多级事件裂变，构成订单事件树的方案。

参见图4，系统1和系统2可以是不同的服务器设备，分别可以接收客户端发送的用于触发订单事件的请求信息。其中，系统1和系统2可以同时触发订单事件A，订单事件A可以通过订单事件裂变的方式产生业务M定制子订单事件A1、业务N定制子订单事件A2及订单事件B；

其中，业务M定制子订单事件A1、业务N定制子订单事件A2及订单事件B还可以由系统1直接触发。业务M定制子订单事件A1又能通过订单事件裂变的方式产生订单事件E，订单事件B又可以通过订单事件裂变的方式产生订单事件C和订单事件D。

一些实施例中，订单事件的名称由不同的字段(例如第一字段、第二字段及第三字段)组成。其中，第一字段可以定义为业务标识，对应的值为业务方名称。第二字段可以定义为子事件标识，对应值为固定的英文单词(例如item)，用以代表子事件。第三字段可以定义为事件名标识，对应值为业务方定义的事件名称。其中，当主订单裂变多个子订单时，主订单事件名称可以由第一字段和第三字段构成，子订单事件名称可以由第一字段、第二字段及第三字段构成。

本实施例中，可以将客户端触发的订单事件以及裂变的订单事件对应的订单事件模型数据对象序列化为字符串，然后存入数据库持久化。将某个订单事件ID匹配的所有订单事件记录构建成事件树，展示在后台管理页面，进而实现订单事件处理的可视化。

可以看出，本申请实施例提供的方案，订单事件的订单处理逻辑被打包成订单事件处理器，不同的系统在处理订单事件时，可以通过事件名称触发相应的订单事件处理器进行处理，而且订单事件处理器本身可以触发其他订单事件，这样使得高度复用相同的逻辑，提升订单处理的性能，有效减少了研发和维护成本；而且订单事件处理流程中每次功能的变更不会改动订单的核心流程，不会影响订单核心流程的稳定性，避免了相关技术中订单核心流程越来越复杂的缺陷，提升订单处理的性能。

与前述应用功能实现方法实施例相对应，本申请还提供了一种基于事件的订单业务处理装置及相应的实施例。

图5是本申请实施例示出的基于事件的订单业务处理装置的结构示意图；

参见图5，本申请实施例提供的装置500，包括：

接收模块501，用于接收客户端发送的用于触发订单事件的请求信息。

接收模块501接收到触发订单事件的请求信息后，可以获取与该请求信息匹配的订单模型数据对象，即请求信息需符合订单事件模型数据对象，订单模型数据对象可以为预先定义。

配置模块502，用于根据接收模块501接收的请求信息配置与订单事件匹配的订单事件处理器，其中，订单事件处理器为预先定义，且包含用于处理订单事件的处理逻辑。

配置模块502可以从订单模型数据对象中获取与订单事件对应的属性信息，通过该属性信息获取订单事件处理器。

执行模块503，用于执行配置模块502配置的订单事件处理器，对订单事件进行处理。

执行模块503可以通过与订单事件处理器匹配的订单事件驱动器执行订单事件处理器，进而对订单事件进行处理。

可以看出，本申请实施例的方案，订单事件的处理逻辑被打包成订单事件处理器，进而通过配置模块502配置的订单事件处理器对订单事件进行处理，可以高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

图6是本申请实施例示出的基于事件的订单业务处理装置的另一结构示意图。

参见图6，本申请实施例提供的装置，配置模块502包括：

获取子模块512，用于在预先定义的订单事件模型数据对象中获取订单事件的名称信息。

订单事件的名称信息包括订单事件名称字段。

配置子模块522，用于根据获取子模块512获取的名称信息配置与订单事件匹配的订单事件处理器。

配置子模块522还用于根据名称信息判断与订单事件匹配的订单事件处理器是否存在；若存在，则配置订单事件处理器；或，若不存在，则返回订单事件处理器不存在的提示信息。

可以看出，本申请实施例的方案，可以根据订单事件对应的名称信息配置与订单事件匹配的订单事件处理器，由于预先定义了订单事件的处理逻辑，订单状态的变更和行为的操作在不同的程序模块为相同的处理思路，针对相类似的功能无需维护多种程序逻辑，提高了故障处理效率，降低了日常维护的成本和难度。

图7是本申请实施例示出的基于事件的订单业务处理系统的结构示意图。

参见图7，本申请实施例提供的系统600，包括：

客户端设备601，用于向服务器发送用于触发订单事件的请求信息。

客户端设备例如可以是手机、平板电脑等移动通信设备。

服务器设备602，根据客户端601设备发送的请求信息配置与订单事件匹配的订单事件处理器，其中，订单事件处理器为预先定义，且包含用于处理订单事件的处理逻辑；执行订单事件处理器，对所述订单事件进行处理。

服务设备602可以是不同的系统模块，不同的系统模块分别可以触发订单事件。

本申请实施例的方案，订单事件的处理逻辑被打包成订单事件处理器，不同的系统可以分别可以触发订单事件处理器对订单事件进行处理，可以高度复用相同的订单处理逻辑，提升了订单处理能力，有效减少了研发和维护成本。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种计算机可读存储介质(或非暂时性机器可读存储介质或机器可读存储介质)，其上存储有可执行代码(或计算机程序或计算机指令代码)，当可执行代码(或计算机程序或计算机指令代码)被电子设备(或服务器等)的处理器执行时，使处理器执行根据本申请的上述方法的各个步骤的部分或全部。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文披露的各实施例。