一种请求检测方法、系统、装置、电子设备及存储介质

技术领域

本申请涉及微服务技术领域，特别是涉及一种请求检测方法、系统、装置、电子设备及存储介质。

背景技术

随着微服务技术的发展，越来越多的业务依赖于微服务实现。例如，在风控领域，对于一个业务来说，可以基于多个检测规则对用于访问该业务的业务请求进行检测，一个检测规则可以对应至少一个微服务。例如，登录业务对应的检测规则可以包括：用于检测手机号的规则(可以称为第一检测规则)和用于检测IP地址的规则(可以称为第二检测规则)。相应的，当接收到针对登录业务的业务请求时，调用第一检测规则对应的微服务以检测登录的手机号，得到对应的检测结果，调用第二检测规则对应的微服务以检测登录的IP地址，得到对应的检测结果。进而，可以根据第一检测规则和第二检测规则对应的检测结果，得到该业务请求的检测结果，以根据该检测结果对该业务请求进行响应。

相关技术中，如果某一检测规则对应的微服务发生故障，则用于处理该业务请求的线程会持续性地调用该微服务，也就无法及时释放该线程，导致线程被无效占用，进而，可能会导致线程资源耗尽，甚至会造成业务系统的崩溃。

发明内容

本申请实施例的目的在于提供一种请求检测方法、系统、装置、电子设备及存储介质，以及时响应业务请求，避免用于处理业务请求的线程持续性地调用处于故障状态的微服务，避免线程被无效占用，进而，避免线程资源耗尽，也就可以避免业务系统崩溃。具体技术方案如下：

在本申请实施的第一方面，首先提供了一种请求检测方法，所述方法包括：

接收针对目标业务的业务请求；

针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，所述目标业务对应的每一检测规则用于检测所述业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；

若是，则获取该检测规则对应的预设检测结果；

若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果。

可选的，所述方法还包括：

当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数；

针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态；

所述针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务，包括：

针对所述目标业务对应的每一检测规则，判断当前已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务；

若存在，则确定该检测规则对应的微服务中当前存在处于故障状态的微服务；

若不存在，则确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

可选的，在所述针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，所述方法还包括：

针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态；其中，所述第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

可选的，所述当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数，包括：

当达到预设时刻时，通过所述目标业务所属的业务系统对应的消息队列获取预设历史时间段内的微服务响应日志；其中，所述微服务响应日志包含响应超时的微服务的响应超时记录；

按照所述响应超时记录，统计所述预设历史时间段内响应超时的微服务各自的响应超时次数。

可选的，所述方法还包括：

当达到预设时刻时，显示所述预设历史时间段内响应超时的微服务各自的响应超时次数。

可选的，所述方法还包括：

当达到预设时刻时，若所述预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

可选的，在所述基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果之后，所述方法还包括：

基于预设的检测结果集和响应操作集的对应关系，确定所述业务请求的检测结果对应的响应操作；其中，所述检测结果集包括所述业务请求对应的多个检测结果；所述响应操作集包括多个用于响应所述业务请求的响应操作；

按照确定出的响应操作响应所述业务请求。

在本申请实施的第二方面，还提供了一种请求检测系统，所述请求检测系统包括：业务节点；

所述业务节点，用于接收针对目标业务的业务请求；

针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，所述目标业务对应的每一检测规则用于检测所述业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；

若是，则获取该检测规则对应的预设检测结果；

若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果。

可选的，所述请求检测系统还包括：降级节点；

所述降级节点，用于当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数；针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态；

所述业务节点，具体用于针对所述目标业务对应的每一检测规则，判断当前所述降级节点已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务；

若存在，则确定该检测规则对应的微服务中当前存在处于故障状态的微服务；

若不存在，则确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

可选的，所述降级节点，还用于在所述针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态；其中，所述第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

可选的，所述业务节点，还用于在所述目标业务所属的业务系统对应的第一消息队列中添加微服务响应日志；其中，所述微服务响应日志包含响应超时的微服务的响应超时记录；

所述降级节点，具体用于当达到预设时刻时，从所述第一消息队列中获取预设历史时间段内的微服务响应日志；并按照所获取的微服务响应日志中的响应超时记录，统计所述预设历史时间段内响应超时的微服务各自的响应超时次数。

可选的，所述系统还包括：显示节点；

所述降级节点，还用于当达到预设时刻时，在所述目标业务所属的业务系统对应的第二消息队列中添加所述预设历史时间段内响应超时的微服务各自的响应超时次数；

所述显示节点，用于从所述第二消息队列中获取响应超时的微服务各自的响应超时次数，并进行显示。

可选的，所述降级节点，还用于当达到预设时刻时，若所述预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

可选的，所述业务节点，还用于在所述基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果之后，基于预设的检测结果集和响应操作集的对应关系，确定所述业务请求的检测结果对应的响应操作；其中，所述检测结果集包括所述业务请求对应的多个检测结果；所述响应操作集包括多个用于响应所述业务请求的响应操作；

按照确定出的响应操作响应所述业务请求。

在本申请实施的第三方面，还提供了一种请求检测装置，所述装置包括：

业务请求接收模块，用于接收针对目标业务的业务请求；

故障状态判断模块，用于针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，所述目标业务对应的每一检测规则用于检测所述业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；若是，则触发预设检测结果获取模块；若否，则触发微服务调用模块；

所述预设检测结果获取模块，用于获取该检测规则对应的预设检测结果；

所述微服务调用模块，用于调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

检测结果确定模块，用于基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果。

可选的，所述装置还包括：

响应超时次数获取模块，用于当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数；

故障状态确定模块，用于针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态；

所述故障状态判断模块，具体用于针对所述目标业务对应的每一检测规则，判断当前已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务；若存在，则触发第一确定模块；若不存在，则触发第二确定模块；

所述第一确定模块，用于确定该检测规则对应的微服务中当前存在处于故障状态的微服务；

所述第二确定模块，用于确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

可选的，所述装置还包括：

非故障状态确定模块，用于在所述针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态；其中，所述第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

可选的，所述响应超时次数获取模块，具体用于当达到预设时刻时，通过所述目标业务所属的业务系统对应的消息队列获取预设历史时间段内的微服务响应日志；其中，所述微服务响应日志包含响应超时的微服务的响应超时记录；按照所述响应超时记录，统计所述预设历史时间段内响应超时的微服务各自的响应超时次数。

可选的，所述装置还包括：

显示模块，用于当达到预设时刻时，显示所述预设历史时间段内响应超时的微服务各自的响应超时次数。

可选的，所述装置还包括：

告警模块，用于当达到预设时刻时，若所述预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

可选的，所述装置还包括：

响应操作确定模块，用于在所述基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果之后，基于预设的检测结果集和响应操作集的对应关系，确定所述业务请求的检测结果对应的响应操作；其中，所述检测结果集包括所述业务请求对应的多个检测结果；所述响应操作集包括多个用于响应所述业务请求的响应操作；

业务请求响应模块，用于按照确定出的响应操作响应所述业务请求。

在本申请实施的第四方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现上述任一所述的请求检测方法。

在本申请实施的又一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的请求检测方法。

在本申请实施的又一方面，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的请求检测方法。

本申请实施例提供的一种请求检测方法、系统、装置、电子设备及存储介质，接收针对目标业务的业务请求；针对目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，目标业务对应的每一检测规则用于检测业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；若是，则获取该检测规则对应的预设检测结果；若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果。

基于上述处理，针对目标业务对应的每一检测规则，当该检测规则对应的微服务中存在处于故障状态的微服务时，可以获取该检测规则的预设检测结果，也就能够在对应的微服务处于故障状态时，及时得到检测规则的检测结果，进而，能够根据检测结果响应业务请求，即，可以及时响应业务请求，也就能够及时释放处理该业务请求的线程，避免线程被无效占用，进而，避免线程资源耗尽，也就可以避免业务系统崩溃。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的一种请求检测方法的第一种流程图；

图2为本申请实施例提供的一种请求检测方法的第二种流程图；

图3为本申请实施例提供的一种请求处理的系统协作泳道图；

图4为本申请实施例提供的一种请求检测方法的第三种流程图；

图5为本申请实施例提供的一种熔断降级系统的结构示意图；

图6为本申请实施例提供的一种请求检测装置的结构示意图；

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

具体实施方式

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

随着微服务技术的发展，越来越多的业务依赖于微服务实现。在风控领域，针对一个业务，可以基于多个检测规则对用于访问该业务的业务请求进行检测，一个检测规则可以对应至少一个微服务。

例如，登录业务对应的检测规则可以包括：用于检测手机号的规则(可以称为第一检测规则)和用于检测IP地址的规则(可以称为第二检测规则)。相应的，当接收到针对登录业务的业务请求时，调用第一检测规则对应的微服务以检测登录的手机号，得到对应的检测结果，调用第二检测规则对应的微服务以检测登录的IP地址，得到对应的检测结果。进而，可以根据第一检测规则和第二检测规则对应的检测结果，得到该业务请求的检测结果，以根据该检测结果对该业务请求进行响应。

相关技术中，如果某一检测规则对应的微服务发生故障，用于处理该业务请求的线程会持续性地调用该微服务，也就无法及时释放该线程，导致线程被无效占用，进而，可能会导致线程资源耗尽，甚至会造成业务系统的崩溃。

为了保证对业务请求的正常响应，进而保证业务系统的正常运行，本申请实施例提供了一种请求检测方法，可以应用于电子设备。例如，该电子设备可以为服务器，该服务器能够与客户端网络互通，相应的，该服务器可以接收客户端发送的业务请求，并响应。

参见图1，图1为本申请实施例提供的一种请求检测方法的第一种流程图，该方法可以包括以下步骤：

步骤S101：接收针对目标业务的业务请求。

步骤S102：针对目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务。若是，则执行步骤S103；若否，则执行步骤S104。

其中，目标业务对应的每一检测规则用于检测业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式。

步骤S103：获取该检测规则对应的预设检测结果。

步骤S104：调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果。

步骤S105：基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果。

本申请实施例提供的一种请求检测方法，针对目标业务对应的每一检测规则，当该检测规则对应的微服务中存在处于故障状态的微服务时，可以获取该检测规则的预设检测结果，也就能够在对应的微服务处于故障状态时，及时得到检测规则的检测结果，进而，能够根据检测结果响应业务请求，即，可以及时响应业务请求，也就能够及时释放处理该业务请求的线程，避免线程被无效占用，进而，避免线程资源耗尽，也就可以避免业务系统崩溃。

针对步骤S101，目标业务可以为客户端当前请求的业务，也就是电子设备能够提供的任意一种业务。例如，本申请中的电子设备能够提供多种不同的业务。如，针对网上银行的场景，电子设备可以提供包括用户登录、转账和查询余额等业务；如，针对社交平台的场景，电子设备可以提供包括用户登录和添加好友等业务。

当用户在客户端请求目标业务时，客户端可以生成用于访问目标业务的业务请求，并向电子设备发送。进而，电子设备可以对该业务请求进行处理。

针对步骤S102，电子设备在接收到针对目标业务的业务请求时，可以基于目标业务对应的检测规则对接收到的目标业务的业务请求进行检测，得到该业务请求的检测结果。目标业务对应的检测规则可以有多个，该多个检测规则用于检测目标业务的业务请求中携带的不同信息，即，从不同的维度对目标业务的业务请求进行检测。即，针对目标业务对应的每一检测规则，可以调用该检测规则对应的微服务，以根据对应的微服务返回的调用结果，确定该检测规则的检测结果。

针对目标业务对应的任一检测规则，若该检测规则对应的任一微服务存在故障时，则可以确定该微服务处于故障状态。针对故障的微服务，相关技术中无法及时有效地获取其调用结果，因此，针对对应的微服务中存在处于故障状态的微服务的检测规则，也就无法及时有效地通过调用对应的微服务，得到该检测规则的检测结果。进而，针对这类检测规则，本申请的实施例中则可以按照步骤S103，获取这类检测规则的检测结果。

针对任一微服务，若在调用该微服务后超过预设时长未接收到其返回的调用结果，则可以确定该微服务响应超时。预设时长可以是5毫秒，或者，也可以是10毫秒。例如，针对任一微服务，可以基于历史时间段内，该微服务发生响应超时的次数确定该微服务是否存在故障。

在一种实现方式中，请求检测方法还可以包括：

步骤1：当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数。

步骤2：针对预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态。

针对目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务，包括：

步骤3：针对目标业务对应的每一检测规则，判断当前已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务。若是，则执行步骤4；若否，则执行步骤5。

步骤4：确定该检测规则对应的微服务中当前存在处于故障状态的微服务。

步骤5：确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

其中，预设时刻可以为周期性的时刻。

在本申请实施例中，当达到预设时刻时，电子设备可以获取预设历史时间段内响应超时的微服务各自的响应超时次数。例如，电子设备可以每五分钟获取预设历史时间段内响应超时的微服务各自的响应超时次数，或者，也可以每六分钟获取预设历史时间段内响应超时的微服务各自的响应超时次数。预设历史时间段可以是预设时刻之前的历史时间段，预设历史时间段的时长可以为1分钟，或者，也可以为2分钟。

针对预设历史时间段内每一响应超时的微服务，若该微服务在预设历史时间段内的响应超时次数大于预设阈值，则可以认为该微服务存在故障，进而电子设备可以确定该微服务处于故障状态。预设历史时间段内该微服务的响应超时次数能够体现预设历史时间段内该微服务响应超时的频率。

例如，预设阈值可以是固定值，此处不做限定。或者，预设阈值可以基于电子设备当前的业务负载确定。例如，预设阈值可以与电子设备当前的业务负载呈正相关。可以设置预设阈值为电子设备当前的业务负载的10％，或者，也可以为电子设备当前的业务负载的15％。

可以理解的是，在实际的业务场景中，针对一些正常的微服务，由于网络状态等影响，其可能也会发生响应超时，然而其响应超时的次数较小。若电子设备当前的业务负载较大，针对某一正常的微服务，其在一定时间内响应超时的次数也会较大。因此，设置较大的预设阈值，也就能够避免将该类正常的微服务确定为故障的微服务。基于上述处理，能够适应业务负载的变化，提高确定出的处于故障状态的微服务的准确性，保证业务请求的检测结果的高可用。

一种方式中，电子设备可以基于异步的方式，分别确定处于故障状态的微服务，以及对接收到的业务请求进行处理。例如，电子设备可以通过不同的线程分别确定处于故障状态的微服务，以及对接收到的业务请求进行处理。如，电子设备可以通过一个线程(可以称为线程1)确定处于故障状态的微服务，即，通过一个线程执行上述步骤1和步骤2。另外，还可以通过另一个线程(可以称为线程2)，基于线程1确定出的处于故障状态的微服务，对接收到的业务请求进行处理，即，通过另一个线程执行上述步骤S101到步骤S105。

基于上述方式，由于确定处于故障状态的微服务与对接收到的业务请求进行处理为异步进行的，因此，能够提高确定出的故障状态的微服务的及时性，且不会影响对业务请求进行处理的过程，进一步保证业务请求的检测结果的可用性。

针对步骤S103，针对目标业务对应的每一检测规则，若该检测规则对应的微服务中当前存在处于故障状态的微服务，即，该检测规则当前处于降级状态，可以获取该检测规则对应的预设检测结果。

在一个实施例中，一个检测规则对应的预设检测结果表示：业务请求为预设的各风险等级中除第一风险等级和第二风险等级以外的其他风险等级。第一风险等级表示各风险等级中最高的风险等级，第二风险等级表示各风险等级中最低的风险等级。也就是说，一个检测规则对应的预设检测结果表示业务请求为中间风险等级。

例如，在风控领域，预设检测结果可以是表示中间风险等级的风险评估值。也就是说，针对一个检测规则，若表示该检测规则的风险评估值属于预设风险评估值范围，则预设检测结果可以为该预设风险评估值范围中除两端的值以外的一个值(也可以称为中间值)。例如，预设检测结果可以为该预设风险评估值范围的二等分点对应的风险评估值，或者，也可以为该预设风险评估值范围的三等分点对应的风险评估值。

如，预设的各风险等级包含：第一风险等级、第二风险等级和第三风险等级。第一风险等级表示高风险，第二风险等级表示低风险，第三风险等级表示中间风险，相应的，预设检测结果表示第三风险等级对应的风险评估值。

或者，预设的各风险等级包含：第一风险等级、第二风险等级、第三风险等级、第四风险等级和第五风险等级。第一风险等级表示高风险，第二风险等级表示低风险，第三风险等级表示中间风险，第四风险等级表示次高风险，第五风险等级表示次低风险。相应的，预设检测结果可以表示第三风险等级对应的风险评估值，或者，预设检测结果也可以表示第四风险等级对应的风险评估值，或者，预设检测结果也可以表示第五风险等级对应的风险评估值。

相关技术中，针对故障的微服务，可以获取预设的调用结果，例如，预设的调用结果为空(Null)，进而，确定调用结果与业务请求中的信息不匹配，进而，确定检测规则的检测结果为上述预设风险评估值范围端点的值，即，得到的检测规则的检测结果表示业务请求为最高的风险等级，或者，得到的检测规则的检测结果表示业务请求为最低的风险等级。而业务请求中的信息与该微服务在正常情况下的调用结果可能是相匹配的。也就是说，基于相关技术中的处理，在该微服务故障的情况下，确定出的检测规则的检测结果与实际的真实结果是完全相反的，进而，导致最终计算出的业务请求的检测结果的准确度较低。

而在本申请实施例中，针对处于降级状态的检测规则，可以返回一个表示中间风险等级的风险评估值，可以避免确定出的检测规则的检测结果与实际的真实结果是完全相反的，能够在一定程度上降低该检测结果的检测结果的不准确对整个业务请求的检测结果的影响，提高业务请求的检测结果的可用性。

针对步骤S104，微服务返回的调用结果用于对业务请求进行检测，即，对业务请求中携带的信息进行检测。可以理解的是，不同的微服务返回不同的调用结果。针对每一微服务，可以按照对应的检测规则中记录检测的方式，基于该微服务返回的调用结果，对业务请求中携带的需要进行检测的信息进行检测，以确定该信息是否正常，进而，可以根据该信息是否正常得到对应的检测规则的检测结果。

例如，在风控领域，当用户在客户端请求登录业务时，客户端生成登录业务的业务请求并向电子设备发送该业务请求。该业务请求中可以携带有登录手机号、登录设备的硬件信息以及登录地点等信息。登录业务对应的检测规则可以包括：检测登录手机号的规则、检测登录设备的硬件信息的规则以及检测登录地点的规则。

进而，在电子设备接收到针对登录业务的业务请求时，可以调用检测登录手机号的微服务对业务请求中的手机号进行检测，例如，检测业务请求中的手机号的前三位是否为正常数值。相应的，该微服务的调用结果包含正常手机号的前三位。

还可以调用检测登录设备的硬件信息的微服务对业务请求中硬件信息进行检测，例如，检测业务请求中的硬件信息是否为常用的硬件信息。相应的，该微服务的调用结果包含常用的硬件信息。

以及可以调用检测登录地点的微服务对业务请求中的登录地点进行检测，例如，检测业务请求中的登录地点是否为常用的登录地点。相应的，该微服务的调用结果包含常用的登录地点。

针对每一检测规则，可以按照该检测规则对应的检测方式，基于该检测规则对应的微服务的调用结果，确定检测的信息是否正常，进而，可以确定该检测规则的检测结果。检测结果可以用风险评估值表示。例如，风险评估值越高，表示检测对象的风险等级越高。

例如，检测登录手机号的规则的检测结果可以是业务请求中的手机号的风险评估值。当业务请求中的手机号的前三位与调用结果匹配时，确定业务请求中的手机号为正常手机号，此时风险评估值可以为上述预设风险评估值范围中的最小值。当业务请求中的手机号与调用结果不匹配时，确定业务请求中的手机号不属于正常手机号，此时风险评估值可以为上述预设风险评估值范围中的最大值。

当目标业务对应的每一检测规则均不处于降级状态时，即，当每一检测规则调用的微服务均不存在故障时，针对目标业务对应的每一检测规则，调用该检测规则对应的微服务。此时，检测规则对应的微服务均能够及时响应，因此，可以及时返回对应的微服务的调用结果，进而，基于对应的微服务返回的调用结果可以确定该检测规则对应的真实检测结果。

针对步骤S105，针对目标业务对应的每一检测规则，均可以得到该检测规则对应的真实检测结果，当该检测规则处于降级状态时，该检测规则对应的真实检测结果即为预设检测结果；当该检测结果未处于降级状态时，该检测规则对应的真实检测结果是基于对应的微服务返回的调用结果确定的。进而，可以基于目标业务对应的每一检测规则对应的检测结果，确定目标业务的业务请求的检测结果。

基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果的方式，可以与相关技术中基于各检测规则的真实检测结果得到业务请求的检测结果的方式相同。

一种实现方式中，各检测规则的检测结果可以用风险评估值表示，进而，可以通过计算各检测规则的检测结果的加权和，得到业务请求的风险评估值，即，业务请求的检测结果。

例如，计算业务请求对应的所有检测规则的检测结果的加权和，得到业务请求的检测结果。

又例如，还可以计算除处于降级状态的检测规则之外的其他检测规则的真实检测结果的加权和。即，处于降级状态的检测规则的预设检测结果并不参与计算。例如，可以在计算加权和时，设置处于降级状态的检测规则的预设检测结果的权重为0，并相应调整其他检测规则的真实检测结果的权重。基于此，也就能够在一定程度上降低处于降级状态的检测规则的检测结果的不准确对整个业务请求的检测结果的影响，提高业务请求的检测结果的可用性。

在一个实施例中，在针对预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，请求检测方法还可以包括：

步骤1：针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态。

其中，第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

在本申请实施例中，电子设备在每次确定出处于故障状态的微服务时，还可以确定处于故障状态的微服务的预设过期时长，也就是说，在确定故障状态的微服务时，在之后的预设过期时长内，处于故障状态的微服务为故障状态。当超过预设过期时长时，处于故障状态的微服务可以重新恢复正常状态，即，不再处于故障状态。预设过期时长小于设置预设时刻的周期时长。

例如，在每次确定出处于故障状态的微服务时，电子设备可以记录确定出的每一处于故障状态的微服务，以及该微服务处于故障状态的开始时刻。后续，针对记录的每一处于故障状态的微服务，在记录该微服务处于故障状态的开始时刻之后，当达到预设过期时长对应的时刻时，可以将该微服务从记录的处于故障状态的微服务中删除，也就可以确定该微服务处于非故障状态。

例如，预设过期时长可以是3分钟，也可以是4分钟。

基于上述处理，为处于降级状态的检测规则设置过期时长，实现检测规则自动恢复正常状态，无需人工控制，能够适应网络环境的动态变化，提高检测结果的准确性，进一步保证业务请求的正常响应。

在一个实施例中，当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数，包括：

步骤1：达到预设时刻时，通过目标业务所属的业务系统对应的消息队列获取预设历史时间段内的微服务响应日志。

其中，微服务响应日志包含响应超时的微服务的响应超时记录。

步骤2：按照响应超时记录，统计预设历史时间段内响应超时的微服务各自的响应超时次数。

其中，响应超时记录中记录有响应超时的微服务，以及该微服务发生响应超时的时刻。

在本申请实施例中，针对每一业务系统，可以设置对应的消息队列，相应的，每一业务系统可以通过对应的消息队列向电子设备发送该业务系统的微服务响应日志。基于此，使得电子设备能够对接不同的业务系统，对不同的业务系统的业务请求进行检测，以实现业务请求检测的动态扩展。

电子设备可以基于微服务响应日志确定微服务的响应超时次数。例如，电子设备可以通过Flink大数据引擎对微服务响应日志中的响应超时记录进行分析。即，电子设备可以通过聚合函数，对微服务响应日志中的响应超时记录进行分析，得到预设历史时间段内微服务的响应超时次数。例如，电子设备可以设置时间窗口，并通过聚合函数得到该时间窗口内微服务的响应超时次数。该时间窗口的时长与预设历史时间段的时长相同。

通过Flink大数据引擎对微服务响应日志中的响应超时记录进行分析，即，可以对微服务响应日志中的响应超时记录进行近实时的分析，也就能够实现对确定出的处于故障状态的微服务的近实时监控。由于微服务响应日志是业务请求处理过程中生成的，因此，电子设备直接对微服务响应日志进行分析，也就能够及时确定出微服务的响应超时次数，进而及时确定出处于故障状态的微服务，进一步保证业务请求的检测结果的可用性。

在一个实施例中，请求检测方法还可以包括：

步骤一：当达到预设时刻时，显示预设历史时间段内响应超时的微服务各自的响应超时次数。

在本申请实施例中，可以通过显示预设历史时间段内响应超时的微服务各自的响应超时次数。例如，可以通过监控大盘，以图表的形式，显示响应超时的微服务发生响应超时的时间和次数的关系。例如，可以以折线图的形式，显示响应超时的微服务发生响应超时的时间和次数的关系。其中，折线图的横坐标可以为时间，纵坐标可以为响应超时的次数。监控大盘可以是RAP(Realtime Analytics Platform，实时分析平台)数据大盘。通过显示微服务的响应超时次数，可以展示微服务响应超时的趋势，使得运维人员基于显示的信息可以直观地了解到微服务响应超时的趋势，也就能够基于微服务发生响应超时的趋势对微服务进行维护和调整，进一步保证业务系统的稳定性。

在一个实施例中，请求检测方法还可以包括：

步骤二：当达到预设时刻时，若预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

例如，可以以短信或者邮件的方式发送告警消息。告警消息中可以包含响应超时次数大于预设阈值的微服务，以及该微服务的响应超时次数。使得运维人员在接收到告警消息时，可以对告警消息中包含的微服务进行问题检查和维护，进一步保证业务系统的稳定性。

在一个实施例中，参见图2，图2为本申请实施例提供的一种请求检测方法的第二种流程图。在基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果(S105)之后，请求检测方法还可以包括：

步骤S106：基于预设的检测结果集和响应操作集的对应关系，确定业务请求的检测结果对应的响应操作。

其中，检测结果集包括业务请求对应的多个检测结果；响应操作集包括多个用于响应业务请求的响应操作。

步骤S107：按照确定出的响应操作响应业务请求。

在本申请实施例中，可以预先设置各检测结果与各响应操作的对应关系，即，检测结果集和响应操作集的对应关系。在得到业务请求的检测结果之后，电子设备可以在对应关系中进行查询，确定得到的检测结果对应的响应操作，进而，可以按照查询到的响应操作响应业务请求。例如，针对登录业务的检测结果表示业务请求的风险较低，对应的响应操作为允许登录。针对登录业务的检测结果表示业务请求的风险较高，对应的响应操作为拒绝登录。

基于各检测结果和各响应操作的对应关系，可以确定检测结果对应的响应操作，进而可以基于确定的响应操作响应业务请求，也就能够及时响应业务请求，保证业务系统的正常运行。

本申请实施例还提供了一种请求检测系统，请求检测系统包括：业务节点。业务节点可以为服务器，用于接收客户端发送的业务请求，并可以得到业务请求对应的检测结果。另外，还可以基于业务请求对应的检测结果，对业务请求进行响应。

业务节点，用于接收针对目标业务的业务请求；

针对目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，目标业务对应的每一检测规则用于检测业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；

若是，则获取该检测规则对应的预设检测结果；

若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果。

本申请实施例提供的一种请求检测系统，针对目标业务对应的每一检测规则，当该检测规则对应的微服务中存在处于故障状态的微服务时，可以获取该检测规则的预设检测结果，也就能够在对应的微服务处于故障状态时，及时得到检测规则的检测结果，进而，能够根据检测结果响应业务请求，即，可以及时响应业务请求，也就能够及时释放处理该业务请求的线程，避免线程被无效占用，进而，避免线程资源耗尽，也就可以避免业务系统崩溃。

在一个实施例中，请求检测系统还包括：降级节点。降级节点可以为服务器，用于获取预设历史时间段内响应超时的微服务各自的响应超时次数，并可以确定处于故障状态的微服务。

降级节点，用于当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数；针对预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态；

业务节点，具体用于针对目标业务对应的每一检测规则，判断当前降级节点已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务；

若存在，则确定该检测规则对应的微服务中当前存在处于故障状态的微服务；

若不存在，则确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

在本申请实施例中，降级节点可以确定处于故障状态的微服务，并通知业务节点确定出的处于故障状态的微服务。

或者，降级节点也可以将处于故障状态的微服务记录在数据库中。进而，业务节点可以基于数据库中记录的处于故障状态的微服务，确定目标业务对应的检测规则对应的微服务中当前是否存在处于故障状态的微服务。

基于上述处理，可以通过一个节点(即降级节点)确定处于故障状态的微服务，通过另一个节点(即业务节点)对业务请求进行处理，也就可以通过异步的方式，分别确定处于故障状态的微服务，以及对接收到的业务请求进行处理。业务节点在对接收到的业务请求进行处理时，无需确定出处于故障状态的微服务，降低业务节点的任务量，避免业务节点的任务量过大影响业务节点的性能，进一步保证业务节点可以及时响应业务请求。

在一个实施例中，降级节点，还用于在针对预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态；其中，第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

在一个实施例中，业务节点，还用于在目标业务所属的业务系统对应的第一消息队列中添加微服务响应日志。

其中，微服务响应日志包含响应超时的微服务的响应超时记录。

降级节点，具体用于当达到预设时刻时，从第一消息队列中获取预设历史时间段内的微服务响应日志；并按照所获取的微服务响应日志中的响应超时记录，统计预设历史时间段内响应超时的微服务各自的响应超时次数。

在本申请实施例中，针对每一业务系统，可以设置对应的第一消息队列，相应的，业务节点可以在对应的消息队列中添加该业务系统的微服务响应日志。基于此，降级节点可以获取不同的业务系统的微服务响应日志。降级节点可以基于目标业务所属的业务系统对应的第一消息队列获取微服务响应日志，进而，可以对从第一消息队列中获取到的微服务响应日志进行分析，得到预设历史时间段内响应超时的微服务各自的响应超时次数。降级节点分析微服务响应日志得到微服务各自的响应超时次数的方式，可以参考上述方法实施例中分析微服务响应日志得到微服务各自的响应超时次数的相关介绍。

例如，第一消息队列可以是kafka消息队列，降级节点和业务节点之间可以通过kafka消息队列传输微服务响应日志，也就能够提高微服务响应日志的传输效率。

在一个实施例中，请求检测系统还包括：显示节点。显示节点，可以为具有显示功能的服务器，用于获取响应超时的微服务各自的响应超时次数，并进行显示。

降级节点，还用于当达到预设时刻时，在目标业务所属的业务系统对应的第二消息队列中添加预设历史时间段内响应超时的微服务各自的响应超时次数；

显示节点，用于从第二消息队列中获取响应超时的微服务各自的响应超时次数，并进行显示。

在本申请实施例中，降级节点可以在达到预设时刻时，在目标业务所属的业务系统对应的第二消息队列中添加预设历史时间段内响应超时的微服务各自的响应超时次数。不同的业务系统可以共用一个第二消息队列，或者，针对每一业务系统，可以设置对应的第二消息队列。基于此，显示节点可以获取不同的业务系统的响应超时的微服务各自的响应超时次数并显示。

第二消息队列也可以是kafka消息队列。降级节点和显示节点之间可以通过kafka消息队列传输响应超时的微服务各自的响应超时次数，也就能够提高响应超时的微服务各自的响应超时次数的传输效率。

显示节点显示响应超时次数的方式，可以参考上述方法实施例中步骤一的相关介绍。

在一个实施例中，降级节点，还用于当达到预设时刻时，若预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

降级节点发送告警消息的方式，可以参考上述方法实施例中步骤二的相关介绍。

在一个实施例中，业务节点，还用于在基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到业务请求的检测结果之后，基于预设的检测结果集和响应操作集的对应关系，确定业务请求的检测结果对应的响应操作；其中，检测结果集包括业务请求对应的多个检测结果；响应操作集包括多个用于响应业务请求的响应操作；按照确定出的响应操作响应业务请求。

在一个实施例中，参见图3，图3为本申请实施例提供的一种请求处理的系统协作泳道图。

业务系统(即上述实施例中的业务节点)可以向消息队列(即上述实施例中的第一消息队列)中推送熔断降级日志(即上述实施例中的微服务响应日志)，消息队列中的Fuse.log即为熔断降级日志。

进而，熔断降级系统(即上述实施例中的降级节点)可以从消息队列中提取熔断降级日志，并解析日志得到熔断降级的检测规则。即，获取微服务响应日志中的响应超时记录。进而，通过定义时间窗口聚合检测规则熔断降级的频率，即，可以设置时间窗口，并通过聚合函数得到该时间窗口内微服务的响应超时次数。检测规则熔断降级也就是检测规则对应的微服务响应超时。

进而，熔断降级系统可以向RAP数据大盘(即上述实施例中的显示节点)发送检测规则发生熔断降级的频率，RAP数据大盘可以显示熔断降级趋势图，该熔断降级趋势图包含检测规则发生熔断降级的频率。即，可以展示微服务响应超时的趋势。

另外，熔断降级系统可以监听配置中心中设置的检测规则降级阈值(即上述实施例中的预设阈值)，进而，可以判断检测规则发生熔断降级的频率是否超过该阈值。其中，配置中心可以为数据库。

针对熔断降级的频率超过检测规则降级阈值的检测规则，熔断降级系统可以确定其处于降级状态并为其设置过期时间(即上述实施例中的预设过期时长)，这类检测规则可以称之为降级检测规则。即，针对预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则熔断降级系统可以确定该微服务在预设过期时长内处于故障状态，即，该微服务对应的检测规则在预设过期时长内处于降级状态。

进而，熔断降级系统推送降级检测规则至配置中心并附带过期时间，即，熔断降级系统可以向配置中心推送确定出的降级检测规则以及该降级检测规则处于降级状态的过期时间。配置中心可以生成降级检测规则列表及自定义检测规则决策结果，即，配置中心可以生成降级检测规则列表，并将降级检测规则记录在降级检测规则列表中，并记录预先设置的自定义检测规则决策结果(即上述实施例中的预设检测结果)。

业务系统监听配置中心配置，拉取降级检测规则列表，即，业务系统可以监听配置中心配置的自定义检测规则决策结果，拉取降级检测规则列表，获取降级的检测规则。即，熔断降级系统可以通知业务系统确定出的处于降级状态的检测规则。进而，针对降级的检测规则，业务系统可以获取对应的自定义检测规则决策结果。

运维人员可以在配置中心对检测规则降级阈值以及检测规则决策结果进行自定义配置，即，在配置中心中记录预先设置的预设阈值以及预设检测结果。如此，可以提升配置的动态扩展性，进而，基于预设检测结果，可以及时响应业务请求，同时实现业务请求的检测结果的高可用。另外，可以通过配置中心的动态配置，扩展熔断降级系统能够消费的消息队列，这些消息队列可以对接不同的业务系统，进而，使得熔断降级系统可以消费不同业务系统的熔断降级日志，也就可以对更多依赖第三方服务(即上述实施例中的微服务)的业务系统提供预设检测结果。也就可以保证及时响应多个业务系统的业务请求，保证多个业务系统的业务请求的检测结果的高可用。

在一个实施例中，参见图4，图4为本申请实施例提供的一种请求检测方法的第三种流程图。其中，业务系统可以为上述实施例中的业务节点，熔断降级系统可以为上述实施例中的降级节点。需要说明的是，图4中的步骤编号并不代表实际的步骤顺序，不做具体限定。另外，图4中的相关步骤可以参考图3中的说明。

在业务系统在向熔断降级系统推送熔断降级日志(即上述实施例中的微服务响应日志)之前，执行步骤S401：客户端请求业务系统，即，客户端向业务系统发送针对目标业务的业务请求。业务系统接收到目标业务的业务请求后，执行步骤S402，调用第三方服务，即，业务系统调用目标业务对应的检测规则对应的微服务。如步骤S403所示，第三方服务调用超时，返回默认值。调用超时的第三方服务返回的默认值可以为空。进而，如步骤S404所示，业务系统获取默认检测规则决策结果，并基于默认检测规则决策结果对客户端发送的业务请求进行响应。即，业务系统基于返回的默认值，确定检测规则的检测结果(即默认检测规则决策结果)。进而，可以根据检测规则的检测结果，得到针对目标业务的业务请求的检测结果，以根据该业务请求的检测结果对客户端发送的该业务请求进行响应。

其中，业务系统对接收到的业务请求进行处理，与熔断降级系统确定处于降级状态的检测规则可以是异步进行的。

配置中心中记录有检测规则降级阈值，并通过步骤S405，向熔断降级系统推送检测规则降级阈值。如步骤S406所示，业务系统可以向消息队列推送业务系统熔断降级日志。

进而，熔断降级系统可以基于步骤S407从消息队列的推送消息中获取熔断降级日志，并分析熔断降级日志，进而，如步骤S408所示，检测规则熔断超过阈值，进而，可以降级该检测规则，即，可以确定检测规则熔断是否超过阈值，也就可以确定出处于降级状态的检测规则。即，基于微服务响应日志，将预设历史时间段内响应超时次数大于预设阈值的微服务，确定为在预设过期时长内处于故障状态，即，处于故障状态的微服务对应的检测规则处于降级状态。

针对业务请求对应的任一检测规则，当该检测规则熔断超过阈值时，如步骤S409所示，降级该检测规则并附带过期时间与自定义降级策略，进而，熔断降级系统可以向配置中心推送降级的检测规则并附带过期时长与自定义降级策略。其中，自定义降级策略即检测规则对应的预设检测结果。

如步骤S410所示，当客户端请求业务系统时，业务系统在接收到目标业务的业务请求后，可以执行步骤S411，拉取配置中心降级检测规则列表，即，从配置中心获取降级检测规则列表。降级检测规则列表中记录有降级的检测规则、过期时长与自定义降级策略。

如步骤S412所示，业务系统可以获取配置中心返回的降级检测规则列表。进而，可以基于降级检测规则列表，判断业务请求对应的检测规则是否处于降级状态。如步骤S413和步骤S414所示，针对业务请求对应的任一检测规则，若降级检测规则列表中包含该检测规则，且该检测规则降级策略未过期，即，该检测规则的自定义降级策略为过期，当前未达到该检测规则对应的过期时长，则执行步骤S415。业务系统获取自定义检测规则决策结果，并基于自定义检测规则决策结果对客户端发送的业务请求进行响应。即，业务系统可以基于自定义降级策略得到处于降级状态的检测规则的预设检测结果，即自定义检测规则决策结果，进而，也就可以基于自定义检测规则决策结果，得到目标业务的业务请求的检测结果，也就可以根据目标业务的业务请求的检测结果对该业务请求进行响应。

即，业务系统可以针对目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务。若是，则获取该检测规则的预设检测结果。若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果确定该检测规则的检测结果。基于各检测规则的检测结果，可以得到业务请求的检测结果。进而，可以确定出与业务请求的检测结果对应的响应操作，以响应客户端的业务请求。

在一个实施例中，参见图5，图5为本申请实施例提供的一种熔断降级系统的结构示意图。熔断降级系统包括：配置监控层、计算层、组件层、数据资源层。

其中，配置监控层用于进行降级配置和降级监控。降级配置包括熔断降级阈值(即上述实施例中的预设阈值)设置以及检测规则降级决策(即上述实施例中的预设检测结果)配置。熔断降级监控的功能包括：显示熔断降级趋势图以及超过熔断降级阈值时报警。显示熔断降级趋势图的方式可以参考上述实施例中步骤一中的相关介绍，可以通过监控大盘(即上述实施例中的RAP数据大盘)，以图表的形式，显示响应超时的微服务发生响应超时的时间和次数的关系。在超过熔断降级阈值时进行报警的方式可以参考上述实施例中步骤二中发送告警消息的相关介绍。

计算层中的Flink Job(Flink工作)可以监听配置中心参数的变化，配置中心中记录的参数包括熔断降级阈值以及检测规则降级决策。通过Flink Job还可以统计检测规则熔断降级频率，即可以统计响应超时的微服务各自的响应超时次数。进而，熔断降级系统可以基于熔断降级阈值，确定出处于故障状态的微服务，即，处于故障状态的微服务对应的检测规则处于降级状态。另外，还可以通过Flink Job发送降级的检测规则，即，在消息队列中添加处于降级状态的检测规则，以通知业务系统处于降级状态的检测规则。

微服务响应日志的响应超时记录中记录有响应超时的微服务的集合(即熔断降级第三方服务集合)，以及响应超时的微服务对应的检测规则的集合(即熔断降级检测规则集合)。计算层中还包括HTTP(HyperText Transfer Protocol，超文本传输协议)接口，可以通过该接口获取上述两个集合。进而，可以基于MySQL数据库中记录的微服务和检测规则的对应关系，确定处于降级状态的检测规则，也就是确定降级的检测规则。

组件层包括配置中心、监控大盘、消息队列以及Flink大数据引擎。运维人员可以在配置中心设置预设阈值以及预设检测结果。监控大盘用于显示熔断降级趋势图。消息队列可以传输检测规则熔断降级频率以及降级的检测规则，包括上述实施例中的第一消息队列和第二消息队列。Flink大数据引擎可以近实时地对微服务响应日志中的响应超时记录进行处理分析，得到响应超时的微服务各自的响应超时次数。

数据资源层可以包括MySQL数据库、kafka消息队列以及数据资源服务平台。MySQL数据库用于记录微服务和检测规则的对应关系。kafka消息队列对应上述实施例中的第一消息队列和第二消息队列。数据资源服务平台可以提供显示界面，进而，运维人员可以通过数据资源服务平台查看kafka消息队列以及MySQL数据库中的数据。

本申请实施例还提供了一种请求检测装置，参见图6，图6为本申请实施例提供的一种请求检测装置的结构示意图，请求检测装置包括：

业务请求接收模块601，用于接收针对目标业务的业务请求；

故障状态判断模块602，用于针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，所述目标业务对应的每一检测规则用于检测所述业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；若是，则触发预设检测结果获取模块603；若否，则触发微服务调用模块604；

预设检测结果获取模块603，用于获取该检测规则对应的预设检测结果；

微服务调用模块604，用于调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

检测结果确定模块605，用于基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果。

基于上述处理，针对目标业务对应的每一检测规则，当该检测规则对应的微服务中存在处于故障状态的微服务时，可以获取该检测规则的预设检测结果，也就能够在对应的微服务处于故障状态时，及时得到检测规则的检测结果，进而，能够根据检测结果响应业务请求，即，可以及时响应业务请求，也就能够及时释放处理该业务请求的线程，避免线程被无效占用，进而，避免线程资源耗尽，也就可以避免业务系统崩溃。

在一个实施例中，请求检测装置还包括：

响应超时次数获取模块，用于当达到预设时刻时，获取预设历史时间段内响应超时的微服务各自的响应超时次数；

故障状态确定模块，用于针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态；

所述故障状态判断模块，具体用于针对所述目标业务对应的每一检测规则，判断当前已确定出的处于故障状态的微服务中是否存在该检测规则对应的微服务；若存在，则触发第一确定模块；若不存在，则触发第二确定模块；

所述第一确定模块，用于确定该检测规则对应的微服务中当前存在处于故障状态的微服务；

所述第二确定模块，用于确定该检测规则对应的微服务中当前不存在处于故障状态的微服务。

在一个实施例中，请求检测装置还包括：

非故障状态确定模块，用于在所述针对所述预设历史时间段内每一响应超时的微服务，若该微服务的响应超时次数大于预设阈值，则确定该微服务从当前时刻开始处于故障状态之后，针对确定出的每一处于故障状态的微服务，当达到第一时刻时，确定该微服务处于非故障状态；其中，所述第一时刻为确定出该微服务处于故障状态的时刻向后延伸预设过期时长对应的时刻。

在一个实施例中，响应超时次数获取模块，具体用于当达到预设时刻时，通过所述目标业务所属的业务系统对应的消息队列获取预设历史时间段内的微服务响应日志；其中，微服务响应日志包含响应超时的微服务的响应超时记录；按照响应超时记录，统计预设历史时间段内响应超时的微服务各自的响应超时次数。

在一个实施例中，请求检测装置还包括：

显示模块，用于当达到预设时刻时，显示预设历史时间段内响应超时的微服务各自的响应超时次数。

在一个实施例中，请求检测装置还包括：

告警模块，用于当达到预设时刻时，若预设历史时间段内存在响应超时次数大于预设阈值的微服务，则发送告警消息。

在一个实施例中，请求检测装置还包括：

响应操作确定模块，用于在所述基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果之后，基于预设的检测结果集和响应操作集的对应关系，确定所述业务请求的检测结果对应的响应操作；其中，所述检测结果集包括所述业务请求对应的多个检测结果；所述响应操作集包括多个用于响应所述业务请求的响应操作；

业务请求响应模块，用于按照确定出的响应操作响应业务请求。

本申请实施例还提供了一种电子设备，如图7所示，包括处理器701、通信接口702、存储器703和通信总线704，其中，处理器701，通信接口702，存储器703通过通信总线704完成相互间的通信，

存储器703，用于存放计算机程序；

处理器701，用于执行存储器703上所存放的程序时，实现如下步骤：

接收针对目标业务的业务请求；

针对所述目标业务对应的每一检测规则，判断该检测规则对应的微服务中当前是否存在处于故障状态的微服务；其中，所述目标业务对应的每一检测规则用于检测所述业务请求中携带的信息；一个检测规则包含所要检测的信息以及检测的方式；

若是，则获取该检测规则对应的预设检测结果；

若否，则调用该检测规则对应的微服务，并根据对应的微服务返回的调用结果，确定该检测规则对应的真实检测结果；

基于对应的微服务中存在处于故障状态的微服务的检测规则的预设检测结果，以及其他检测规则的真实检测结果，得到所述业务请求的检测结果。

上述终端提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，简称PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，简称EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述终端与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，简称RAM)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital Signal Processor，简称DSP)、专用集成电路(Application SpecificIntegrated Circuit，简称ASIC)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本申请提供的又一实施例中，还提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述实施例中任一所述的请求检测方法。

在本申请提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的请求检测方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

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

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

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。