一种业务数据的处理方法、装置及系统与流程

本申请属于计算机数据处理技术领域，尤其涉及一种业务数据的处理方法、装置及系统。

背景技术：

随着互联网和计算机技术的迅速发展，目前许多企业的业务系统部署向分布式系统发展，以应对日益增长的业务需求。

随着业务的不断发展，需要业务系统，尤其是大规模分布式系统的生命周期中总会伴随升级和改造，以应对业务快速发展给系统带来的处理压力。而系统产生的业务数据除自身外通常同时被其他如报表系统、文件生成等第三方系统使用。如图1和图2所示，图1是现有中一种业务系统的内部结构示意图，该业务系统包括提供对外服务接口模块、内部业务逻辑实现模块和数据存储模块，业务系统可以通过数据存储模块与数据库交互，写入业务数据或者读取业务数据。图2是现有中一种业务系统业务数据的生成与消费的示意图，图2中，业务系统获取或产生的新的业务数据和写入数据库中，同时其他消费业务数据的应用可以从数据库中读取业务数据进行处理，如生成报表、页面展示等。

而业务系统的改造升级常常包括内部业务逻辑的变更或者数据存储结构/方式的变更，如图3所示，图3是现有中一种业务系统的业务逻辑和数据存储改造的结构变更示意图。如图3中改造后系统结构部分所示，该业务系统改造的结果为分别使用新的业务逻辑实现模块、新的数据存储模块、新的数据库去替换系统原有各模块。新旧模块内业务数据格式及存储方式均不同，由于对外服务接口模块提供的对外的服务接口没有变，故业务系统服务的消费者并不感知系统的内部改造。但对于每一个运行着旧版本系统的服务器而言均会面临着将业务系统从旧逻辑旧存储切换到新逻辑新存储的过程，由于切换后业务数据已经不再写入图3中所示类型a关系数据库，往往会导致改造过程中使用新业务系统的数据消费应用无法继续从原有的数据库中读取业务数据，或者使用旧业务系统的消费应用也无法读取新的数据库中业务数据，使得改造升级过程中业务系统的可靠性和业务数据的可用性降低，甚至会导致消费业务数据的报表，文件生成等第三方系统无法正常进行业务操作。

现有的一些方案中可以采用暂停业务系统服务，等改造升级完成后再开放服务，以保障业务系统的改造升级，但这样会导致第三方系统的业务无法持续可用。其他一些方案中也可以采用可以设置在系统进行内部逻辑和存储方案改造时，安排报表、文件生成等其他数据消费系统同时进行配合改造和上线，但多方系统的同时改造其实施成本和协调难度较大，风险较高，经济性也较差。例如系统a改造过程中，外部其它依赖系统a数据的应用b、c、d因为a的改动，被迫需要同时修改，改造范围大引起风险范围变大，会出现a改造成功但外围b、c、d改造出现故障，导致产品不可用的风险。因此，在对业务系统进行内部逻辑和存储方式的改造过程中，如何确保系统发布的中间状态、以及系统异常回滚状态下数据高可用，使消费数据的报表、文件生成等第三方系统业务持续可用成为目前许多企业用户迫切需要解决的问题。

技术实现要素：

本申请目的在于提供一种业务数据的处理方法、装置及系统，可以在对业务系统进行改造的过程中，确保业务系统的业务数据高可用，使消费数据的报表、文件生成等第三方系统业务持续可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。

本申请提供的一种业务数据的处理方法、装置及系统是这样实现的：

一种业务数据的处理方法，所述方法包括：

基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源；

在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求；

在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

一种业务数据的处理装置，所述装置包括：

资源准备模块，用于基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源；

提交处理模块，用于在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求；

提交结果处理模块，用于在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

一种业务系统，包括：存储器、处理器以及存储在存储器上并可在处理器上运行的计算机指令，

所述计算机指令被处理器执行时实现以下步骤：

基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源；

在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求；

在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

一种业务系统，包括旧业务逻辑实现模块、旧数据存储模块、新业务逻辑实现模块、新数据存储模块、处理器以及用于存储处理器可执行指令的存储器，

所述处理器被配置成，用于接收到的业务的处理请求时，按照旧数据存储模块中设定的旧数据格式从旧数据库中读取数据，准备对应于所述业务的旧业务逻辑处理资源，以及，按照新数据存储模块中设定的新数据格式从新数据库中读取数据，准备对应于所述业务的新业务逻辑处理资源；还用于在确认所述旧业务逻辑处理资源和所述新业务逻辑处理资源准备成功后，使用所述旧业务逻辑实现模块和新业务逻辑实现模块对所述业务进行提交处理；还用于所述业务在所述旧业务逻辑实现模块和所述新业务逻辑实现模块中提交成功后，确认所述业务提交成功。

本申请提供的一种业务数据的处理方法、装置及系统，基于分布式事务在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写。由于改造前后类型数据库中均有业务数据写入，故报表、文件生成等第三方系统在业务系统改造过程中可持续从类型关系数据库读取数据而不受影响，保障业务数据高可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。与此同时可以将改造系统风险控制在改造的单个系统范围内，保障了业务系统乃至依赖于该系统数据的外部应用的稳定性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是现有中一种业务系统的内部结构示意图；

图2是现有中一种业务系统业务数据的生成与消费的示意图；

图3是本申请所述一种业务数据的处理方法一种实施例的方法流程图；

图4是本申请提供的一种业务数据的处理方法另一个实施例场景的实施示意图；

图5是本申请提供的一种业务数据的处理方法另一个实施例场景的实施示意图

图6是本申请提供的一个示例中的分布式事务阶段一的处理流程示意图；

图7是本申请提供的所述一种业务数据的处理方法的另一种实施例的方法流程示意图；

图8是本申请提供的所述一种业务数据的处理方法的另一种实施例的方法流程示意图。

图9是本申请提供的一个示例中的分布式事务阶段二的处理流程示意图；

图10是本申请提供的方法另一种实施例应用场景中的分布式事务阶段二的回滚处理流程示意图；

图11是本申请提供的一种业务数据的处理装置的一个实施例模块结构示意图；

图12是本申请提供的一种业务数据的处理装置另一个实施例模块结构示意图；

图13是本申请提供的一种业务数据的处理装置另一个实施例模块结构示意图；

图14是本申请提供一种业务系统一种实施例的构架结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图4是本申请所述一种业务数据的处理方法一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理的实施环境)。

以下为了清楚起见，以具体的系统改造过程中外部作业调用使用时系统的业务数据处理为应用场景进行说明。但是，本领域技术人员能够理解到，可以将本方案的实质精神应用到其他系统内部逻辑或存储方法改造时外部应用调用系统内部数据进行消费时的场景下。即，基于分布式事务在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写，保障业务数据高可用，使消费数据的报表、文件生成等第三方系统业务持续可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。

具体的一种实施例如图4所示，本申请提供的一种业务数据的处理方法的一种实施例中，所述方法可以包括：

s1：基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源。

在本实施例应用场景中，处于改造升级的业务系统仍然可以正常接收外部其他数据消费用于的业务处理请求。如报表应用可以使用业务系统进行生成报表的作业，业务系统接收到该作业业务的处理请求，然后经过系内部处理后可以提交作业，并将作为完成后形成的报表返回给所述业务系统外部的报表应用。

在本申请实施例中，业务系统升级改造时，可以保持并继续使用业务系统业务处理的旧业务逻辑或者存储旧数据格式的旧数据库。所述的业务系统升级改造可以包括业务系统内部业务数据处理逻辑的改造，或者数据存储格式/方式/数据库类型的改造、迁移等。当然，所述的升级改造也可以同时包括系统的逻辑的变更和数据存储变更的实施场景。例如本实施例中，将原来业务系统业务数据处理的旧业务逻辑、存储就数据格式的类型a关系数据库改造变更使用新业务逻辑处理业务数据、使用新数据格式类型b关系数据库存储业务数据。

在具体实施过程中，由于业务系统保持了新旧两个业务实现逻辑，因此，在接收到业务的处理请求后，可以分别向旧业务逻辑和改造升级使用的新业务逻辑发送资源准备请求，以使所述业务系统中的旧业务逻辑和新业务逻辑量业务处理的参与者都准备对应于所述业务的处理资源。所述的旧业务逻辑和新业务逻辑，可以理解为预先设计好的对业务数据件处理的处理方法/步骤/执行动作和顺序等，可以包括数据处理和/或数据存储(数据读写或存储方式/数据格式控制)阶段，可以由计算机可执行代码或其他逻辑电路实现。

本申请实施例利用分布式事务处理机制，在业务系统内部将业务实现逻辑当作事务的参与者，同时可以在业务系统内部设置事务引擎负责事务服务管理(相当于分布式事务机制中的事务发起者)。业务系统改造过程中，对于一个外部请求，业务系统内部可以通过事务引擎协调新旧两个业务实现逻辑执行。所述的分布式事务处理过程通常包括以下两个阶段：

阶段一：

1、事务发起者(事务管理器)向所参与者发送资源准备请求；

2、参与者收到资源准备请求后，进行准备操作，并答复发起者是否准备成功。

相应的，在本实施例应用场景中，可以设置事务引擎，负责业务数据处理中的资源调配等事务管理。在接收到外部作业的业务处理请求时，可以向参与者(即本实施例所述的旧业务逻辑和新业务逻辑)发送资源准备请求，以准备处理所述业务的处理资源。

s2：在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求。

本申请实施例中，由于改造前后的数据库均有业务数据写入，或者改造前后使用新旧两套业务实现逻辑处理业务数据，因此，报表、文件生成等第三方应用在业务系统升级改造过程中可以持续的从业务系统的数据库中读取数据或者实现业务逻辑，保障第三方应用业务不受影响。在本申请实施例中，旧业务逻辑和新业务逻辑可以准备业务数据处理需所需的处理资源，若所述处理资源准备成功，则可以向上述所述的事务引擎(事务发起者)返回处理资源准备成功的消息。例如，使用旧业务逻辑采用旧数据格式写入旧数据库成功时可以返回旧业务逻辑处理资源准备成功的第一消息；当使用新业务逻辑采用新数据格式写入信息数据库成功时可以返回新业务逻辑处理资源准备成功的第二消息。然后在可以在确定所有的事务参与者(即本实施例应用场景中的旧业务逻辑和新业务逻辑)的业务的处理资源准备成功后才发送提交作业的处理请求。

上述处理确认接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息相当于分布式事务中的阶段二，事务发起者收到所有参与者准备成功的答复后向所有参与者发起提交请求。

s3：在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

提交业务进行处理后，业务系统中的新旧两个业务逻辑可以同时对业务进行处理。如同时使用旧数据库中的数据和旧业务实现逻辑生成旧业务报表和使用新旧数据的中数据和新业务实现逻辑生成新业务报表。当基于接收到的新旧两个业务逻辑业务提交处理成功的消息后，确认当前处理的业务提交处理成功。当然，在一些实施场景中，数据双写或结合两个业务实现逻辑可以生成两个业务提交处理的结果，如生成两个报表。

一般的，系统内部新旧两个逻辑分布提交外部作业，可以分别对应有一个结果。但是对于外部消费业务数据一方而言通常是只有一个输出结果的。因此，本实施例中可以设置将其中一个结果做处理后作为对外输出的结果。这样，系统外部只感知系统内部作业处理有没有成功，至于系统内部如何执行、是否执行了新旧两个逻辑等不被外部调用应用所关心。利用本申请实施方案，可以有效保障系统改造升级过程中的数据可靠用，例如在统a改造过程中，外部其它依赖系统a数据的应用b、c、d不受影响，就好像a从未发生过变更一样。这样在系统a改造过程中，b、c、d的功能依然是可用的。这样就避免了b、c、d会因为a的改动被迫需要同时修改，避免了改造范围扩大，减少改造风险。

本发明基于分布式事务机制，在应用内部将业务实现逻辑当作事务参与者，同时在内部设计事务引擎负责事务管理(事务发起者)。对于一个外部请求业务系统内部通过事务引擎协调新旧两个业务实现逻辑执行。由于新旧逻辑操作的数据库不同，进而实现了数据的双写。这样在系统改造期间消费业务数据的报表、文件生成等第三方系统就可以继续从原有的数据库中获取数据，解决了系统改造过程中数据高可用问题。与此同时将改造系统风险控制在改造的单个系统范围内，保障了业务系统乃至依赖于该系统数据的外部应用的稳定性。

图5是本申请提供的一种业务数据的处理方法另一个实施例场景的实施示意图。在图5中，虽然使用了新的类型b关系数据库，但由于改造前后类型a数据库中均有业务数据写入，故报表、文件生成等第三方系统在业务系统改造过程中可持续从类型a关系数据库读取数据而不受影响，保障系统外部其他数据消费应用正常使用原业务系统的服务。

具体的一个示例中，本申请提供的中业务系统对外部请求的处理流程可以包括两个阶段。例如图6所示的分布式事务阶段一，图6是本申请提供的一个示例中的分布式事务阶段一的处理流程示意图，图6中新旧数据库写入顺序可以换，本实施例中可以只需要保证新旧数据库都写入成功即可。本申请提供的所述方法的另一种实施例中，所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源，可以包括：

s101：根据所述资源准备请求使用旧业务逻辑将所述业务的业务数据按照旧数据格式写入旧数据库；以及，

s102：根据所述资源准备请求使用新业务逻辑将所述业务的业务数据按照新数据格式写入新数据库。

图7是本申请提供的所述一种业务数据的处理方法的另一种实施例的方法流程示意图.另一种实施例中，若业务系统在处理业务请求时出现异常情况，如一直没有收到参与者的答复或者收到失败的答复，则向所有参与者发起回滚请求，使业务系统恢复到上一次正确处理业务数据的状态。因此，本申请提供的所述方法的另一种实施例中，所述方法还可以包括：

s4：在满足下述任意一个条件时，向所述旧业务逻辑和新业务逻辑发送所述业务的处理资源回滚请求：

在预定响应时间内没有接收到所述第一消息和第二消息；

接收到所述旧业务逻辑和新业务逻辑中的至少一个发送来的所述处理资源准备失败的答复消息。

另一种实施中，进一步的，业务系统可以在接收到所述旧业务逻辑返回的处理资源回滚成功的第五消息和所述新业务逻辑返回的处理资源回滚成功的第六消息后，确认所述业务的处理资源回滚成功。基于分布式事务在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写，保障业务数据高可用。

上述实施例采用在业务系统使用的旧业务逻辑和新业务逻辑中任意一个业务处理失败时均指向资源回滚，保障业务系统可靠性，降低业务系统改造风险。并且一种实施方式在，在回滚处理过程中，可以设置只有在所有的逻辑单元都回滚处理成功后才确认业务系统回滚处理成功。否则，可以发出警告提示或者执行其他预定的处理措施，以保障系统的安全、可靠。

图8是本申请提供的所述一种业务数据的处理方法的另一种实施例的方法流程示意图。如图8所示，本申请提供的所述方法的另一种实施例中，所述方法还可以包括：

s5：在满足下述任意一个条件时，启动定时任务，所述定时任务被设置成在延迟预定时间后重新向所述旧业务逻辑和新业务逻辑发送所述业务提交请求：

在预定响应时间内没有接收到所述第三消息和第四消息；

接收到所述旧业务逻辑和新业务逻辑中的至少一个发送来的所述业务提交失败的答复消息。

图9是本申请提供的一个示例中的分布式事务阶段二的处理流程示意图。图10是本申请提供的方法另一种实施例应用场景中的分布式事务阶段二的回滚处理流程示意图。事务引擎会收到两个提交成功的作业反馈，那么此时事务引擎会只有收到两个都成功的时候才确认整个分布式事务处理成功。

如果有一个失败，事务引擎会返回提交失败，一种实施方式中可以设置不会进行回滚操作。因为这里是“分布式事务阶段二提交”的情况，事务引擎会等待分布式事务发起者内部的定时任务重新调用事务引擎进行提交直到成功。

本申请提供的所述方法的其他实施例中，接收到所述业务的处理请求之后，所述方法还包括：

初始化所述旧业务逻辑和新业务逻辑的运行记录；

相应的，所述发送资源准备请求包括：在确定所述旧业务逻辑和新业务逻辑的运行记录初始化成功后发送所述资源准备请求。

由于是两阶段事务，可以简单理解为两阶段事务的处理过程是由两次独立的请求才能完成的。本实施例中初始化运行记录，就是在第一个请求过程中记录下来我做了什么操作。第二个请求到来时查询出第一个请求保存下来的记录，就知道上一个请求做了什么，下面就可以接着继续处理，提高和保障处理效率。

本申请提供的所述方法的其他实施例中，发送所述业务的提交请求之前，所述方法还包括：

校验所述旧业务逻辑和新业务逻辑的运行记录；

相应的，所述发送所述业务的提交请求包括：在确定所述旧业务逻辑和新业务逻辑的运行记录校验成功后发送所述业务提交请求。

本申请提供的所述方法的其他实施例中，发送所述业务的处理资源回滚请求之前，所述方法还包括：

校验所述旧业务逻辑和新业务逻辑的运行记录；

相应的，所述发送所述业务的处理资源回滚请求包括：在确定所述旧业务逻辑和新业务逻辑的运行记录校验成功后发送处理资源回滚请求。

上述实施例应用场景所示的实施方案，通过在系统例如系统a内部设计事务引擎，将改造范围和风险降到了最小，仅在内部解决。最坏情况下，若系统a改造出现问题，也可以快速回滚系统a，而非传统方案连带回滚一系列外围b、c、d系统，造成大面积产品不可用影响。同时系统a改造后，外部其它依赖系统a数据的应用b、c、d不受影响，就好像a从未发生过变更一样。从而保障了整个产品线的稳定性。

本申请提供的一种业务数据的处理方法，基于分布式事务在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写。由于改造前后类型数据库中均有业务数据写入，故报表、文件生成等第三方系统在业务系统改造过程中可持续从类型关系数据库读取数据而不受影响，保障业务数据高可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。与此同时可以将改造系统风险控制在改造的单个系统范围内，保障了业务系统乃至依赖于该系统数据的外部应用的稳定性。

基于本申请所述的业务数据的处理方法，本申请还提供一种业务数据的处理装置。图11是本申请提供的一种业务数据的处理装置的一个实施例模块结构示意图，如图11所示，所述装置可以包括：

资源准备模块101，可以用于基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源；

提交处理模块102，可以用于在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求；

结果处理模块103，可以用于在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

本申请提供的一种业务数据的处理装置，在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写。由于改造前后类型数据库中均有业务数据写入，故报表、文件生成等第三方系统在业务系统改造过程中可持续从类型关系数据库读取数据而不受影响，保障业务数据高可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。与此同时可以将改造系统风险控制在改造的单个系统范围内，保障了业务系统乃至依赖于该系统数据的外部应用的稳定性。

图12是本申请提供的一种业务数据的处理装置另一个实施例模块结构示意图。如前述所述，所述装置的另一种实施例中，所述装置还可以包括：

回滚处理模块104，可以用于在满足下述任意一个条件时，向所述旧业务逻辑和新业务逻辑发送所述业务的处理资源回滚请求：

在预定响应时间内没有接收到所述第一消息和第二消息；

接收到所述旧业务逻辑和新业务逻辑中的至少一个发送来的所述处理资源准备失败的答复消息。

图13是本申请提供的一种业务数据的处理装置另一个实施例模块结构示意图。如前述所述，所述装置的另一种实施例中，所述装置还可以包括：

重提交模块105，可以用于在满足下述任意一个条件时，启动定时任务，所述定时任务被设置成在延迟预定时间后重新向所述旧业务逻辑和新业务逻辑发送所述业务提交请求：

在预定响应时间内没有接收到所述第三消息和第四消息；

接收到所述旧业务逻辑和新业务逻辑中的至少一个发送来的所述业务提交失败的答复消息。

上述所述装置的具体实现逻辑实现方式与方法相似，可以参照前述方法相关描述，在此不做赘述。

本申请提供的一种业务数据的处理装置，基于分布式事务在系统进行逻辑和存储改造过程中，通过设计内部两阶段事务引擎实现数据双写。由于改造前后类型数据库中均有业务数据写入，故报表、文件生成等第三方系统在业务系统改造过程中可持续从类型关系数据库读取数据而不受影响，保障业务数据高可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。与此同时可以将改造系统风险控制在改造的单个系统范围内，保障了业务系统乃至依赖于该系统数据的外部应用的稳定性。

前述所述方法或装置，可以用于各种升级改造过程中的业务系统，以保障业务系统内部逻辑或数据存储结构改造升级等变更时的业务数据高可用，使消费数据的第三方系统业务持续可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。因此，本申请还提供一种业务系统，包括：存储器、处理器以及存储在存储器上并可在处理器上运行的计算机指令，

所述计算机指令被处理器执行时实现以下步骤：

基于接收到的业务的处理请求向旧业务逻辑和设置的新业务逻辑发送资源准备请求，以使所述旧业务逻辑和新业务逻辑准备对应于所述资源准备请求的处理资源；

在接收到所述旧业务逻辑返回的所述处理资源准备成功的第一消息和所述新业务逻辑返回的所述处理资源准备成功的第二消息后，向所述旧业务逻辑和新业务逻辑发送所述业务的提交请求；

在接收到所述旧业务逻辑返回的所述业务提交成功的第三消息和所述新业务逻辑返回的所述业务提交成功的第四消息后，确认所述业务提交成功。

本申请还提供另一种业务系统，包括旧业务逻辑实现模块、旧数据存储模块、新业务逻辑实现模块、新数据存储模块、处理器以及用于存储处理器可执行指令的存储器，

其中，所述处理器被配置成，可以用于接收到的业务的处理请求时，按照旧数据存储模块中设定的旧数据格式从旧数据库中读取数据，准备对应于所述业务的旧业务逻辑处理资源，以及，按照新数据存储模块中设定的新数据格式从新数据库中读取数据，准备对应于所述业务的新业务逻辑处理资源；还用于在确认所述旧业务逻辑处理资源和所述新业务逻辑处理资源准备成功后，使用所述旧业务逻辑实现模块和新业务逻辑实现模块对所述业务进行提交处理；还用于所述业务在所述旧业务逻辑实现模块和所述新业务逻辑实现模块中提交成功后，确认所述业务提交成功。

图14是本申请提供一种业务系统一种实施例的构架结构示意图。

本申请目的在于提供一种业务数据的处理方法、装置及系统，可以在对业务系统进行改造的过程中，确保业务系统的业务数据高可用，使消费数据的报表、文件生成等第三方系统业务持续可用，提高业务系统的可靠性，降低改造风险、难度和实施成本。

尽管本申请内容中提到设计新旧两个业务的实现逻辑、基于应答的消息确认、逻辑运行记录的校验和初始化、新旧数据库的双写等之类的不同事物参与者定义、业务处理逻辑实现方式、信息交互、计算、判断等描述，但是，本申请并不局限于必须是符合行业通信标准、标准数据/函数结构、标准设计语言处理方法或本申请实施例所描述的情况。某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据定义、存储、判断、设置方式等获取的实施例，仍然可以属于本申请的可选实施方案范围之内。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。