本申请实施例涉及软件开发技术领域，具体而言，本申请涉及一种业务处理方法、装置、电子设备及计算机可读存储介质。
背景技术：
伴随我国银行票据业务的蓬勃发展，多样的业务产品需求以及快速变化的市场需求都对后台业务系统的开发提出了更高的要求。一方面，不断有新的产品需要快速落地交付市场，另一方面，要求已有产品跟随市场变化对业务流程优化迭代。
目前票据业务的开发主要面临以下两种情形：1、当有新的产品业务需求时，开发人员根据业务流程，全新开发一套业务代码，或者复用部分已有的业务代码；2、当已有业务的业务流程需要调整时，开发人员需要对原有的业务逻辑进行大量的代码修改。然而，本申请实施例的发明人在具体实现过程中发现：全新开发一套业务代码的开发周期长、费时费力、导致无法快速落地新产品，复用原有业务代码不仅需要梳理原逻辑，进行大量的代码修改，极大增加工作量及时间成本，而且容易造成代码的强耦合，不利于系统后期维护及系统健壮性。
技术实现要素：
本申请实施例的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：
一方面，提供了一种业务处理方法，包括：
对目标业务的业务需求进行分析，并根据分析结果将目标业务拆分为多个目标业务组件；
从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，其中，组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；
通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常。
在一种可能的实现方式中，从组件池中获取多个目标业务组件，包括：
步骤a、分析确定组件池中是否包括多个目标业务组件；
步骤b、确定组件池中包括多个目标业务组件时，直接从组件池中获取多个目标业务组件；确定组件池中不包括多个目标业务组件中的任一目标业务组件时，生成任一目标业务组件，并将任一目标业务组件更新至组件池中；
重复执行上述的步骤a与步骤b，直至组件池中包括多个目标业务组件。
在一种可能的实现方式中，生成任一目标业务组件，包括：
根据业务需求分析确定是否需要进行任一目标业务组件的全新开发；
当需要进行任一目标业务组件的全新开发时，针对任一目标业务组件进行全新的开发处理；
当不需要进行任一目标业务组件的全新开发时，从组件池包括的各个业务组件中，查找与任一目标业务组件相关联的业务组件，并通过对该业务组件进行加工处理，生成任一目标业务组件。
在一种可能的实现方式中，根据获取到的多个目标业务组件构建目标业务的业务链，包括：
通过调度平台，根据多个目标业务组件及多个目标业务组件之间的连接关系，构建目标业务的业务链，并为目标业务分配相应的第一标识信息，其中，多个目标业务组件之间的连接关系是根据图的数据结构生成的；
其中，通过调度业务链，实现针对目标业务的交易请求的交易操作，包括：
通过调度平台，根据第一标识信息，获取业务链，并通过业务链，调度多个目标业务组件，实现针对目标业务的交易请求的交易操作。
在一种可能的实现方式中，在通过调度业务链，实现针对目标业务的交易请求的交易操作的过程中，还包括：
生成针对交易操作的交易标识信息；
其中，实时监控交易操作是否存在异常，包括：
根据交易标识信息，查询业务链中的多个目标业务组件的运行状态及多个目标业务组件之间的数据信息；
根据多个目标业务组件的运行状态及多个目标业务组件之间的数据信息，确定交易操作是否存在异常。
在一种可能的实现方式中，确定交易操作是否存在异常，包括：
通过监控平台确定交易操作是否存在业务异常阻断；
当确定交易操作存在业务异常阻断时，定位发生业务异常阻断的目标业务组件，并获取业务异常阻断对应的业务异常信息和业务交易数据，以及根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
在一种可能的实现方式中，异常处理包括业务重试处理或业务撤销处理；根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理，包括：
当异常处理为业务重试处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始继续进行后续的交易操作；
当异常处理为业务撤销处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始逆序进行各个目标业务组件的业务撤销操作，其中，该逆序是与业务链中的多个目标业务组件执行交易操作的顺序相反的顺序。
一方面，提供了一种业务处理装置，包括：
第一处理模块，用于对目标业务的业务需求进行分析，并根据分析结果将目标业务拆分为多个目标业务组件；
第二处理模块，用于从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，其中，组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；
第三处理模块，用于通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常。
在一种可能的实现方式中，第二处理模块在从组件池中获取多个目标业务组件时，用于：
步骤a、分析确定组件池中是否包括多个目标业务组件；
步骤b、确定组件池中包括多个目标业务组件时，直接从组件池中获取多个目标业务组件；确定组件池中不包括多个目标业务组件中的任一目标业务组件时，生成任一目标业务组件，并将任一目标业务组件更新至组件池中；
重复执行上述的步骤a与步骤b，直至组件池中包括多个目标业务组件。
在一种可能的实现方式中，第二处理模块在生成任一目标业务组件时，用于：
根据业务需求分析确定是否需要进行任一目标业务组件的全新开发；
当需要进行任一目标业务组件的全新开发时，针对任一目标业务组件进行全新的开发处理；
当不需要进行任一目标业务组件的全新开发时，从组件池包括的各个业务组件中，查找与任一目标业务组件相关联的业务组件，并通过对该业务组件进行加工处理，生成任一目标业务组件。
在一种可能的实现方式中，第二处理模块在根据获取到的多个目标业务组件构建目标业务的业务链时，用于：
通过调度平台，根据多个目标业务组件及多个目标业务组件之间的连接关系，构建目标业务的业务链，并为目标业务分配相应的第一标识信息，其中，多个目标业务组件之间的连接关系是根据图的数据结构生成的；
其中，第三处理模块用于通过调度平台，根据第一标识信息，获取业务链，并通过业务链，调度多个目标业务组件，实现针对目标业务的交易请求的交易操作。
在一种可能的实现方式中，第三处理模块在通过调度业务链，实现针对目标业务的交易请求的交易操作时，还用于生成针对交易操作的交易标识信息；
其中，第三处理模块在实时监控交易操作是否存在异常时，用于：
根据交易标识信息，查询业务链中的多个目标业务组件的运行状态及多个目标业务组件之间的数据信息；
根据多个目标业务组件的运行状态及多个目标业务组件之间的数据信息，确定交易操作是否存在异常。
在一种可能的实现方式中，第三处理模块在确定交易操作是否存在异常时，用于：
通过监控平台确定交易操作是否存在业务异常阻断；
当确定交易操作存在业务异常阻断时，定位发生业务异常阻断的目标业务组件，并获取业务异常阻断对应的业务异常信息和业务交易数据，以及根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
在一种可能的实现方式中，异常处理包括业务重试处理或业务撤销处理；第三处理模块在根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理时，用于：
当异常处理为业务重试处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始继续进行后续的交易操作；
当异常处理为业务撤销处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始逆序进行各个目标业务组件的业务撤销操作，其中，该逆序是与业务链中的多个目标业务组件执行交易操作的顺序相反的顺序。
一方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的业务处理方法。
一方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的业务处理方法。
本申请实施例提供的业务处理方法，通过从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，使得通过组件池中的多个相互独立、且互无依赖的业务组件，不仅可以有效提升目标业务的开发效率，最大程度的实现已有资源的复用，而且可以保持代码分离，有利于后期维护；通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常，使得可以在目标业务的交易过程中，能够实时确定异常交易，便于后续在线进行异常问题的排查。
本申请实施例附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。
附图说明
本申请实施例上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本申请实施例的业务处理方法的流程示意图；
图2为本申请实施例的业务链中的多个业务组件的装配示意图；
图3为本申请实施例的异常阻断交易监控示意图；
图4为本申请实施例的业务处理的整体过程示意图；
图5为本申请实施例的业务处理装置的基本结构示意图；
图6为本申请实施例的电子设备的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
下面以具体地实施例对本申请实施例的技术方案以及本申请实施例的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
本申请一个实施例提供了一种业务处理方法，该方法由计算机设备执行，该计算机设备可以是终端或者服务器。终端可以是台式设备或者移动终端。服务器可以是独立的物理服务器、物理服务器集群或者虚拟服务器。如图1所示，该方法包括：
步骤s110，对目标业务的业务需求进行分析，并根据分析结果将目标业务拆分为多个目标业务组件；步骤s120，从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，其中，组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；步骤s130，通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常。
目标业务可以是银行行业的各种业务，例如存款业务、取款业务、查询业务、转账业务、缴费业务、票据业务、银承自动放款业务、公信贷业务等等，也可以是其它行业的各种业务，例如浏览器的浏览业务，又例如软件平台上的软件开发业务等。
在构建目标业务(例如票据业务)的过程中，可以先确定目标业务的业务需求，接着对目标业务的业务需求进行分析，得到业务需求的分析结果，接着，根据得到的分析结果将目标业务拆分为粒度足够小的多个基础业务组件(即多个目标业务组件)，即将目标业务拆分为多个目标业务组件。例如，可以将目标业务拆分为目标业务组件a1(亦可记作基础业务组件a1)、目标业务组件a2(亦可记作基础业务组件a2)、目标业务组件a3(亦可记作基础业务组件a3)、…、目标业务组件a10(亦可记作基础业务组件a10)，即将目标业务的开发拆解为其包括的多个基础业务组件的开发；又例如，可以将目标业务拆分为目标业务组件b1(亦可记作基础业务组件b1)、目标业务组件b2(亦可记作基础业务组件b2)、目标业务组件b3(亦可记作基础业务组件b3)、…、目标业务组件b15(亦可记作基础业务组件b15)。
在将目标业务拆分为多个目标业务组件后，可以从已有的组件池中寻找相匹配的基础业务组件，比如从已有的组件池中寻找该多个目标业务组件，从而可以复用已经的基础业务组件，接着，根据查找到的多个目标业务组件构建目标业务的业务链，即通过组件池中存储有的多个目标业务组件来快速、便捷地搭建目标业务的业务链，从而不仅可以快速便捷地构建目标业务的业务链，有效减少目标业务的业务代码的开发工作，无需花费大量人力、时间用于目标业务的全新开发，极大降低工作量和时间成本。其中，组件池中预存储有大量的业务组件(即基础业务组件)，各个基础业务组件之间是相互独立的、互无依赖的，从而可以最大程度地实现了基础业务组件之间的代码分离、目标业务的业务代码的分离，降低目标业务的代码之间的耦合性，极利于目标业务的后期维护及健壮性。
在构建完成目标业务的业务链后，后续在接收到该目标业务的交易请求时，便可以通过调度该目标业务的业务链，来实现针对该目标业务的交易请求的交易操作，其中，在在线实现目标业务的交易操作的过程中，可以对交易操作进行实时监控，以确定交易操作是否存在异常，从而可以在确定交易操作存在异常时，能够及时在线进行异常排查，全球便于后续能够准确采取相应的后续处理操作。
本申请实施例提供的业务处理方法，通过从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，使得通过组件池中的多个相互独立、且互无依赖的业务组件，不仅可以有效提升目标业务的开发效率，最大程度的实现已有资源的复用，而且可以保持代码分离，有利于后期维护；通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常，使得可以在目标业务的交易过程中，能够实时确定异常交易，便于后续在线进行异常问题的排查。
下面对本申请实施例进行具体介绍：
在一种可能的实现方式中，在从组件池中获取目标业务的多个目标业务组件的过程中，可以执行如下处理：步骤a、分析确定组件池中是否包括多个目标业务组件；步骤b、确定组件池中包括多个目标业务组件时，直接从组件池中获取多个目标业务组件；确定组件池中不包括多个目标业务组件中的任一目标业务组件时，生成任一目标业务组件，并将任一目标业务组件更新至组件池中；重复执行上述的步骤a与步骤b，直至组件池中包括多个目标业务组件。
在一个示例中，在从组件池中获取目标业务的多个目标业务组件的过程中执行如下处理：
首先，需要分析确定组件池中是否包括该多个目标业务组件。
其次，如果确定组件池中包括该多个目标业务组件，说明先前开发其它业务时涉及到这些业务组件的开发，这些业务组件可以满足当前的目标业务的开发需求，故可以直接复用已有的业务组件，无需再额外花时间与精力进行同样的业务组件的开发，即可以直接复用组件池中的该多个目标业务组件，直接利用该多个目标业务组件构建目标业务的业务链。如果确定组件池中不包括该多个目标业务组件中的任一个，例如，多个目标业务组件分别为目标业务组件a1、目标业务组件a2、目标业务组件a3、…、及目标业务组件a10，若组件池中不包括该10个目标业务组件中的目标业务组件a4，说明之前开发的所有业务均没有涉及该目标业务组件a4的开发，故无法直接复用，此时，需要花费一定的时间与精力生成目标业务组件a4，即需要生成目标业务组件a4；其中，当生成目标业务组件a4后，将生成的目标业务组件a4更新至组件池中，以便后续构建其它的目标业务时能够复用。
其中，当将目标业务组件a4更新至组件池后，便可以在组件池中查找到目标业务组件a4，此时，可以根据组件池中原来已有的目标业务组件a1、目标业务组件a2、目标业务组件a3、目标业务组件a5、…、目标业务组件a10、以及新更新到组件池中的目标业务组件a4，构建目标业务的业务链。
需要说明的是，对于首次的业务开发，组件池中是没有任何业务组件的，此时，需要将该首次的业务开发拆分为多个相应的基础业务组件的开发，每当完成一个基础业务组件的开发就将该开发完成的基础业务组件更新到组件池中，以用于后续开发类似业务时能够使用，即复用该开发完成的基础业务组件。每当完成一个业务的各个基础业务组件的开发后，就将该业务包括的各个基础业务组件更新到组件池中，依此类推，经过一段时间的积累后，组件池中的基础业务组件的数量将越来越多，从而随着组件库的丰富，后续开发工作将越来越高效、简便。
在一种可能的实现方式中，在生成任一目标业务组件的过程中，可以执行如下处理：首先，根据业务需求分析确定是否需要进行任一目标业务组件的全新开发；接着，当需要进行任一目标业务组件的全新开发时，针对任一目标业务组件进行全新的开发处理；当不需要进行任一目标业务组件的全新开发时，从组件池包括的各个业务组件中，查找与任一目标业务组件相关联的业务组件，并通过对该业务组件进行加工处理，生成任一目标业务组件。
具体地，当在组件池中未查找到目标业务的多个目标业务组件中的任一个(例如目标业务组件a4)时，需要生成该任一个目标业务组件(例如目标业务组件a4)，以满足目标业务的业务需求，从而构建目标业务的业务链。
在一个示例中，假定该任一个目标业务组件为目标业务组件a4，则在生成目标业务组件a4时，首先，需要根据目标业务的业务需求，分析确定是否需要进行目标业务组件a4的全新开发；接着，当确定需要进行目标业务组件a4的全新开发时，即在不依赖组件池中任意一个已有业务组件的基础上，进行全新的目标业务组件a4的开发，实现目标业务组件a4的从无到有的设计与开发，此时，需要针对目标业务组件a4进行全新的开发处理，开发生成目标业务组件a4；当确定不需要进行目标业务组件a4的全新开发时，说明此时可以在组件池中的已有业务组件的基础上，生成目标业务组件a4，比如，通过对组件池中的已有业务组件进行二次加工处理，来生成目标业务组件a4。
其中，在对组件池中的已有业务组件进行二次加工处理的过程中，首先，从组件池中选取(或查找)与目标业务组件a4相关联的业务组件，比如，从组件池的已有业务组件中选取与目标业务组件a4的相关度大于预定阈值的业务组件；接着，对该选取出的业务组件进行加工处理，比如进行前处理或后处理，来生成目标业务组件a4。对选取出的业务组件进行加工处理可以采用装饰模式，即在不改变原来的业务组件的基础上，定制化全新的目标业务组件a4(可以记作定制业务组件a4)，从而降低业务组件之间的耦合性。
需要说明的是，每个业务组件都包括有正向业务处理部分(即交易操作正常时执行的部分)和逆序业务回退操作部分(即交易操作存在异常时撤销回退时执行的部分)。
在一种可能的实现方式中，在根据获取到的多个目标业务组件构建目标业务的业务链的过程中，可以通过调度平台，根据多个目标业务组件及多个目标业务组件之间的连接关系，构建目标业务的业务链，并为目标业务分配相应的第一标识信息，其中，多个目标业务组件之间的连接关系是根据图的数据结构生成的。
其中，在通过调度业务链，实现针对目标业务的交易请求的交易操作的过程中，可以通过调度平台，根据第一标识信息，获取业务链，并通过业务链，调度多个目标业务组件，实现针对目标业务的交易请求的交易操作。
具体地，可以根据目标业务的业务流程，通过调度平台将目标业务所需要的多个目标业务组件进行装配，形成完整的业务链，同时，为目标业务分配相应的第一标识信息，比如为目标业务分配一个唯一的业务id，用以区分不同的目标业务。相当于，一个业务链由多个目标业务组件构成。其中，在形成完整的业务链的过程中，可以采用图的数据结构构建多个目标业务组件之间的连接关系，在图的数据结构中，每个目标业务组件都是图中的一个节点，相当于，根据业务流程，在图的数据结构的基础上，建立多个目标业务组件之间的有向图，即生成多个目标业务组件之间的连接关系；接着，根据多个目标业务组件及多个目标业务组件之间的连接关系，构建完整的业务链。
其中，图的数据结构可以灵活支持多个目标业务组件之间的串联、并联等多样的组合方式，如图2所示。在图2中，组件池中包括有多个基础业务组件及定制业务组件，该定制业务组件是在组件池中的已有业务组件的基础上进行定制化的二次加工处理生成的新业务组件。
具体地，在为目标业务分配相应的第一标识信息后，在调度目标业务的过程中，可以通过调度平台，根据该第一标识信息，获取目标业务的业务链(比如根据目标业务的id调起相应的业务链)，并通过该业务链，调度相应的多个目标业务组件(比如根据目标业务组件的id调起相应的目标业务组件)，从而实现针对目标业务的交易请求的交易操作。
在一种可能的实现方式中，在通过调度业务链，实现针对目标业务的交易请求的交易操作的过程中，还可以生成针对交易操作的交易标识信息。其中，在实时监控交易操作是否存在异常的过程中，可以执行如下处理：首先，根据交易标识信息，查询业务链中的多个目标业务组件的运行状态及多个目标业务组件之间的数据信息；接着，根据多个目标业务组件的运行状态及多个目标业务组件之间的数据信息，确定交易操作是否存在异常。
具体地，当接收到针对目标业务的交易请求(相当于接收到目标业务的交易的触发请求)时，调度平台首先根据目标业务的第一标识信息(比如目标业务的id)，获取相应的业务链，同时生成针对目标业务的交易操作的交易标识信息，比如产生目标业务的交易操作的唯一交易流水，以用于后续监控平台查询交易运行状态；接着，逐一调度该业务链对应的目标业务组件进行相应的交易操作(即业务操作)。此时，可以将目标业务组件的id和对应的方法名持久化到数据库中，基于反射技术，依据类名调起相应方法处理。
具体地，在实时监控目标业务的交易操作是否存在异常的过程中，可以通过监控平台实时监控目标业务的业务交易状态。其中，可以根据交易标识信息(例如唯一交易流水)，查找目标业务的业务链中的多个目标业务组件的运行状态和多个目标业务组件之间的数据信息，并根据多个目标业务组件的运行状态及多个目标业务组件之间的数据信息，确定交易操作是否存在异常，即排查出失败的业务交易操作，便于在线异常处置。
在一种可能的实现方式中，在确定交易操作是否存在异常的过程中，可以通过监控平台确定交易操作是否存在业务异常阻断；当确定交易操作存在业务异常阻断时，定位发生业务异常阻断的目标业务组件，并获取业务异常阻断对应的业务异常信息和业务交易数据，以及根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
具体地，在通过监控平台确定交易操作是否存在异常的过程中，可以通过监控平台确定交易操作是否存在业务异常阻断，其中，通过监控平台确定交易操作是否存在业务异常阻断的示意图如图3所示，在图3中，当确定目标业务的交易操作存在业务异常阻断时，首先，通过业务异常阻断定位发生业务异常阻断的目标业务组件，例如图3中的目标业务组件n，接着，获取业务异常阻断对应的业务异常信息(例如图3中的错误信息)和业务交易数据(例如图3中的交易数据)，并根据获取到的业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
具体地，在发生业务异常阻断的目标业务组件进行相应的异常处理的过程中，可以确定异常处理是业务重试处理还是业务撤销处理，即异常处理包括业务重试处理或业务撤销处理。其中，当确定异常处理是业务重试处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始继续进行后续的交易操作；当确定异常处理是业务撤销处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始逆序进行各个目标业务组件的业务撤销操作，其中，该逆序是与业务链中的多个目标业务组件执行交易操作的顺序相反的顺序。
在一个示例中，当异常处理是业务重试处理时，通过调度平台基于执行到发生异常的目标业务组件所保存的交易数据和业务异常信息，尝试继续从该发生异常的目标业务组件开始执行后续的交易操作，若此时交易操作执行成功，则转向监控平台继续进行实时监控，若此时交易操作失败，说明交易操作存在业务异常阻断，则重复执行如下处理：当确定交易操作存在业务异常阻断时，通过监控平台定位发生业务异常阻断的目标业务组件，并获取业务异常阻断对应的业务异常信息和业务交易数据，以及根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
在一个示例中，当当异常处理是业务撤销处理时，通过调度平台基于执行到发生异常的目标业务组件所保存的交易数据和业务异常信息，从该发生异常的目标业务组件开始，逆序(即与正常的业务处理流程顺序相反的顺序)逐个目标业务组件进行相应的回退操作(即业务撤销操作)，即删除此次交易操作的交易数据和恢复相关数据状态；其中，若撤销成功，此次交易操作结束，反之，进行线下人工处置。
下面通过具体示例对本申请实施例的业务处理方法进行具体介绍，其中，图4给出了本申请实施例的业务处理的整体过程示意图，在图4中，主要包括四个部分：1、组件开发平台，包括基础业务组件开发或基于现有的业务组件的定制化加工；2、调度平台，基于调度平台进行相应业务组件的组合拼装，形成完整业务链；3、监控平台，基于监控平台实时监控交易操作的执行状况，对发生异常阻断的业务操作进行线上处置；4、在线异常处置平台，对于异常阻断的交易操作，根据相关数据分析，选择业务重试操作或业务撤销操作。详细步骤如下：
步骤s1、对目标业务的整体业务需求详细分析，对目标业务进行基础业务组件级别的粒度拆解，便于最大程度的进行后续扩展复用。
步骤s2、基于现有的组件池，分析是否能满足此目标业务的业务需求。
步骤s3、若现有组件池完全可以满足此目标业务的业务需求的开发，则直接到调度平台进行基础业务组件的装配。
步骤s4、反之，分析需要进行新的基础业务组件开发，还是对已有基础业务组件进行加工，其中，每一个基础业务组件都有一个唯一的业务组件id，调度平台以此调起对应业务组件的处理；
步骤s4.1、若需要开发新的基础业务组件，则在组件池新加入新开发完成的基础业务组件；
步骤s4.2、若只需对现有的基础业务组件进行加工，则对基础业务组件进行前处理或后处理，此时可以采用装饰模式，在不改变原来基础业务组件的基础上，定制化全新的基础业务组件，从而降低基础业务组件之间的耦合性。
需要说明的是，每一个基础业务组件，都包含有正向业务处理部分(交易正常时执行此部分)和逆序业务回退操作部分(交易异常阻断撤销回退时执行此部分)。
步骤s5、更新组件池，再一次分析，现有的组件池是否可以满足目标业务的业务需求，若满足则通过调度平台进入基础业务组件的装备阶段；反之，通过重复执行步骤s2-步骤s4，来不断完善组件池，直至可以满足目标业务的业务需求。
步骤s6、根据目标业务的业务流程，通过调度平台将需要的基础业务组件装配，形成完整的业务链，其中，每一个目标业务会分配一个唯一的业务id，用以区分不同的目标业务，即，一个业务链由若干个基础业务组件构成，可以根据业务id调起相应的业务链，再根据业务组件id调起相应的业务组件。
其中，为支持目前所有的业务组合方式，本申请实施例采用图的数据结构构建基础业务组件间的关系，即每一个基础业务组件都是图中的一个节点，根据业务流程建立基础精力组件的有向图，灵活的支持多个基础业务组件进行串联、并联等多样的组合方式(如图2所示)。当接收到一支交易的触发请求时，通过调度平台首先根据其业务id，获取相应的业务链，同时产生此交易的唯一交易流水(用于监控平台查询交易运行状态)，然后，逐一调起该业务链对应的基础业务组件进行相应的业务操作。在本申请实施例中，将业务组件id和对应方法名持久化到数据库中，基于反射技术，依据类名调起相应方法处理。
步骤s7、通过监控平台实时监控各业务交易状态，根据唯一交易流水，可以查询其业务链中的各个基础业务组件的运行状态及组件间数据信息；同时会排列出交易失败的业务交易，便于在线异常处置(如图3所示)。
步骤s8、当发生业务异常阻断时，首先通过监控平台定位发生交易异常的基础业务组件，综合业务异常信息及交易数据，分析后续的处置是业务重试还是业务撤销，其中：
步骤s8.1、当选择业务重试操作时，通过调度平台基于执行到该发生业务异常阻断的基础业务组件保存的交易数据，尝试继续从该发生业务异常阻断的基础业务组件开始执行程序：若此时程序执行成功，转向业务监控平台继续实时监控；若交易失败，则重复执行步骤8；
步骤s8.2、当选择业务撤销操作时，通过调度系统从该发生业务异常阻断的基础业务组件开始，逆序(即与业务流程顺序相反)逐个基础业务组件进行相应的业务回退操作，即删除此笔交易数据和恢复相关数据状态；若撤销成功，此笔交易结束，反之，进行线下人工处置。
步骤s9、所有状态更新至监控平台，统一监控。
本申请实施例的方法，通过将某一类业务细分为粒度足够小的基础业务组件，将某一个业务的开发拆解为其基础业务组件的开发，同时基于非共性的定制化需求，对其中的基础业务组件添加前处理和后处理达到定制效果；然后基于调度平台根据需求将所需的基础业务组件装配起来，组合成最后的业务链。当有类似新产品开发时，依旧可以从已有的组件池中寻找基础业务组件，复用已有的基础业务组件，而新的部分则可以进一步分解为基础业务组件，并将其添加到组件池；当某一业务流程发生改变时，只要按需通过调度平台重新组合基础业务组件即可。由于将业务分解为一个个基础业务组件，从而通过监控平台，可以很清晰地看到某一支具体交易的执行情况及运行信息，进而可以通过基于调度平台，对存在异常的交易操作进行有条件的交易重试或者交易撤销。
图5为本申请又一实施例提供的一种业务处理装置的结构示意图，如图5所示，该装置500可以包括第一处理模块501、第二处理模块502与第三处理模块503；其中：
第一处理模块501，用于对目标业务的业务需求进行分析，并根据分析结果将目标业务拆分为多个目标业务组件；
第二处理模块502，用于从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，其中，组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；
第三处理模块503，用于通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常。
在一种可能的实现方式中，第二处理模块在从组件池中获取多个目标业务组件时，用于：
步骤a、分析确定组件池中是否包括多个目标业务组件；
步骤b、确定组件池中包括多个目标业务组件时，直接从组件池中获取多个目标业务组件；确定组件池中不包括多个目标业务组件中的任一目标业务组件时，生成任一目标业务组件，并将任一目标业务组件更新至组件池中；
重复执行上述的步骤a与步骤b，直至组件池中包括多个目标业务组件。
在一种可能的实现方式中，第二处理模块在生成任一目标业务组件时，用于：
根据业务需求分析确定是否需要进行任一目标业务组件的全新开发；
当需要进行任一目标业务组件的全新开发时，针对任一目标业务组件进行全新的开发处理；
当不需要进行任一目标业务组件的全新开发时，从组件池包括的各个业务组件中，查找与任一目标业务组件相关联的业务组件，并通过对该业务组件进行加工处理，生成任一目标业务组件。
在一种可能的实现方式中，第二处理模块在根据获取到的多个目标业务组件构建目标业务的业务链时，用于：
通过调度平台，根据多个目标业务组件及多个目标业务组件之间的连接关系，构建目标业务的业务链，并为目标业务分配相应的第一标识信息，其中，多个目标业务组件之间的连接关系是根据图的数据结构生成的；
其中，第三处理模块用于通过调度平台，根据第一标识信息，获取业务链，并通过业务链，调度多个目标业务组件，实现针对目标业务的交易请求的交易操作。
在一种可能的实现方式中，第三处理模块在通过调度业务链，实现针对目标业务的交易请求的交易操作时，还用于生成针对交易操作的交易标识信息；
其中，第三处理模块在实时监控交易操作是否存在异常时，用于：
根据交易标识信息，查询业务链中的多个目标业务组件的运行状态及多个目标业务组件之间的数据信息；
根据多个目标业务组件的运行状态及多个目标业务组件之间的数据信息，确定交易操作是否存在异常。
在一种可能的实现方式中，第三处理模块在确定交易操作是否存在异常时，用于：
通过监控平台确定交易操作是否存在业务异常阻断；
当确定交易操作存在业务异常阻断时，定位发生业务异常阻断的目标业务组件，并获取业务异常阻断对应的业务异常信息和业务交易数据，以及根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理。
在一种可能的实现方式中，异常处理包括业务重试处理或业务撤销处理；第三处理模块在根据业务异常信息和业务交易数据，对发生业务异常阻断的目标业务组件进行相应的异常处理时，用于：
当异常处理为业务重试处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始继续进行后续的交易操作；
当异常处理为业务撤销处理时，通过调度平台根据业务异常信息和业务交易数据，从发生业务异常阻断的目标业务组件开始逆序进行各个目标业务组件的业务撤销操作，其中，该逆序是与业务链中的多个目标业务组件执行交易操作的顺序相反的顺序。
本申请实施例提供的装置，通过从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，使得通过组件池中的多个相互独立、且互无依赖的业务组件，不仅可以有效提升目标业务的开发效率，最大程度的实现已有资源的复用，而且可以保持代码分离，有利于后期维护；通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常，使得可以在目标业务的交易过程中，能够实时确定异常交易，便于后续在线进行异常问题的排查。
需要说明的是，本实施例为与上述的方法项实施例相对应的装置项实施例，本实施例可与上述方法项实施例互相配合实施。上述方法项实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在上述方法项实施例中。
本申请另一实施例提供了一种电子设备，如图6所示，图6所示的电子设备600包括：处理器601和存储器603。其中，处理器601和存储器603相连，如通过总线602相连。进一步地，电子设备600还可以包括收发器604。需要说明的是，实际应用中收发器604不限于一个，该电子设备600的结构并不构成对本申请实施例的限定。
其中，处理器601应用于本申请实施例中，用于实现图5所示的第一处理模块、第二处理模块及第三处理模块的功能。收发器604包括接收机和发射机。
处理器601可以是cpu，通用处理器，dsp，asic，fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器601也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。
总线602可包括一通路，在上述组件之间传送信息。总线602可以是pci总线或eisa总线等。总线602可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
存储器603可以是rom或可存储静态信息和指令的其他类型的静态存储设备，ram或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom、cd-rom或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
存储器603用于存储执行本申请方案的应用程序代码，并由处理器601来控制执行。处理器601用于执行存储器603中存储的应用程序代码，以实现图5所示实施例提供的业务处理装置的动作。
本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，可实现：对目标业务的业务需求进行分析，并根据分析结果将目标业务拆分为多个目标业务组件；接着，从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，其中，组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；接着，通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常。
本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述实施例所示的方法。其中，通过从组件池中获取多个目标业务组件，并根据获取到的多个目标业务组件构建目标业务的业务链，使得通过组件池中的多个相互独立、且互无依赖的业务组件，不仅可以有效提升目标业务的开发效率，最大程度的实现已有资源的复用，而且可以保持代码分离，有利于后期维护；通过调度业务链，实现针对目标业务的交易请求的交易操作，并实时监控交易操作是否存在异常，使得可以在目标业务的交易过程中，能够实时确定异常交易，便于后续在线进行异常问题的排查。
本申请实施例提供的计算机可读存储介质适用于上述方法的任一实施例。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。
1.一种业务处理方法，其特征在于，包括：
对目标业务的业务需求进行分析，并根据分析结果将所述目标业务拆分为多个目标业务组件；
从组件池中获取所述多个目标业务组件，并根据获取到的所述多个目标业务组件构建所述目标业务的业务链，其中，所述组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；
通过调度所述业务链，实现针对所述目标业务的交易请求的交易操作，并实时监控所述交易操作是否存在异常。
2.根据权利要求1所述的方法，其特征在于，所述从组件池中获取所述多个目标业务组件，包括：
步骤a、分析确定所述组件池中是否包括所述多个目标业务组件；
步骤b、确定所述组件池中包括所述多个目标业务组件时，直接从组件池中获取所述多个目标业务组件；确定所述组件池中不包括所述多个目标业务组件中的任一目标业务组件时，生成所述任一目标业务组件，并将所述任一目标业务组件更新至所述组件池中；
重复执行上述的步骤a与步骤b，直至所述组件池中包括所述多个目标业务组件。
3.根据权利要求2所述的方法，其特征在于，所述生成所述任一目标业务组件，包括：
根据所述业务需求分析确定是否需要进行所述任一目标业务组件的全新开发；
当需要进行所述任一目标业务组件的全新开发时，针对所述任一目标业务组件进行全新的开发处理；
当不需要进行所述任一目标业务组件的全新开发时，从所述组件池包括的各个业务组件中，查找与所述任一目标业务组件相关联的业务组件，并通过对该业务组件进行加工处理，生成所述任一目标业务组件。
4.根据权利要求1所述的方法，其特征在于，所述根据获取到的所述多个目标业务组件构建所述目标业务的业务链，包括：
通过调度平台，根据所述多个目标业务组件及所述多个目标业务组件之间的连接关系，构建所述目标业务的业务链，并为所述目标业务分配相应的第一标识信息，其中，所述多个目标业务组件之间的连接关系是根据图的数据结构生成的；
其中，所述通过调度所述业务链，实现针对所述目标业务的交易请求的交易操作，包括：
通过所述调度平台，根据所述第一标识信息，获取所述业务链，并通过所述业务链，调度所述多个目标业务组件，实现针对所述目标业务的交易请求的交易操作。
5.根据权利要求1或4所述的方法，其特征在于，在所述通过调度所述业务链，实现针对所述目标业务的交易请求的交易操作的过程中，还包括：
生成针对所述交易操作的交易标识信息；
其中，所述实时监控所述交易操作是否存在异常，包括：
根据所述交易标识信息，查询所述业务链中的所述多个目标业务组件的运行状态及所述多个目标业务组件之间的数据信息；
根据所述多个目标业务组件的运行状态及所述多个目标业务组件之间的数据信息，确定所述交易操作是否存在异常。
6.根据权利要求1或5所述的方法，其特征在于，所述确定所述交易操作是否存在异常，包括：
通过监控平台确定所述交易操作是否存在业务异常阻断；
当确定所述交易操作存在业务异常阻断时，定位发生业务异常阻断的目标业务组件，并获取所述业务异常阻断对应的业务异常信息和业务交易数据，以及根据所述业务异常信息和所述业务交易数据，对所述发生业务异常阻断的目标业务组件进行相应的异常处理。
7.根据权利要求6所述的方法，其特征在于，所述异常处理包括业务重试处理或业务撤销处理；所述根据所述业务异常信息和所述业务交易数据，对所述发生业务异常阻断的目标业务组件进行相应的异常处理，包括：
当所述异常处理为业务重试处理时，通过调度平台根据所述业务异常信息和所述业务交易数据，从所述发生业务异常阻断的目标业务组件开始继续进行后续的交易操作；
当所述异常处理为业务撤销处理时，通过调度平台根据所述业务异常信息和所述业务交易数据，从所述发生业务异常阻断的目标业务组件开始逆序进行各个目标业务组件的业务撤销操作，其中，该逆序是与所述业务链中的多个目标业务组件执行交易操作的顺序相反的顺序。
8.一种业务处理装置，其特征在于，包括：
第一处理模块，用于对目标业务的业务需求进行分析，并根据分析结果将所述目标业务拆分为多个目标业务组件；
第二处理模块，用于从组件池中获取所述多个目标业务组件，并根据获取到的所述多个目标业务组件构建所述目标业务的业务链，其中，所述组件池中存储有多个业务组件，各个业务组件之间相互独立、且互无依赖；
第三处理模块，用于通过调度所述业务链，实现针对所述目标业务的交易请求的交易操作，并实时监控所述交易操作是否存在异常。
9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-7任一项所述的方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现权利要求1-7任一项所述的方法。
技术总结