业务数据处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及数据处理技术领域，特别是涉及一种业务数据处理方法、装置、计算机设备和存储介质。

背景技术

“熔断机制”(Circuit Breaker)是金融市场中的常见概念，具有广义和狭义两种概念。广义是指为控制股票、期货或其他金融衍生产品的交易风险，为其单日价格波动幅度规定区间限制，一旦成交价触及区间上下限，交易则自动中断一段时间(“即熔断”)，或就此“躺平”而不得超过上限或下限(“熔而不断”)。狭义则专指指数期货的“熔断”。而金融交易中的“熔断机制”，其作用是避免金融交易产品价格波动过度，给市场一定时间的冷静期，向投资者警示风险，并为有关方面采取相关的风险控制手段和措施赢得时间和机会。对于金融交易来说，熔断是一个有效的风险控制机制。

对于一个金融交易系统来说，金融交易的类别众多，针对每种业务类别，其对应的风险控制的规则也会有所不同。传统的熔断机制，一般只是基于访问流量的简单规则，对系统接口进行控制。但有时候需要基于金融交易业务的规则对系统进行熔断。例如，当运维灾备处理时，交易管控数据无法获取，而访问流量判断的简单规则，并不能及时识别这一问题，从而导致本该管控的客户没有及时的管控。因此，对于包含多种业务类别的复杂金融交易系统，现有的熔断机制并不能很好地监测到每种业务类别中分别存在的风险。

发明内容

基于此，有必要针对上述技术问题，提供一种能够对复杂金融交易系统中多种业务类别的风险进行监测的业务数据处理方法、装置、计算机设备和存储介质。

一种业务数据处理方法，其特征在于，所述方法包括：

获取与至少一个业务类别分别对应的检查配置信息，所述检查配置信息包括检查节点位置和检查规则；

对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于所述当前业务类别所对应的检查配置信息筛选出目标历史业务数据；

基于所述检查规则对所述目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间；

接收业务处理方发起的检查请求；所述业务处理方对应处理所述至少一个业务类别中的其中一个业务类别，且所述检查请求通过所述业务处理方在执行业务处理并达到目标检查节点时触发生成；

基于与所述目标检查节点相匹配的检查配置信息，从所述存储空间中读取对应的目标检查结果；

响应于所述检查请求，反馈读取的所述目标检查结果；反馈的所述目标检查结果用于指示所述业务处理方基于所述目标检查结果进行对应的业务处理。

在其中一个实施例中，所述获取与至少一个业务类别分别对应的检查配置信息之前，所述方法还包括：

获取至少一个业务类别分别对应的业务处理节点，对于每个业务类别，分别从相应的业务处理节点中确定目标业务处理节点；

在各所述目标业务处理节点之前加入对应的检查节点；

对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个所述检查节点的检查配置信息，所述检查配置信息用于对所述业务类别对应的业务数据进行查询。

在其中一个实施例中，

所述检查规则包括检查指标，所述对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个所述检查节点的检查配置信息，包括：

对于每个所述检查节点，根据当前检查节点对应的目标业务处理节点所属的业务类别分别获取对应的检查指标；

确定各检查指标分别对应的检查条件；所述检查条件用于从与当前业务类别对应的历史业务数据中筛选出目标历史业务数据；

对每个所述检查条件进行验证，当基于每个所述检查条件均成功从数据库中查询到所述检查指标对应的目标历史业务数据时，则验证通过，完成所述检查指标的配置。

在其中一个实施例中，所述方法还包括：

对于每个检查节点，根据每个所述检查指标对应检查的业务数据，得到每个所述检查指标对应的权重值；

根据每个所述检查指标和对应的检查权重值，得到当前业务类别在当前检查节点对应的检查规则。

在其中一个实施例中，所述方法还包括：

对于每个所述检查条件，分别确定对应的检查阈值；

当基于所述检查条件对应获得的目标历史业务数据超出所述检查阈值时，触发警报动作，所述警报动作用于将警报信息发送至指定终端。

在其中一个实施例中，所述基于所述检查规则对所述目标历史业务数据进行处理，得到对应的检查结果，包括：

基于所述检查规则对所述目标历史业务数据进行处理，获得结果参数值；

根据所述结果参数值的大小，顺次查询结果分级列表，获得对应的目标结果项；所述结果分级列表中，至少包含有两个结果参数区间，每个结果参数区间对应有一个结果项；

根据目标结果项确定当前业务请求方所执行的业务在当前检查节点对应的检查结果。

在其中一个实施例中，所述方法还包括：

获取所述业务处理方基于所述目标检查结果进行对应的业务处理所得到的业务数据，并基于获取到的业务数据更新相应业务类别所对应的历史业务数据；

按照预设检查周期，周期性地基于所述检查规则对更新后的所述目标历史业务数据进行处理，得到对应的检查结果，以对所述存储空间中与所述检查配置信息关联存储的检查结果进行周期性地更新。

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

获取模块，用于获取与至少一个业务类别分别对应的检查配置信息，所述检查配置信息包括检查节点位置和检查规则；

查询模块，用于对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于所述当前业务类别所对应的检查配置信息筛选出目标历史业务数据；

缓存模块，用于基于所述检查规则对所述目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间；

接收模块，用于接收业务处理方发起的检查请求；所述业务处理方对应处理所述至少一个业务类别中的其中一个业务类别，且所述检查请求通过所述业务处理方在执行业务处理并达到目标检查节点时触发生成；

读取模块，用于基于与所述目标检查节点相匹配的检查配置信息，从所述存储空间中读取对应的目标检查结果；

反馈模块，用于响应于所述检查请求，反馈读取的所述目标检查结果；反馈的所述目标检查结果用于指示所述业务处理方基于所述目标检查结果进行对应的业务处理。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取与至少一个业务类别分别对应的检查配置信息，所述检查配置信息包括检查节点位置和检查规则；

对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于所述当前业务类别所对应的检查配置信息筛选出目标历史业务数据；

基于所述检查规则对所述目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间；

接收业务处理方发起的检查请求；所述业务处理方对应处理所述至少一个业务类别中的其中一个业务类别，且所述检查请求通过所述业务处理方在执行业务处理并达到目标检查节点时触发生成；

基于与所述目标检查节点相匹配的检查配置信息，从所述存储空间中读取对应的目标检查结果；

响应于所述检查请求，反馈读取的所述目标检查结果；反馈的所述目标检查结果用于指示所述业务处理方基于所述目标检查结果进行对应的业务处理。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取与至少一个业务类别分别对应的检查配置信息，所述检查配置信息包括检查节点位置和检查规则；

对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于所述当前业务类别所对应的检查配置信息筛选出目标历史业务数据；

基于所述检查规则对所述目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间；

接收业务处理方发起的检查请求；所述业务处理方对应处理所述至少一个业务类别中的其中一个业务类别，且所述检查请求通过所述业务处理方在执行业务处理并达到目标检查节点时触发生成；

基于与所述目标检查节点相匹配的检查配置信息，从所述存储空间中读取对应的目标检查结果；

响应于所述检查请求，反馈读取的所述目标检查结果；反馈的所述目标检查结果用于指示所述业务处理方基于所述目标检查结果进行对应的业务处理。

上述业务数据处理方法、装置、计算机设备和存储介质，通过对每个业务类别对应的检查信息分别进行检查配置，配置的内容包括检查节点位置和检查规则，根据每个业务类别对应的检查配置信息，从该业务类别的历史业务数据中找到对应的目标历史业务数据，然后基于检查规则对目标历史业务数据进行处理，得到对应的检查结果。当接收到业务处理方发起的检查请求时，根据该业务请求流程对应的业务类别，查找缓存空间中对应的检查结果，根据该检查结果，对业务处理方发起的检查请求进行响应。由于上述方法中对于每个业务类别都单独进行了分类，并设置有对应的检查配置信息，同时，还基于历史业务数据获得了对应的检查结果，对于业务处理方发起的检查请求来说，只要确定了其所属的业务类别，就可以从缓存空间中找到对应的检查结果。由于上述业务数据处理方法对于每个业务类别来说，都有对应的检查配置规则和检查结果，可以对各种类型的业务所对应的熔断问题进行准确处理。

附图说明

图1为一个实施例中业务数据处理方法的应用环境图；

图2为一个实施例中业务数据处理方法的流程示意图；

图3为一个实施例中指标配置过程的流程示意图；

图4为另一个实施例中业务数据处理方法的时序图；

图5为一个实施例中业务处理装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的业务数据处理方法，可以应用于如图1所示的应用环境中。其中，业务熔断系统106分别与业务系统102、业务系统主库104之间具有信息交互，业务系统102处理完成一个业务任务后，将该业务任务对应的业务数据存入业务系统主库104中。业务熔断系统106根据每个业务类别对应的检查配置信息对业务系统主库104进行查询以获得检查结果并存储，同时根据业务系统102的请求提供上述检查结果。

对于具有多种业务类别的业务系统102来说，每种业务类别对应有一个业务系统，例如图1中的业务系统1021和业务系统1022，分别代表一种业务类别，与每种业务类别相对应的，还有一个业务系统主库。如图1所示，业务系统1021用于处理业务类别1中的各种业务任务，在处理业务类别1对应的业务任务1的过程中，当来到业务任务1的检查节点位置时，业务系统1021向业务熔断系统106发出获得当前业务类别1对应的检查结果1的请求，并根据检查结果1对业务任务1进行处理，然后将处理完毕的业务任务1写入对应的业务系统主库1041中。类似的，业务类别2也具有对应的业务系统1022和业务系统主库1042。进一步地，对于每个业务类别，各业务系统主库还对应设有业务系统备库，业务系统备库数据与对应的业务系统主库数据之间定时进行数据同步。

本申请就是基于对上述场景所存在的一些问题进行改进而得到的方案。利用本申请可以实现系统的动态配置化，可快速响应业务需求，改变相应的配置。在对本申请中的业务数据处理方法进行描述之前，首先对本申请的实施例中涉及到的部分名词作如下解释：

业务类别：对于采用相同流程进行处理的一类业务任务的总称，例如，企业贷款审批流程、个人贷款审批流程；

检测节点：在业务类别的处理流程中加入检测节点，在该检测节点对当前处理的业务任务进行检查，检查的类别包括风险检查、阈值检查等，在检测节点获得的检测结果可以用于指示当前处理的业务任务进入下一环节，例如通过、拒绝或者挂起等；

检查规则：业务熔断系统根据检查规则对每个业务类别对应的历史业务数据进行检查，以获得对应的检查结果；

历史业务数据：对于每个业务类别来说，其所对应的每条历史业务数据都是一个业务处理的过程。例如，对于贷款业务类别来说，对应的历史业务数据就是一个个具体的贷款审批过程。对于每条历史业务数据，业务熔断系统在与之相对应的检查节点，采用与之相对应的检查规则对其进行检查。

在一个实施例中，如图2所示，提供了一种业务数据处理方法，以该方法应用于图1中的业务熔断系统为例进行说明，包括以下步骤：

步骤S202，获取与至少一个业务类别分别对应的检查配置信息，检查配置信息包括检查节点位置和检查规则。

具体来说，业务系统需要处理的业务很多，分别归属于不同的类别，每个类别里面的业务对应的操作流程是一样的。例如金融系统处理的多个贷款业务流程属于同一业务类别。对于每个业务类别都具有对应的检查配置信息，业务熔断系统根据检查配置信息对该业务类别对应的业务进行处理。

步骤S204，对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于当前业务类别所对应的检查配置信息筛选出目标历史业务数据。

具体来说，每个业务类别都对应有一定的历史业务数据，业务熔断系统根据检查配置信息，从对应的历史业务数据中获得目标历史业务数据。即，对于每种业务类型，业务熔断系统都会基于与之对应的检查配置信息对存储有与之对应的历史业务数据的数据库进行处理，从数据库中获得与该检查配置信息对应的目标历史业务数据。当上述数据库包括业务系统主库和对应的业务系统备库时，业务熔断系统优先从业务系统备库中查询获得与该检查配置信息对应的目标历史业务数据。当上述数据库仅有一个业务系统主库时，业务熔断系统直接从业务系统主库中查询获得与该检查配置信息对应的目标历史业务数据。采用业务系统主库和业务系统备库的数据库配置方案，可以进一步保证业务数据的安全性。

例如对于贷款业务来说，设置的检查节点是A节点，需要在A节点对历史业务数据进行查询，获得B类型数据。历史业务数据中的B类型数据即为目标历史业务数据。

步骤S206，基于检查规则对目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间。

具体来说，获得目标表历史业务数据后，还需要对其进行进一步的处理，才能得到对应的检查结果。每个业务类别会对应有一套检查配置信息，业务熔断系统会根据每个业务类别对应的检查配套信息从历史业务数据中获得目标历史业务数据，对其进行处理获得对应的检查结果并对应存储。这样，在业务熔断系统里，对于每种业务类别所对应的检查配置信息，都有一个与之对应的检查结果。

步骤S208，接收业务处理方发起的检查请求；业务处理方对应处理至少一个业务类别中的其中一个业务类别，且检查请求通过业务处理方在执行业务处理并达到目标检查节点时触发生成。

具体来说，业务处理方在对业务进行处理的时候，根据当前处理的业务所属业务类别对应的检查配置信息，业务处理方的处理流程来到了检查节点。业务处理方会基于这些信息向业务熔断系统请求获得一个检查结果。

步骤S210，基于与目标检查节点相匹配的检查配置信息，从存储空间中读取对应的目标检查结果。

具体来说，由于检查结果是基于每个业务类别对应的检查配置信息从历史业务数据中获取的，并对应存储在缓存空间中，因此基于业务熔断系统会根据业务处理方所处理的业务在当前检查节点相匹配的检查配置信息，就可以从缓存空间中获得对应的目标检查结果并反馈给业务处理方。

步骤S212，响应于检查请求，反馈读取的目标检查结果；反馈的目标检查结果用于指示业务处理方基于目标检查结果进行对应的业务处理。

具体来说，业务处理方式在从业务熔断系统获得了对应的目标检查结果以后，基于该目标检查结果，可以做出下一步的处理判断。例如，对于金融系统来说，假设在一个贷款流程中，业务熔断系统对于该贷款流程对应的检查配置信息所给出的目标检查结果是“挂起”或“重试”该贷款流程中贷款业务的审批，那么业务处理方就会根据“挂起”或“重试”这一目标检查结果，对当前贷款流程暂停处理或者是重新启动该流程，并将处理完毕的贷款流程作为历史业务数据存储到数据库中。

上述业务数据处理方法中，通过对每个业务类别对应的检查信息分别进行检查配置，配置的内容包括检查节点位置和检查规则，根据每个业务类别对应的检查配置信息，从该业务类别的历史业务数据中找到对应的目标历史业务数据，然后基于检查规则对目标历史业务数据进行处理，得到对应的检查结果。当接收到业务处理方发起的检查请求时，根据该业务请求流程对应的业务类别，查找缓存空间中对应的检查结果，根据该检查结果，对业务处理方发起的检查请求进行响应。由于上述方法中对于每个业务类别都单独进行了分类，并设置有对应的检查配置信息，同时，还基于历史业务数据获得了对应的检查结果，对于业务处理方发起的检查请求来说，只要确定了其所属的业务类别，就可以从缓存空间中找到对应的检查结果。由于上述业务数据处理方法对于每个业务类别来说，都有对应的检查配置规则和检查结果，可以对各种类型的业务所对应的熔断问题进行准确处理。

在一个实施例中，获取与至少一个业务类别分别对应的检查配置信息之前，方法还包括：获取至少一个业务类别分别对应的业务处理节点，对于每个业务类别，分别从相应的业务处理节点中确定目标业务处理节点；在各目标业务处理节点之前加入对应的检查节点；对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个检查节点的检查配置信息，检查配置信息用于对业务类别对应的业务数据进行查询。

具体来说，在获取每种业务类别对应的检查配置信息之前，需要了解该业务类别的业务处理步骤，并在业务处理步骤结束之前加入检查节点。根据具体处理的业务的需求，检查节点可以设置一个或者多个，用于对同一内容或者是不同内容进行检查，例如对于上述贷款流程，可以设置一个节点对流程内容中的贷款人身份信息进行查询，也可以在流程中再设置一个节点对流程内容中的贷款金额进行查询，每个检查节点都有对应的一套检查规则，以获取对应的目标历史业务数据。

上述实施例中，每种业务类型都有对应的检查配置信息，检查信息包括检查节点和检查规则，通过检查和检查规则获得该业务类别对应的检查结果，就可以使得业务系统在对新的业务进行处理的时候，只需要根据该业务的业务类别，就可以准确地获得对应的检查结果，从而及时对其作出准确的处理，避免了因为熔断规则单一而导致无法对每种业务类别检查到位的情况。

在一个实施例中，检查规则包括检查指标，对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个检查节点的检查配置信息，包括：对于每个检查节点，根据当前检查节点对应的目标业务处理节点所属的业务类别分别获取对应的检查指标；确定各检查指标分别对应的检查条件；检查条件用于从与当前业务类别对应的历史业务数据中筛选出目标历史业务数据；对每个检查条件进行验证，当基于每个检查条件均成功从数据库中查询到检查指标对应的目标历史业务数据时，则验证通过，完成检查指标的配置。

具体来说，业务熔断系统为了在检查节点获取确定的目标历史业务数据，需要一定的检查规则，检查规则中就包含有检查指标。检查指标一般是一类数据，包括SQL或者脚本表达式两种，数据源是服务于SQL，用于告诉SQL具体的数据查询地址，以从历史业务数据中获得对应的具体目标历史业务数据。在上述检查指标设置完成后，还需要对其进行验证，确认每个检查指标都可以正常地从存储有历史业务数据的数据库中获得对应的目标历史业务数据，才能确认完成了检查指标的配置。

上述实施例中，不同业务类别的业务数据还会存在一定的差异，通过具体的检查指标配置，可以灵活地对每种业务类别分别提供一个检查结果以对业务进行处理。

在一个实施例中，上述方法还包括：对于每个检查节点，根据每个检查指标对应检查的业务数据，得到每个检查指标对应的权重值；根据每个检查指标和对应的检查权重值，得到当前业务类别在当前检查节点对应的检查规则。

具体来说，对于检查节点来说，其所对应的检查指标可能会有多个，每个检查指标在业务处理过程中的重要性并不相同，因此，针对每个检查指标，还对应有一个权重值，根据权重值，可以得到当前业务类别在当前检查节点对应的检查规则。在一个实施例中，上述检查规则是通过两个具体检查指标相对应的数值运算(例如加减乘除运算)得到相应的检查结果。在另一个实施例中，假设有n个检查规则，则对应的检查规则即为：

检查结果＝检查指标1*权重值1+检查指标2*权重值2+检查指标3*权重值3+…检查指标n*权重值n

上述实施例中，对于每个业务类别来说，在检查节点，每个检查指标都对应有一个权重值，利用检查指标和权重值，可以针对每个具体业务进行准确检查，也可以针对同一业务的不同方面进行检查，从而保证了检查结果的精确性。

在一个实施例中，上述方法还包括：对于每个检查条件，分别确定对应的检查阈值；当基于检查条件对应获得的目标历史业务数据超出检查阈值时，触发警报动作，警报动作用于将警报信息发送至指定终端。

具体来说，对于每个检查指标，如果业务熔断系统基于该检查指标所获得的目标历史业务数据超出了业务熔断系统设定的阈值，那么就会触发警报流程，将超出阈值的检查指标以及对应的目标历史业务数据，一起反馈给监测该检查指标的指定终端，指定终端接收到这个警报信息后，再对其进行处理。进一步地，业务熔断系统反馈警报信息的方式可以是短信、邮件、电话等，本实施例中对此不作具体的限制。

上述实施例中，通过设置检查阈值，可以及时发现异常数据信息并发出警报，避免了业务熔断系统基于异常信息获得异常的检查结果，从而影响到业务流程处理的精确度。

在一个实施例中，基于检查规则对目标历史业务数据进行处理，得到对应的检查结果，包括：基于检查规则对目标历史业务数据进行处理，获得结果参数值；根据结果参数值的大小，顺次查询结果分级列表，获得对应的目标结果项；结果分级列表中，至少包含有两个结果参数区间，每个结果参数区间对应有一个结果项；根据目标结果项确定当前业务请求方所执行的业务在当前检查节点对应的检查结果。

具体来说，业务熔断系统在获得目标历史业务数据后，基于检查规则对其进行处理，可以获得一个结果参数值。与这个结果参数值相对应是，一个结果分级列表。在这个列表中，不同的结果参数值范围对应有一个结果项。例如，对于A～B之间的结果参数值，对应的结果项是N1，对于B～C之间的结果参数值，对应的结果项是N2，对于C～D之间的结果参数值，对应的结果项是N3，以此类推。其中，A、B、C、D与结果参数值具有相同的参数属性，结果参数值可以落入上述A、B、C、D划分出来的参数区间里，结果项N1、N2、N3可以是任意一种指示语句，如“通过”、“挂起”、“重试”等，例如，N1是“通过”指示语句，则业务处理方在接收到N1结果后，对当前处理的流程作出通过处理。需要说明的是，上述“A、B、C、D”划分出来的结果参数值区间，以及对应的“通过”、“挂起”、“重试”等结果项，均为本实施例中为了对上述方法进行说明所使用的具体示例，不视为对上述方法所作出的具体限制。

上述实施例中，通过结果参数值和结果分级列表，可以进一步地对不同的业务类别下的业务处理作出更为精确的判断，极大地节省了人工判断所需要的时间精力。

在一个实施例中，方法还包括：获取业务处理方基于目标检查结果进行对应的业务处理所得到的业务数据，并基于获取到的业务数据更新相应业务类别所对应的历史业务数据；按照预设检查周期，周期性地基于检查规则对更新后的目标历史业务数据进行处理，得到对应的检查结果，以对存储空间中与检查配置信息关联存储的检查结果进行周期性地更新。

具体来说，业务熔断系统在获得每个业务类别在每个检查节点上对应的检查结果后，会将所获得的检查结果缓存至存储空间内。例如，业务熔断系统在t

在下一检查时刻t

上述实施例中，对于每个业务类别，业务熔断系统会按照一定的检查周期来获取对应的检查结果，在下一个检查周期对应的结果来临之前，对于来自于业务处理方的检查请求，业务熔断系统会将当前存储空间内的检查结果反馈给业务处理方，通过这种方式，可以有效保证存储空间内检查结果的可靠性和准确性，是的业务系统可以及时根据检查结果对所处理的业务作出调整，提高了业务系统的抗风险能力。

应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

如图3所示，是一个实施例中，对指标进行配置的具体流程。下面结合图3对上述方法进行进一步的说明。其中，通过业务熔断系统对检查节点、检查规则等进行配置时，具体过程如下。对于具体的业务类别，在获取其业务处理流程后，首先在业务处理流程中配置检查节点，检查节点一般设置在结束之前，数量不少于一个。对于配置好的检查节点，还需要进一步配置检查项，即检查指标。虽然不同的业务类别其处理流程和检查规则不尽相同，但是部分业务数据内容可能相同，例如版本信息、数据源等，对于相同的数据内容，获取该内容的检查指标是一致的。因此对于在其他业务流程配置过程中已经出现过的检查指标，都会被保存在一个专门的检查指标清单集合中，对当前的检查项进行配置时，首先确认该检查指标是否存在于检查指标清单集合中，如果存在，则将其从集合中直接取出，即完成检查项中各检查指标的配置；如果不存在，则需要针对需要配置的信息创建新的检查指标(即图3中的熔断指标)，并将新创建的检查指标发布至检查指标清单集合中，完成检查项中各检查指标的配置。

检查项中各检查指标配置完成后，依据上述方法，还可以对其进行进一步的熔断表达式配置、告警表达式配置、告警对象配置和告警方式配置，本实施例中对此不作赘述。通过上述流程，可以进一步地完善上述业务数据处理方法。

如图4所示，是一个实施例中，基于上述业务数据处理方法对具体业务进行处理的时序图。下面基于图4，对上述方法作出进一步的说明。

如图4所示，在进行具体的业务处理之前，授权用户先基于业务熔断系统获取了检查配置信息。具体来说，授权用户先通过熔断管理页面访问指标查询器，确认检查配置信息中所需要的检查指标已经存在于检查指标清单集合中，如果不存在，则此时需要将所需要的检查指标添加到检查指标清单集合中。然后，对该检查指标进行验证，具体过程为，利用该检查指标对数据库中的数据进行查询，能够获得对应的目标数据，即为验证通过。对于验证通过的检查指标，即可将其返回至熔断管理页面完成相应配置。同时，基于熔断管理页面，授权用户还可以进一步进行熔断规则、告警规则等配置，全部配置完成后，可以对上述检查配置信息进行缓存，并将相关内容提交至数据库进行保存，以备历史查询。

由于业务熔断系统不需要根据业务处理方的检查请求，实时从数据库中获得对应的检查结果，因此，业务熔断系统只需要根据每个业务类别对应的检查配置信息，就可以独立从数据库中获得每个业务类别对应的检查结果。对于任意的业务类别来说，业务熔断系统从缓存中读取对应的检查配置信息，包括检查节点和检查规则，基于上述检查配置信息获取并启动一个线程以获得检查结果。在执行的过程中，上述线程首先根据检查指标从数据库中获取对应的目标历史业务数据，然后基于检查规则中的计算表达式获得结果参数值，根据上述结果参数值，执行熔断规则阈值判断。然后根据判断结果，一方面将熔断结果(即检查结果)保存到数据库中以备历史查询，另一方面也对熔断结果进行缓存，业务熔断系统对于接下来一段时间内该业务类别下对应的检查请求，都将基于缓存的熔断结果给出检查结果，直至业务熔断服务器获得下一熔断结果更新缓存内容。

对于在阈值判断的过程中存在异常情况的检查请求，业务熔断系统就会基于事先配置好的告警规则，调用告警器发出告警通知，并将告警结果返回给业务熔断系统。

在一个实施例中，如图5所示，提供了一种业务处理装置，包括：获取模块502，查询模块504，缓存模块506，接收模块508，读取模块510，反馈模块512，其中：

获取模块502，用于获取与至少一个业务类别分别对应的检查配置信息，检查配置信息包括检查节点位置和检查规则；

查询模块504，用于对于每个业务类别，分别从与当前业务类别对应的历史业务数据中，基于当前业务类别所对应的检查配置信息筛选出目标历史业务数据；

缓存模块506，用于基于检查规则对目标历史业务数据进行处理，得到对应的检查结果，并将每个业务类别所对应的检查结果和检查配置信息关联存储至存储空间；

接收模块508，用于接收业务处理方发起的检查请求；业务处理方对应处理至少一个业务类别中的其中一个业务类别，且检查请求通过业务处理方在执行业务处理并达到目标检查节点时触发生成；

读取模块510，用于基于与目标检查节点相匹配的检查配置信息，从存储空间中读取对应的目标检查结果；

反馈模块512，用于响应于检查请求，反馈读取的目标检查结果；反馈的目标检查结果用于指示业务处理方基于目标检查结果进行对应的业务处理。

上述业务处理装置，通过对每个业务类别对应的检查信息分别进行检查配置，配置的内容包括检查节点位置和检查规则，根据每个业务类别对应的检查配置信息，从该业务类别的历史业务数据中找到对应的目标历史业务数据，然后基于检查规则对目标历史业务数据进行处理，得到对应的检查结果。当接收到业务处理方发起的检查请求时，根据该业务请求流程对应的业务类别，查找缓存空间中对应的检查结果，根据该检查结果，对业务处理方发起的检查请求进行响应。由于上述方法中对于每个业务类别都单独进行了分类，并设置有对应的检查配置信息，同时，还基于历史业务数据获得了对应的检查结果，对于业务处理方发起的检查请求来说，只要确定了其所属的业务类别，就可以从缓存空间中找到对应的检查结果。由于上述业务数据处理方法对于每个业务类别来说，都有对应的检查配置规则和检查结果，可以对各种类型的业务所对应的熔断问题进行准确处理。

在一个实施例中，获取模块，还用于：获取至少一个业务类别分别对应的业务处理节点，对于每个业务类别，分别从相应的业务处理节点中确定目标业务处理节点；在各目标业务处理节点之前加入对应的检查节点；对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个检查节点的检查配置信息，检查配置信息用于对业务类别对应的业务数据进行查询。

上述实施例中，每种业务类型都有对应的检查配置信息，检查信息包括检查节点和检查规则，通过检查和检查规则获得该业务类别对应的检查结果，就可以使得业务系统在对新的业务进行处理的时候，只需要根据该业务的业务类别，就可以准确地获得对应的检查结果，从而及时对其作出准确的处理，避免了因为熔断规则单一而导致无法对每种业务类别检查到位的情况。

在一个实施例中，检查规则包括检查指标，获取模块，还用于：对于每个检查节点，基于相应检查节点对应的目标业务处理节点所属的业务类别，确定每个检查节点的检查配置信息，包括：对于每个检查节点，根据当前检查节点对应的目标业务处理节点所属的业务类别分别获取对应的检查指标；确定各检查指标分别对应的检查条件；检查条件用于从与当前业务类别对应的历史业务数据中筛选出目标历史业务数据；对每个检查条件进行验证，当基于每个检查条件均成功从数据库中查询到检查指标对应的目标历史业务数据时，则验证通过，完成检查指标的配置。

上述实施例中，不同业务类别的业务数据还会存在一定的差异，通过具体的检查指标配置，可以灵活地对每种业务类别分别提供一个检查结果以对业务进行处理。

在一个实施例中，获取模块，还用于：对于每个检查节点，根据每个检查指标对应检查的业务数据，得到每个检查指标对应的权重值；根据每个检查指标和对应的检查权重值，得到当前业务类别在当前检查节点对应的检查规则。

上述实施例中，对于每个业务类别来说，在检查节点，每个检查指标都对应有一个权重值，利用检查指标和权重值，可以针对每个具体业务进行准确检查，也可以针对同一业务的不同方面进行检查，从而保证了检查结果的精确性。

在一个实施例中，获取模块，还用于：对于每个检查条件，分别确定对应的检查阈值；当基于检查条件对应获得的目标历史业务数据超出检查阈值时，触发警报动作，警报动作用于将警报信息发送至指定终端。

上述实施例中，通过设置检查阈值，可以及时发现异常数据信息并发出警报，避免了业务熔断系统基于异常信息获得异常的检查结果，从而影响到业务流程处理的精确度。

在一个实施例中，缓存模块，还用于：基于检查规则对目标历史业务数据进行处理，获得结果参数值；根据结果参数值的大小，顺次查询结果分级列表，获得对应的目标结果项；结果分级列表中，至少包含有两个结果参数区间，每个结果参数区间对应有一个结果项；根据目标结果项确定当前业务请求方所执行的业务在当前检查节点对应的检查结果。

上述实施例中，通过结果参数值和结果分级列表，可以进一步地对不同的业务类别下的业务处理作出更为精确的判断，极大地节省了人工判断所需要的时间精力。

在一个实施例中，缓存模块，还用于：获取业务处理方基于目标检查结果进行对应的业务处理所得到的业务数据，并基于获取到的业务数据更新相应业务类别所对应的历史业务数据；按照预设检查周期，周期性地基于检查规则对更新后的目标历史业务数据进行处理，得到对应的检查结果，以对存储空间中与检查配置信息关联存储的检查结果进行周期性地更新。

上述实施例中，对于每个业务类别，业务熔断系统会按照一定的检查周期来获取对应的检查结果，在下一个检查周期对应的结果来临之前，对于来自于业务处理方的检查请求，业务熔断系统会将当前存储空间内的检查结果反馈给业务处理方，通过这种方式，可以有效保证存储空间内检查结果的可靠性和准确性，是的业务系统可以及时根据检查结果对所处理的业务作出调整，提高了业务系统的抗风险能力。

关于业务处理装置的具体限定可以参见上文中对于业务数据处理方法的限定，在此不再赘述。上述业务处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储历史业务数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务数据处理方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。