CN115271501A - 一种处理订单的方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请的一些实施例提供了一种处理订单的方法、装置、存储介质及电子设备，该方法应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，包括：在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。本申请的一些实施例可以降低各业务端的压力，提升订单的处理效率。

Description

一种处理订单的方法、装置、存储介质及电子设备

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种处理订单的方法、装置、存储介质及电子设备。

背景技术

随着企业的发展，企业的经营范围和核心业务不断向前迭代，并且逐渐扩充经营的业务线。

目前，在对订单处理时，现有技术在一个含有多个业务端的结算系统中将各业务端的数据提取出来，然后按照一定的顺序排列汇总得到订单明细。由于业务端的数量较多每次提取数据时会对各业务端造成很大的处理压力，增大生产环境事故的发生概率，不能确保订单业务的高效处理，降低了客户体验。

因此，如何提供一种高效的处理订单的方法的技术方案成为亟需解决的技术问题。

发明内容

本申请的一些实施例的目的在于提供一种处理订单的方法、装置、存储介质及电子设备，通过本申请的实施例的技术方案可以将业务端与订单处理端解耦，使得订单业务处理端可以独立处理相应的订单数据得到目标订单文件，降低了业务处理系统的服务压力，提升了处理订单的效率，进而确保了业务处理系统的高可用性。

第一方面，本申请的一些实施例提供了一种处理订单的方法，应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，包括：在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

本申请的一些实施例的订单处理端可以在接收到订单状态之后，通过获取各业务端的订单数据，并对其进行处理、整合得到目标订单文件，可以将业务端与订单处理端解耦，使得订单业务处理端可以独立处理相应的订单数据得到目标订单文件，降低了业务处理系统的服务压力，提升了处理订单的效率，进而确保了业务处理系统的高可用性。

在一些实施例，所述获取所述各业务端的订单数据，包括：获取所述各业务端的至少一个订单；提取出与所述至少一个订单中各订单对应的各订单数据，其中，所述各订单数据包括：收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息；将所述各业务端的所述各订单数据组成所述订单数据。

本申请的一些实施例通过将各业务端的各订单的相关数据整合得到订单数据，实现了业务端和订单处理端的数据分开处理，降低了业务端的数据操作压力，进而可以提升订单处理端的处理效率。

在一些实施例，所述对所述各业务端的订单数据进行数据处理，获取各业务端订单信息，包括：将所述各订单数据按照设定的数据结构进行存储，得到所述各业务端的各订单信息，其中，所述各业务端的所有订单信息构成所述各业务端订单信息，其中，所述各业务端订单信息包括：订单基本信息、订单支付信息、订单管控信息和订单清结算信息。

本申请的一些实施例通过将各订单数据按照设定的标准的数据结构进行存储得到各订单信息，可以将不同的业务端的业务线进行定制化字段存储，便于后续可以按照统一的标准化流程处理订单，提升了处理订单的效率。

在一些实施例，所述根据所述各业务端订单信息，得到目标订单文件，包括：对所述各业务端订单信息进行筛选，获取各业务端正常订单；获取所述各业务端正常订单中各正常订单的所述订单支付信息、实际支付信息以及所述订单清结算信息；将所述订单支付信息、所述实际支付信息以及所述订单清结算信息相同的订单作为目标订单；按照时间维度对所述目标订单进行整合，获取所述目标订单文件。

本申请的一些实施例通过对各业务端正常订单中进行订单支付信息、实际支付信息以及订单清结算信息进行自动核对，可以确保目标订单文件的准确性。

在一些实施例，所述对所述各业务端订单信息进行筛选，获取各业务端正常订单，包括：将所述各业务端订单信息中所述订单状态为成功的订单，作为所述各业务端正常订单；所述方法还包括：将所述订单状态为异常或者失败的订单删除。

本申请的一些实施例通过订单状态确定是正常订单还是异常或失败订单，可以筛选出符合条件的订单生成目标订单文件，确保了目标订单文件的准确性。

在一些实施例，所述方法还包括：监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的数量达到第一阈值，则生成限流指令，并执行所述限流指令，以降低所述处理订单的数量。

本申请的一些实施例通过监控处理订单的数量，可以在服务压力或数据处理压力较大时，有效防止订单处理端出现异常或宕机发生生产事故。

在一些实施例，所述方法还包括：监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的响应时间超出第二阈值，则生成熔断指令，并执行所述熔断指令，以确保所述订单处理端的稳定性。

本申请的一些实施例通过监控处理订单的响应时间，可以在服务压力或数据处理压力较大时，有效防止订单处理端出现异常或宕机发生生产事故，确保订单处理端的稳定性。

第二方面，本申请的一些实施例提供了一种处理订单的装置，应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，所述装置包括：数据获取模块，被配置为在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；信息获取模块，被配置为对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；信息整合模块，被配置为根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

第三方面，本申请的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如第一方面任一实施例所述的方法。

第四方面，本申请的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现如第一方面任一实施例所述的方法。

第五方面，本申请的一些实施例提供一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如第一方面任一实施例所述的方法。

附图说明

为了更清楚地说明本申请的一些实施例的技术方案，下面将对本申请的一些实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请的一些实施例提供的一种处理订单的系统图；

图2为本申请的一些实施例提供的处理订单的方法流程图之一；

图3为本申请的一些实施例提供的处理订单的方法流程图之二；

图4为本申请的一些实施例提供的一种处理订单的装置组成框图；

图5为本申请的一些实施例提供的一种电子设备示意图。

具体实施方式

下面将结合本申请的一些实施例中的附图，对本申请的一些实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

相关技术中，结算系统中的业务端数据和结算数据存储在同一个系统内。在获取各业务线(也就是各业务端)的数据时，也会向用户提供相应的服务。也就是说，业务线需要处理订单数据的同时还需要向本端的用户提供服务。由上述相关技术可知，现有技术在面对大量的数据操作时，会对业务端造成很大的数据处理压力，进而提升了发生生产环境事故(例如，宕机、业务端崩溃)的发生概率，不能确保订单业务的高效处理，还降低了客户体验。

鉴于此，本申请的一些实施例提供了一种处理订单的方法，该方法应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端。该方法通过将订单处理端和各业务端解耦，降低了订单处理端和各业务端的处理数据的压力，提升了处理订单的效率，实现了各业务端的业务的快速发展。

如图1所示，本申请的一些实施例提供了一种处理订单的系统图，包括：订单处理端100和业务端110、业务端120以及业务端130。其中，业务端110、业务端120以及业务端130可以产生订单数据，并在用户下单完成后向订单处理端100发送订单状态。订单处理端100在接收到订单状态后，可以获取对应的订单数据。之后订单处理端100可以根据对订单数据进行数据处理得到的各业务端订单信息，生成目标订单文件。

在本申请的一些实施例中，订单处理端100可以与多个业务端进行数据通信，并不局限于上述业务端110、业务端120以及业务端130这三个业务端。订单处理端100、业务端110、业务端120以及业务端130均可以是可移动终端设备或者非移动电脑设备，本申请在此不作具体限定。

下面结合附图2示例性阐述本申请的一些实施例提供的由订单处理端100执行的处理订单的实现过程。

请参见附图2，图2为本申请的一些实施例提供的处理订单的方法流程图，该方法包括：S210，在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据。S220，对所述各业务端的订单数据进行数据处理，获取各业务端订单信息。S230，根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

例如，在本申请的一些实施例中，将业务端与订单处理端进行解耦，与订单相关的订单数据单独存储与订单处理端。通过对获取的各业务端订单数据进行数据处理得到各业务端订单信息，进而生成目标订单文件。本申请的一些实施例有效避免了订单处理端100在进行订单数据结算时对其他业务造成生产事故的风险。

需要说明的是，在本申请的一些实施例中可以采用Kafka消息通知和异步任务。当各业务端在创建订单或者订单状态发生流转时，各业务端会向订单处理端100发送Kafka消息通知(作为订单状态的一个具体示例)，订单处理端100会创建一个异步任务记录，用于记录获取的订单数据。

在本申请的一些实施例中，S210可以包括：获取所述各业务端的至少一个订单；提取出与所述至少一个订单中各订单对应的各订单数据，其中，所述各订单数据包括：收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息；将所述各业务端的所述各订单数据组成所述订单数据。

例如，在本申请的一些实施例中，订单处理端100可以拉取各业务端的各订单数据并存储。例如，在某一时刻，两个用户通过两个业务端分别下单，此时，订单处理端100会接收两个业务端发送的订单状态，然后再去获取各订单数据。其中，各订单数据包含一些订单的场景基本信息，如收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息等等。在获取订单数据的过程中不会对各业务端产生任何服务压力，有效确保了各业务端的正常工作和服务。

在本申请的一些实施例中，S220可以包括：将所述各订单数据按照设定的数据结构进行存储，得到所述各业务端的各订单信息，其中，所述各业务端的所有订单信息构成所述各业务端订单信息，其中，所述各业务端订单信息包括：订单基本信息、订单支付信息、订单管控信息和订单清结算信息。

由于业务类型的不同产生的订单数据会存在差异，为了便于后续数据整合，例如，在本申请的一些实施例中，由于各订单数据依赖的场景基本信息具有先后逻辑关系，因此采用责任链模式和模板模式对各订单数据进行数据清洗(作为数据处理的一个具体示例)，也就是将各订单数据按照设定的数据结构进行存储，存储结构中含有各业务端的定制化字段。然后将数据清洗部分的顶层接口按照模板模式封装。设定的数据结构主要包含两部分，一部分是通用的结构，另一部分为场景定制信息。通过设定的数据结构可以快速识别出订单涉及的场景基本信息。

在本申请的另一些实施例中，也可以只将各订单数据中公共的部分进行数据结构统一，本申请在此不作具体限定。可以理解的是，订单处理端100在对订单数据进行处理时不受业务端的迭代影响，提升了处理订单的稳定高可用性。而且将订单的场景基本信息接入到处理订单的流程中，可以实现后续新业务场景的扩展和开发，节约了人力成本。

在本申请的一些实施例中，S230可以包括：对所述各业务端订单信息进行筛选，获取各业务端正常订单；获取所述各业务端正常订单中各正常订单的所述订单支付信息、实际支付信息以及所述订单清结算信息；将所述订单支付信息、所述实际支付信息以及所述订单清结算信息相同的订单作为目标订单；按照时间维度对所述目标订单进行整合，获取所述目标订单文件。

在本申请的一些实施例中，S230可以包括：将所述各业务端订单信息中所述订单状态为成功的订单，作为所述各业务端正常订单；处理订单的方法还包括：将所述订单状态为异常或者失败的订单删除。

由于订单状态可以根据用户的需要进行取消或变更，因此，在本申请的一些实施例中，只需要对订单状态为成功的订单进行处理即可。若用户下单成功后，业务端会向订单处理端100发送订单状态，通过筛选出订单状态为成功的订单，获取各业务端正常订单。然后将订单状态异常(例如，未支付)或失败的订单删除。之后将各业务端正常订单中的订单支付信息、实际支付信息和订单清结算信息进行自动核对，若三者相同，表示该业务端正常订单准确，否则该业务端正常订单不准确，需要通知管理人员核查原因。最后将核对准确无误的目标订单按照时间维度整合，生成目标订单文件，以供客户参考。

在本申请的一些实施例中，处理订单的方法还包括：监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的数量达到第一阈值，则生成限流指令，并执行所述限流指令，以降低所述处理订单的数量。

由于在实际的应用场景中，订单处理端100连接有多个业务端，因此需要处理大量的订单数据。例如，在本申请的一些实施例中，订单处理端100的资源有限，在一定的时间段内可处理的订单数据有限，因此为了防止订单处理端100发生崩溃或宕机的情况，可以对订单处理端100进行监控，当其在一段时间内处理订单的数量超出第一阈值，则对其进行限流以减少当前处理订单的数量，降低订单处理端100的服务压力和数据处理压力。

在本申请的一些实施例中，处理订单的方法还包括：监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的响应时间超出第二阈值，则生成熔断指令，并执行所述熔断指令，以确保所述订单处理端的稳定性。

例如，在本申请的一些实施例中还可以对订单处理端100进行熔断处理。当在一定的时间段内，处理订单的响应时间超出第二阈值时，可以得知订单处理端100处理数据的压力较大，此时可以采取熔断处理，降低订单处理端100的数据处理压力，避免出现宕机的情况。

需要说明的是，第一阈值和第二阈值可以是根据订单处理端110的实际能力进行设定的，一定的时间段内也可以是根据实际情况进行具体限定，本申请在此不作具体限定。

下面结合附图3示例性阐述本申请的一些实施例提供的处理订单的具体过程。

请参见附图3，图3为本申请的一些实施例提供的处理订单的方法流程图，下面阐述该方法的具体实现过程。

S310，接收至少一个业务端中各业务端发送的订单状态。

例如，作为本申请的一个具体示例，以一个业务端为例，当用户在该业务端下单完成后，该业务端会向订单处理端100发送订单状态。订单状态可以表征该业务端产生了一个订单。

S320，获取所述各业务端的订单数据。

例如，作为本申请的一个具体示例，获取上述一个业务端的收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息等等。

S330，对所述各业务端的订单数据进行数据处理，获取各业务端订单信息。

例如，作为本申请的一个具体示例，将责任链模式和模板模式组合使用，对订单数据进行处理，将订单数据按照设定的数据结构进行存储。通过数据清洗可以使得业务端与订单处理端的流程解耦，两端的数据独立存储，互不影响，后续可以按照上述数据结构的标准进行标准化处理。

S340，根据各业务端订单信息，得到目标订单。

例如，在本申请的一些实施例中，判定各业务端订单信息是否满足清算条件(也就是是否为正常订单)。例如，订单状态为支付成功或退款成功的订单都可以作为正常订单，订单状态为取消支付或支付失败的订单可以认为是异常或者失败的订单。

作为本申请的一个具体示例，上述的一个业务端订单信息为正常订单。此时，需要将正常订单的订单支付信息、实际支付信息以及订单清结算信息进行自动核对，若三者相同则说明该正常订单没问题，数据准确，以此可以将该正常订单作为目标订单。

S350，按照时间维度对所述目标订单进行整合，获取所述目标订单文件。

例如，作为本申请的一个具体示例，将所有业务端的所有目标订单进行整合，按照时间顺序进行排列生成客户结算订单(作为目标订单文件的一个具体示例)。后续还可以将客户结算订单发送给客户。

请参考图4，图4示出了本申请的一些实施例提供的处理订单的装置的组成框图。应理解，该处理订单的装置与上述方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该处理订单的装置的具体功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。

图4的处理订单的装置包括至少一个能以软件或固件的形式存储于存储器中或固化在处理订单的装置中的软件功能模块，该处理订单的装置应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，包括：数据获取模块410，被配置为在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；信息获取模块420，被配置为对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；信息整合模块430，被配置为根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

在本申请的一些实施例中，数据获取模块410，至少被配置为获取所述各业务端的至少一个订单；提取出与所述至少一个订单中各订单对应的各订单数据，其中，所述各订单数据包括：收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息；将所述各业务端的所述各订单数据组成所述订单数据。

在本申请的一些实施例中，信息获取模块420，至少被配置为将所述各订单数据按照设定的数据结构进行存储，得到所述各业务端的各订单信息，其中，所述各业务端的所有订单信息构成所述各业务端订单信息，其中，所述各业务端订单信息包括：订单基本信息、订单支付信息、订单管控信息和订单清结算信息。

在本申请的一些实施例中，信息整合模块430，至少被配置为对所述各业务端订单信息进行筛选，获取各业务端正常订单；获取所述各业务端正常订单中各正常订单的所述订单支付信息、实际支付信息以及所述订单清结算信息；将所述订单支付信息、所述实际支付信息以及所述订单清结算信息相同的订单作为目标订单；按照时间维度对所述目标订单进行整合，获取所述目标订单文件。

在本申请的一些实施例中，信息整合模块430，至少被配置为将所述各业务端订单信息中所述订单状态为成功的订单，作为所述各业务端正常订单；将所述订单状态为异常或者失败的订单删除。

在本申请的一些实施例中，所述装置还包括第一监控模块(图中未示出)，至少被配置为监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的数量达到第一阈值，则生成限流指令，并执行所述限流指令，以降低所述处理订单的数量。

在本申请的一些实施例中，所述装置还包括第二监控模块(图中未示出)，至少被配置为监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；若所述处理订单的响应时间超出第二阈值，则生成熔断指令，并执行所述熔断指令，以确保所述订单处理端的稳定性。

本申请的一些实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

本申请的一些实施例还提供了一种计算机程序产品，所述的计算机程序产品包括计算机程序，其中，所述的计算机程序被处理器执行时可实现如上述实施例提供的上述方法中的任意实施例所对应方法的操作。

如图5所示，本申请的一些实施例提供一种电子设备500，该电子设备500包括：存储器510、处理器520以及存储在存储器510上并可在处理器520上运行的计算机程序，其中，处理器520通过总线530从存储器510读取程序并执行所述程序时可实现如上述任意实施例的方法。

处理器520可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器520可以是微处理器。

存储器510可以用于存储由处理器520执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器520可以用于执行存储器510中的指令以实现上述所示的方法。存储器510包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种处理订单的方法，其特征在于，应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，所述方法包括：

在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；

对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；

根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

2.如权利要求1所述的方法，其特征在于，所述获取所述各业务端的订单数据，包括：

获取所述各业务端的至少一个订单；

提取出与所述至少一个订单中各订单对应的各订单数据，其中，所述各订单数据包括：收银台数据、用户中心数据、订单自定义配置信息、付款单信息、付款时间信息以及客户信息；

将所述各业务端的所述各订单数据组成所述订单数据。

3.如权利要求2所述的方法，其特征在于，所述对所述各业务端的订单数据进行数据处理，获取各业务端订单信息，包括：

将所述各订单数据按照设定的数据结构进行存储，得到所述各业务端的各订单信息，其中，所述各业务端的所有订单信息构成所述各业务端订单信息，其中，所述各业务端订单信息包括：订单基本信息、订单支付信息、订单管控信息和订单清结算信息。

4.如权利要求3所述的方法，其特征在于，所述根据所述各业务端订单信息，得到目标订单文件，包括：

对所述各业务端订单信息进行筛选，获取各业务端正常订单；

获取所述各业务端正常订单中各正常订单的所述订单支付信息、实际支付信息以及所述订单清结算信息；

将所述订单支付信息、所述实际支付信息以及所述订单清结算信息相同的订单作为目标订单；

按照时间维度对所述目标订单进行整合，获取所述目标订单文件。

5.如权利要求4所述的方法，其特征在于，所述对所述各业务端订单信息进行筛选，获取各业务端正常订单，包括：

将所述各业务端订单信息中所述订单状态为成功的订单，作为所述各业务端正常订单；

所述方法还包括：将所述订单状态为异常或者失败的订单删除。

6.如权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；

若所述处理订单的数量达到第一阈值，则生成限流指令，并执行所述限流指令，以降低所述处理订单的数量。

7.如权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

监控接收所述订单状态到获取所述目标订单文件的处理订单的过程；

若所述处理订单的响应时间超出第二阈值，则生成熔断指令，并执行所述熔断指令，以确保所述订单处理端的稳定性。

8.一种处理订单的装置，其特征在于，应用于业务处理系统中的订单处理端，所述系统还包括用于处理业务的至少一个业务端，所述装置包括：

数据获取模块，被配置为在接收所述至少一个业务端中各业务端发送的订单状态之后，获取所述各业务端的订单数据；

信息获取模块，被配置为对所述各业务端的订单数据进行数据处理，获取各业务端订单信息；

信息整合模块，被配置为根据所述各业务端订单信息，得到目标订单文件，其中，所述目标订单文件包括所述各业务端订单信息。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，其中，所述计算机程序被处理器运行时执行如权利要求1-7中任意一项权利要求所述的方法。

10.一种电子设备，其特征在于，包括存储器、处理器以及存储在所述存储器上并在所述处理器上运行的计算机程序，其中，所述计算机程序被所述处理器运行时执行如权利要求1-7中任意一项权利要求所述的方法。

Images