CN114710403B - 数据调度方法、装置、设备、介质及程序产品 - Google Patents

Abstract

本申请公开了一种数据调度方法、装置、设备、介质及程序产品。该方法应用于办件调度系统，包括：根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，所述办件事项转发请求由接件业务系统发送，所述转发请求包括办件事项数据；基于所述路由信息，将所述办件事项数据转发至受理业务系统，在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作。通过上述方法能够对办件事项进行全量监测，通过整体调控办件事项的调度，在办件事项处理过程中出现故障时，采取熔断操作，避免因出现过载现象而造成整个系统故障。

Description

数据调度方法、装置、设备、介质及程序产品

技术领域

本申请属于计算机技术领域，尤其涉及一种数据调度方法、装置、设备、介质及程序产品。

背景技术

随着互联网技术发展，各地业务处理系统可以网上处理各种办件事项，并且可以实现异地办理。在实现异地办理时，需要本地业务处理系统与归属地业务处理系统对接。然而，由本地业务系统与归属地业务系统直接对接，需要进行远程服务的调用。现有技术中，如果调用的远程服务或者资源由于出现故障或错误时，会导致请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源，由局部的、小规模的故障最终导致业务系统的全线崩溃。

发明内容

有鉴于此，本申请实施例提供的一种数据调度方法、装置、设备、介质及程序产品，能够对办件事项进行全量监测，在检测到办件事项处理过程中出现故障时，采取熔断操作，避免出现过载现象而造成整个系统故障。

第一方面，本申请实施例提供一种方法数据调度方法，应用于办件调度系统。该方法可以包括：

根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，所述办件事项转发请求由接件业务系统发送，所述转发请求包括办件事项数据；

基于所述路由信息，将所述办件事项数据转发至受理业务系统；

在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作。

第二方面，本申请实施例提供了一种数据调度装置，应用于办件调度系统，该装置可以包括：

确定模块，用于根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，所述办件事项转发请求由接件业务系统发送，所述转发请求包括办件事项数据；

转发模块，用于基于所述路由信息，将所述办件事项数据转发至受理业务系统；

熔断模块，用于在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作。

第三方面，本申请实施例提供了一种计算机设备，该设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如第一方面所述的数据调用方法。

第四方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如第一方面所述的数据调用方法。

第五方面，本申请实施例提供了一种计算机程序产品，包括计算机程序或指令，所述计算机程序或指令被处理器执行时实现如第一方面所述的数据调用方法。

本申请实施例提供的一种数据调度方法、装置、计算机设备、计算机存储介质一级计算机程序产品，能够接收从接件业务系统发送的转发请求，其中，办件请求中包括办件事项数据，基于所述办件事项数据，从路由配置表中确定受理业务系统的路由信息，然后基于所述路由信息，将所述办件事项数据转发至受理业务系统，在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作，如此，通过办件调度系统可以检测整个办件事项的转发过程，在某个办件事项的垮业务系统转发处理的过程中出现故障，可以针对该办件事项采取熔断操作，避免办件事项转发请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源。通过上述方法能够对办件事项进行全量监测，通过整体调控办件事项的调度，在办件事项处理过程中出现故障时，采取熔断操作，避免出现过载现象而造成整个系统故障。

附图说明

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

图1示出本申请实施提供的一种数据调度的系统构架示意图；

图2示出本申请提供的一种数据调度方法的流程示意图；

图3示出本申请实施例提供的另一种数据调度方法的流程示意图；

图4示出本申请实施例提供的又一种数据调度方法的流程示意图；

图5示出本申请实施例提供的一种查询信息获取方法的流程示意图；

图6示出本申请实施例提供的一种数据调度装置的结构示意图；

图7示出本申请实施例提供的另一种数据调度装置的结构示意图；

图8示出本申请实施例提供的一种计算机设备的硬件结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

目前，接件业务系统可以与受理业务系统直接对接，从而实现办件事项的转发以及办件事项的异地办理，如此，使得用户可以办理跨区域通办事项。然而，采用直接对接的方式，则无法对事项转发过程进行监测，从而无法整体调控办件事项的调度。由于各地业务系统是由各地分别统筹构建。因此，各地业务系统的开发框架可能不同，导致各个业务系统的接口标准不一致，如此，在不同业务系统的对接过程中，需要不断修改接口数据，造成系统建设成本高以及系统维护困难等技术问题。

此外，各业务系统在办件事项的转发过程中，由于各业务系统之间进行办件事项转发时无法对事项转发过程进行监测，从而无法及时且准确确定故障业务，并及时进行故障处理。因此，在出现故障或者由于某种原因无法处理办件事项时，会导致请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源，最终导致整个系统崩溃。

图1示出本申请实施提供的一种数据调度的系统构架示意图。如图1所示，该系统架构10可以包括接件业务系统11、受理业务系统13以及设置在接件业务系统11与受理业务系统13之间的办件调度系统12。其中，该办件调度系统12可以用于汇聚各个系统的办件数据，并且可以调度分发办件数据，从而不仅使得各系统之间数据同步，而且还可以实现各个系统之间办件数据的调度，同时兼顾对整个办件转发过程的监控。以及，该办件调度系统还可以提供对外的标准接口，便于与各个系统对接，从而可以减少对各个业务系统的改造。

此外，办件调度系统12还可以依据数据信息为用户提供办件量、办件分布区域和办件时长等统计数据分析功能，同时提供服务状态监控数据统计、流水日志和熔断补偿机制配置等服务调用数据情况与配置功能。

在本申请实施例中，接件业务系统11和受理业务系统13属于不同区域的系统。接件业务系统11和受理业务系统13可以为各种类型的业务系统，例如，政务服务业务系统、银行业务系统和移动业务系统等。在本申请实施例中，对于接件业务系统与受理业务系统的业务类型不做限制。

在一个示例中，用户通过“跨省通办”专区自助填报“跨省通办”办件，提交至“跨省通办”区域支撑平台的统一接件业务系统，进行接件处理。接件业务系统接件后，将办件事项数据提交到区域支撑平台的业务调度系统，进行业务赋码、材料拆分、办件分发、状态变更和流程跟踪等处理，分发到各区域服务系统(即受理业务系统)进行受理和审批，从而实现异地办理办件事项。

需要说明的是，本申请实施例涉及的“接件业务系统”可以为一个或者多个业务系统。“受理业务系统”可以为一个或者多个业务系统。

图2示出本申请提供的一种数据调度方法的流程示意图。如图2所示，数据调度方法可以应用于如图1所示的办件调度系统，可以包括以下步骤。

S21，根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息。

这里，办件事项转发请求由接件业务系统发送，转发请求包括办件事项数据。

S22，基于路由信息，将办件事项数据转发至受理业务系统。

S23，在接收受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作。

在本申请实施例中，能够接收从接件业务系统发送的转发请求，其中，办件请求中包括办件事项数据，基于所述办件事项数据，从路由配置表中确定受理业务系统的路由信息，然后基于所述路由信息，将所述办件事项数据转发至受理业务系统，在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作，如此，通过办件调度系统可以检测整个办件事项的转发过程，在某个办件事项的垮业务系统转发处理的过程中出现故障，可以针对该办件事项采取熔断操作，避免办件事项转发请求的资源阻塞在服务器上等待从而耗尽系统或者服务器资源。通过上述方法能够对办件事项进行全量监测，通过整体调控办件事项的调度，在办件事项处理过程中出现故障时，采取熔断操作，避免服务出现过载现象而造成整个系统故障。

下面介绍上述各个步骤的具体实现方式。

在S21中，转发请求可以为针对办件事项的转发请求。该转发请求可以包括办件事项数据。办件事项数据可以是与办件事项关联的数据。可选地，办件事项数据可以包括办件事项、事项类型、事项编号以及事项状态等数据。其中，办件事项可以为各种类型的办件事项，例如公共服务办件事项以及银行办件事项等。

路由配置表可以包括与办件事项对应的路由信息。其中，路由信息为办件事项的转发规则，可以包括受理业务系统的路由信息。此外，路由信息还可以包括办件事项的关联数据。可选地，路由信息还可以包括办件事项的事项编号、事项状态、受理区域信息等至少之一。

在本申请实施例中，转发请求可以由接件业务系统向办件调度系统发送，以使办件调度系统将办件事项从接件业务系统转发至受理业务系统，以便受理业务系统受理以及审批该办件事项。路由配置表可以为预先设置在办件调度系统中，也可以通过可视化界面动态配置，还可以为其它方式生成。这里，对路由配置表的获取方式不做限制。

在S22中，办件调度系统可以基于路由信息，调度受理业务系统，从而将办件事项数据转发至受理业务系统，从而使得受理业务系统受理办件事项。

在一个示例中，接件业务系统获取用户登记的办件事项数据，向办件调度系统发送包含办件事项数据的转发请求。办件调度系统解析转发请求，得到办件事项数据，并基于办件事项数据，从路由配置表中确定路由信息，从而根据路由信息，将办件事项数据转发至受理业务系统，以使受理业务系统受理以及处理办件事项。

如此，办件调度系统不仅实现办件事项数据的调度，而且还可以监控整个办件事项的转发流程，从而可以拥有跨区域通办的全量数据信息，通过数据的承接与传递实现办件事项的办理。

在一些实施例中，为了能够准确匹配与办件事项对应的受理业务系统，路由配置表可以包括事项编码与受理业务系统对应关系。如此，S21可以包括以下步骤：

在办件事项数据可以包括事项编码，且路由信息包括受理业务系统的网际协议地址与端口的情况下，基于事项编码确定路由编号；

基于路由编号，在路由配置表中确定网际协议地址与端口。

这里，事项编码可以为办件事项编号，用于区分不同办件事项的独有标识。事项编码的不同位上的字符可以表示不同的含义。

可选地，事项编码可以包括受理区域行政编码以及事项类型编码。例如，事项编码可以为8位，前4位可以表示受理区域行政编码，以及后4位可以表示事项类型编码。

本申请实施例涉及的“路由编号”可以为受理业务系统独有的路由标识。在本申请实施例中，路由配置表中还可以包括路由编号与网际协议地址和端口的关联关系。基于路由编号，办件调度系统可以从路由配置表中匹配出受理业务系统的网际协议地址与端口。

在上述实施例中，可以通过动态配置的路由配置表可以查询到受理业务系统的地址信息，以便将办件事项数据转发至受理业务系统。此外，可以通过配置路由配置表，灵活改变路由转发规则，从而可以避免在新接入系统后，对办件调度系统的接口进行改造。

在一些实施例中，为了准确确定受理业务系统的接口，在基于所述路由编号，在路由配置表中确定网际协议地址与端口之后，该数据调度方法还可以包括：

在办件事项数据包括事项状态，且路由信息包括受理业务系统的业务接口的统一资源标识符的情况下，基于路由编号和事项状态，确定统一资源标识符。

这里，事项状态可以为办件事项的处理状态。例如，在办件事项为申请异地汇款的情况下，事项状态可以为申请办理异地汇款。不同事项状态对应受理业务系统的不同业务接口。

统一资源标识符(Uniform Resource Identifier,URI)可以用于一个紧凑的字符串用来标示抽象或物理资源。这里，URI可以提供定位受理业务系统的业务接口的地址。

在本申请实施例中，路由配置表还可以包括路由编号和事项状态与URI的关联关系。办件调度系统可以根据路由编号和事项状态，从路由配置表中确定出业务接口的URI。

在上述实施例中，通过事项状态可以进一步确定受理业务系统的业务接口，以便受理系统更准确接收和处理办件事项。

在一个示例中，图3示出本申请实施例提供的另一种数据调度方法的流程示意图，如图3所示，该数据调度方法可以应用于办件调度系统，可以包括如下步骤。

S31，接收传入Map集合。

这里，为了方便传递参数，办件调度系统的接口传入参数可以为图Map类型。也就是，接件受理业务系统将办件事项数据可以封装为传入Map集合，并将其发送至办件调度系统。

S32，判断传入Map集合是否含有受理业务系统的路由编号。在有的情况下，执行S33。在没有的情况下，执行S34。

S33，根据传入Map集合的办件编号从办件表中确定路由编号，继续执行S34以及S35。

S34，根据路由编号从路由配置表中确定受理业务系统的网际协议地址和端口。

S35，根据路由编号以及传入MAP集合中的事项状态查询路由配置表，获取受理业务系统的URI。

需要说明的是，S34与S35不分先后。

S36，根据网际协议地址、端口和URI，调用受理业务系统的业务接口。

这里，办件调度系统可以通过软件开发工具包SDK调用受理业务系统接口，将办件事项数据转发至受理业务系统的业务接口，以便受理业务系统受理和处理办件事项。

在上述实施例中，通过事项编码和事项状态查询路由配置表，从而可以获取受理业务系统的接口URI，再通过SDK调用受理业务系统的接口，从而实现办件事项的调度。并且可以通过前端页面动态配置路由规则，从而可以实现路由的可视化配置。

在S23中，为了减少局部系统故障影响整个系统故障的现象，在S22之后，在获取受理业务系统返回的系统报错信息的情况下，基于熔断策略判断是否执行熔断操作。

这里，在受理业务系统出现系统故障的情况下，办件调度系统在向受理业务系统转发办件事项数据之后，会接收到受理业务系统返回的系统报错信息，继而会根据熔断策略判断是否执行熔断操作。

在一些实施例中，基于熔断策略执行熔断操作，包括：

在接收受理业务系统返回的系统报错信息的情况下，统计办件事项数据重发失败的目标次数；

在目标次数大于熔断策略中配置次数的情况下，熔断器执行重发熔断操作。

其中，熔断器为办件调度系统中的一种状态机，用于控制办件调度系统中某些策略是否会被执行或者熔断。例如熔断器可以控制重连策略是否会被执行或者熔断。熔断策略可以包括但不限于在预设时间段内，某些策略执行的失败次数是否超过预设次数或者失败比率等策略。熔断策略还可以包括的根据错误请求次数、总请求次数、开始时间、是否离线等数据中至少一中数据，设定若预设时间内的错误请求比率或错误请求次数达到预设的阀值，则判定对该办件事项的转发请求的采取对应熔断操作。具体的熔断策略可以根据实际办件调度系统的配置需求来进行设置，本申请不做限定。这里，重发失败可以是指办件调度系统向受理业务系统发送重连请求失败。熔断策略的配置次数可以任意设置。例如，配置次数可以为3次、5次或者更多。重发熔断操作可以是指停止执行重发操作。

具体地，在目标次数大于熔断策略中配置次数的情况下，说明该办件事项数据的转发业务出现了故障而无法发送成功，因此为了避免该办件事项对应的相关服务处于熔断状态，因此为了将局部出现问题的业务系统隔离，避免出现整个系统故障，需要对该办件事项数据的转发进行熔断，即停止向受理业务系统发送重连请求。

在上述实施例中，通过熔断策略，可以将局部出现问题的业务系统隔离，避免出现整个系统故障，并且可以减少无效操作，减轻运行负担。此外，通过熔断功能，可以减少无效数据的重发次数。通过比较重发失败次数与配置次数的大小，确定是否执行重发熔断操作。如此，可以准确提高熔断操作的准确性。

在一些实施例中，在统计接收系统报错信息的目标次数之后，该数据调度方法还包括：

在目标次数小于熔断策略中配置次数的情况下，向所述受理业务系统发送重连请求；

基于受理业务系统针对所述重连请求的响应时间超过配置时间，更新目标次数。

这里，在目标次数小于熔断策略中配置次数的情况下，熔断器不会开启，办件调度系统向受理业务系统发送重连请求。

在本申请实施例中，办件调度系统检测到受理业务系统针对重连请求的响应时间超过配置时间，表示办件调度系统向受理业务系统发送请求失败，更新重发失败的次数，办件调度系统检测到受理业务系统针对重连请求的响应时间不超过配置时间，表示办件调度系统向受理业务系统发送请求成功，目标次数清零。

在本申请实施例中，目标次数可以通过远程字典服务(Remote DictionaryServer，Redis)中计数器进行计算。在重发失败的情况下，延长Redis过期时间，更新计数器的目标次数。在重发成功的情况下，清空计数器。

在一些实施例中，为了进一步保障办件事项数据的正常流转，在S22之前，该数据调度方法还可以包括：

在办件调度系统的流控开关开启的情况下，确定转发请求符合办件调度系统的限流策略。

这里，流控开关可以用于办件调度系统的流量控制。限流策略可以包括以下至少之一：转发请求在免控列表中，以及插件限流策略。其中，插件限流策略可以为限流插件对应的限流策略。在本申请实施例中，插件限流策略可以包括但不限于令牌桶算法、并发限流、漏桶算法以及滑动窗口算法等。

在本申请实施例中，办件调度系统先检测流控开关是否开启，在开启的情况下，判断转发请求是否符合限流策略，从而根据判断结果，确定是否执行S21。在符合的情况下，执行S21。在不符合的情况下，结束数据调度流程。

在上述实施例中，通过流控开关以及限流策略可以对办件调度系统的流量进行控制，尽量降低处理转发请求时对其它业务的影响，保障办件调度系统的服务。

在一些实施例中，在流控开关关闭的情况下，办件调度系统不做流量控制，即立即解析转发请求，执行S21。

在一个示例中，图4示出本申请实施例提供的又一种数据调度方法的流程示意图，如图4所示，在S21之前，该数据调度方法还可以包括：

S41，拦截转发请求。

S42，检查流控开关是否开启。在开启的情况下，执行S43。在不开启的情况下，执行S47。

S43，检测该转发请求是否在免控列表。若在，则执行S47。若不在，则执行S44。

S44，检测是否存在插件限流策略。在存在的情况下，执行S45。在不存在的情况下，执行S46。

S45，确定插件限流策略是否执行成功。在成功的情况下，执行S47。在不成功的情况下，执行S46。

S46，放弃转发请求。

S47，放行转发请求。

在上述实施例中，通过限流，一方面，可以避免大量的请求使得办件调度系统过载，保障服务的可用性。另一方面，可以防止网络攻击。

在一些实施例中，在S21之后，该数据调度方法还可以包括：

基于办件事项数据与路由信息，生成数据调度日志。

这里，数据调度日志可以包括前置日志和路由日志。办件调度系统可以将办件事项数据与路由信息，分别存储为前置日志与路由日志，从而生成数据调度日志。

在本申请实施例中，数据调度日志可以存储在后台数据库中，以日志记录表的方式进行存储。

在上述实施例中，通过将办件事项数据和路由信息保存为日志，可以便于后续对办件事项的全量分析，以及便于用户查询办件事项，对办件事项状态进行流程跟踪。

在一些实施例中，在基于所述办件事项数据与路由信息，生成数据调度日志之后，该数据调度方法还可以包括：

接收办件事项查询请求；

从所述数据调度日志中获取与所述办件事项查询请求对应的查询信息。

这里，办件事项查询请求可以由用户通过系统的前端页面输入查询条件生成，也可以由系统自动触发查询条件生成。在本申请实施例中，对办件事项查询请求的生成方式不做限制。

在本申请实施例中，办件调度系统通过解析办件事项查询请求，获取办件事项查询条件，从数据调度日志中获取与办件事项查询条件对应的查询信息。其中，办件事项查询条件包括但不限于办件事项编号、时间、关键字等。

在上述实施例中，通过从日志中获取办件事项的查询信息，可以便于用户随时监控办件事项的状态，有利于用户对处理流程进行跟踪。

在一个示例中，图5示出本申请实施例提供的一种查询信息获取方法的流程示意图。如图5所示，办件调度系统从业务接口切面捕获数据，并办成在数据库(即生成数据调度日志)中。用户通过前台页面输入查询条件。办件调度系统根据传入的查询条件，从后台数据库中查询到相关日志，返回日志列表给前台页面。

基于上述实施例提供的数据调度方法，相应地，本申请实施例还提供了数据调度装置的实现方式。请参见以下实施例。

图6示出本申请实施例提供的一种数据调度装置的结构示意图。该数据调度装置可以应用于如图1所示的办件调度系统。如图6所示，该数据调度装置60可以包括以下模块。

确定模块61，用于用于根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，办件事项转发请求由接件业务系统发送，转发请求包括办件事项数据；

转发模块62，用于基于所述路由信息，将所述办件事项数据转发至受理业务系统；

熔断模块63，用于在接收受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作。

在一些实施例中，转发模块62可以包括：

路由编号确定子模块，用于在所述办件事项数据包括事项编码，且所述路由信息包括受理业务系统的网际协议地址与端口的情况下，基于所述事项编码确定路由编号；

地址确定子模块，用于基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口。

在一些实施例中，转发模块62还可以包括：

统一资源标识符确定子模块，用于在所述基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口之后，在所述办件事项数据包括事项状态，且所述路由信息包括受理业务系统的业务接口的统一资源标识符的情况下，基于所述路由编码和所述事项状态，确定所述统一资源标识符。

在一些实施例中，熔断模块63，还可以包括：

统计子模块，由于在接收受理业务系统返回的系统报错信息的情况下，统计办件事项数据重发失败的目标次数；

执行子模块，用于在目标次数大于熔断策略中配置次数的情况下，熔断器执行重发熔断操作。

在一些实施例中，熔断模块63，还可以包括：

发送子模块，用于在目标次数小于熔断策略中配置次数的情况下，向受理业务系统发送重连请求；

更新子模块，用于基于受理业务系统针对重连请求的响应时间超过配置时间，更新目标次数。

在一些实施例中，该数据调度装置60还可以包括：

限流模块，用于在所述基于所述办件事项数据，从路由配置表中确定路由信息之前，在所述办件调度系统的流控开关开启的情况下，确定所述转发请求符合所述办件调度系统的限流策略。

在一些实施例中，该数据调度装置60还可以包括：

日志生成模块，用于基于所述办件事项数据与路由信息，生成数据调度日志。

在一些实施例中，该数据调度装置60还可以包括：

第二接收模块，用于接收办件事项查询请求；

信息获取模块，用于从所述数据调度日志中获取与所述办件事项查询请求对应的查询信息。

图7示出本申请实施例提供的另一种数据调度装置的结构示意图。该数据调度装置可以应用于如图1所示的办件调度系统。如图7所示，该数据调度装置70可以包括以下前置模块71、路由模块72和后置模块73。

这里，前置模块71可以包括第一日志记录子模块711和限流模块712。其中，第一日志记录子模块，用于记录接件系统的业务接口发送的请求参数等数据。限流模块712，用于对系统进行限流控制。

路由模块72可以包括第二日志记录子模块721、熔断模块722以及路由动态配置模块723。其中，第二日志记录子模块721，用于记录路由信息等数据。熔断模块，用于对系统的某些策略进行熔断控制。路由动态配置模块723，用于动态配置受理业务系统的路由信息。

后置模块73可以包括第三日志记录子模块731。其中，第三日志记录子模块，用于记录各个业务接口的响应数据。

在上述实施例中，通过链式方法将调度系统中各个功能，包括熔断、限流和记录日志等功能串联，再通过一定的业务逻辑将办件转发到各个受理系统。从而实现对办件数据的转发以及对整个调度过程的监控。

图8示出本申请实施例提供的一种计算机设备的硬件结构示意图。如图8所示。在计算机设备可以包括处理器81以及存储有计算机程序指令的存储器82。

具体地，上述处理器81可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器82可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器82可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器82可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器82可在综合网关容灾设备的内部或外部。在特定实施例中，存储器82是非易失性固态存储器。

存储器82可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请的一方面的方法所描述的操作。

处理器81通过读取并执行存储器82中存储的计算机程序指令，以实现上述实施例中的任意一种数据调度方法。

在一个示例中，计算机设备还可包括通信接口83和总线84。其中，如图8所示，处理器81、存储器82、通信接口83通过总线84连接并完成相互间的通信。

通信接口83，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线84包括硬件、软件或两者，将在电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线84可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

该计算机设备可以基于执行本申请实施例中的方法，从而实现结合图2至图7描述的数据调度方法和数据调度装置。

另外，结合上述实施例中的数据调度方法，本申请实施例可提供一种计算机存储介质来实现。该计算机存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种数据调度方法。

此外，结合上述实施例中的数据调度方法，本申请实施例提供一种计算机程序产品，包括计算机程序或指令，计算机程序或指令被处理器执行时实现上述实施例中的任意一种数据调度方法。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本申请的实施例的数据调度方法、装置、计算机设备和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (7)

1.一种数据调度方法，其特征在于，应用于办件调度系统，所述方法包括：

根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，所述办件事项转发请求由接件业务系统发送，所述转发请求包括办件事项数据；

基于所述路由信息，将所述办件事项数据转发至受理业务系统；

在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作；

所述基于熔断策略执行熔断操作，包括：

在接收受理业务系统返回的系统报错信息的情况下，统计所述办件事项数据重发失败的目标次数；

在目标次数大于熔断策略中配置次数的情况下，熔断器执行重发熔断操作；

根据熔断策略判断熔断器是否执行熔断操作，包括：

在目标次数小于熔断策略中配置次数的情况下，向所述受理业务系统发送重连请求；

基于受理业务系统针对所述重连请求的响应时间超过配置时间，更新所述目标次数；

所述根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，包括：

在所述办件事项数据包括事项编码，且所述路由信息包括受理业务系统的网际协议地址与端口的情况下，基于所述事项编码确定路由编号；

基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口；

在所述基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口之后，所述方法还包括：

在所述办件事项数据包括事项状态，且所述路由信息包括受理业务系统的业务接口的统一资源标识符的情况下，基于所述路由编号和所述事项状态，确定所述统一资源标识符；

在所述基于所述办件事项数据，从路由配置表中确定路由信息之前，所述方法还包括：

在所述办件调度系统的流控开关开启的情况下，确定所述转发请求符合所述办件调度系统的限流策略；

在所述根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息之前，所述方法还包括：

拦截转发请求；

检查流控开关是否开启；

在流控开关开启的情况下，检测该转发请求是否在免控列表；

在转发请求在免控列表的情况下，放行转发请求；

在转发请求不在免控列表的情况下，检测是否存在插件限流策略；

在存在插件限流策略的情况下，确定插件限流策略是否执行成功；

在插件限流策略执行成功的情况下，放行转发请求；

在插件限流策略执行不成功的情况下，放弃转发请求；

在不存在插件限流策略的情况下，放弃转发请求；

在流控开关不开启的情况下，放行转发请求。

2.根据权利要求1所述的方法，其特征在于，在所述接收从接件业务系统发送的转发请求之后，所述方法还包括：

基于所述办件事项数据与路由信息，生成数据调度日志。

3.根据权利要求2所述的方法，其特征在于，在所述基于所述办件事项数据与路由信息，生成数据调度日志之后，所述方法还包括：

接收办件事项查询请求；

从所述数据调度日志中获取与所述办件事项查询请求对应的查询信息。

4.一种数据调度装置，其特征在于，应用于办件调度系统，所述装置包括：

确定模块，用于根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息，所述办件事项转发请求由接件业务系统发送，所述转发请求包括办件事项数据；

转发模块，用于基于所述路由信息，将所述办件事项数据转发至受理业务系统；

熔断模块，用于在接收所述受理业务系统返回的系统报错请求的情况下，基于熔断策略执行熔断操作；

所述转发模块包括：

路由编号确定子模块，用于在所述办件事项数据包括事项编码，且所述路由信息包括受理业务系统的网际协议地址与端口的情况下，基于所述事项编码确定路由编号；

地址确定子模块，用于基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口；

所述转发模块还包括：

统一资源标识符确定子模块，用于在所述基于所述路由编号，在所述路由配置表中确定所述网际协议地址与所述端口之后，在所述办件事项数据包括事项状态，且所述路由信息包括受理业务系统的业务接口的统一资源标识符的情况下，基于所述路由编号和所述事项状态，确定所述统一资源标识；

所述熔断模块包括：

统计子模块，由于在接收受理业务系统返回的系统报错信息的情况下，统计办件事项数据重发失败的目标次数；

执行子模块，用于在目标次数大于熔断策略中配置次数的情况下，熔断器执行重发熔断操作；

所述熔断模块还包括：

发送子模块，用于在目标次数小于熔断策略中配置次数的情况下，向受理业务系统发送重连请求；

更新子模块，用于基于受理业务系统针对重连请求的响应时间超过配置时间，更新目标次数；

所述数据调度装置还包括：

限流模块，用于在所述基于所述办件事项数据，从路由配置表中确定路由信息之前，在所述办件调度系统的流控开关开启的情况下，确定所述转发请求符合所述办件调度系统的限流策略；

所述数据调度装置还用于：

在所述根据办件事项转发请求从路由配置表中确定受理业务系统的路由信息之前，拦截转发请求；

检查流控开关是否开启；

在流控开关开启的情况下，检测该转发请求是否在免控列表；

在转发请求在免控列表的情况下，放行转发请求；

在转发请求不在免控列表的情况下，检测是否存在插件限流策略；

在存在插件限流策略的情况下，确定插件限流策略是否执行成功；

在插件限流策略执行成功的情况下，放行转发请求；

在插件限流策略执行不成功的情况下，放弃转发请求；

在不存在插件限流策略的情况下，放弃转发请求；

在流控开关不开启的情况下，放行转发请求。

5.一种计算机设备，其特征在于，所述计算机设备包括处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-3任一项所述的数据调度方法。

6.一种计算机存储介质，其特征在于，所述计算机存储介质上存储有计算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-3任一项所述的数据调度方法。

7.一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时实现如权利要求1-3任一项所述的数据调度方法。