一种请求转发方法、装置、设备及存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种请求转发方法、装置、设备及存储介质。

背景技术

目前，现有的网关技术无法感知下游服务性能状态，因此容易出现导致部分机器负荷较重而部分机器资源得不到充分利用的情况发生；同时在现有网关限流场景下，只能提前对下游接口的流量进行预测以及压测配置限流策略，当在部分条件失效时，例如缓存服务器奔溃、全链路中下游链路奔溃时，会使得已配置的限流策略变得不准确，进而导致服务奔溃。

发明内容

有鉴于此，本发明的目的在于提供一种请求转发方法、装置、设备和存储介质，能够优化网关请求转发策略，充分利用下游服务器中各节点资源，并降低服务不可用的风险。其具体方案如下：

第一方面，本申请公开了一种请求转发方法，包括：

接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；

若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；

若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。

可选的，所述接收客户端发送的当前请求之前，还包括：

开启所述应用节点的服务监控系统；

获取所述应用节点的目标数据，基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌；其中，所述目标数据包含tomcat线程数、数据库连接数、dubbo线程数以及接口响应时间。

可选的，所述基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌之后，还包括：

若所述应用节点忙碌，则生成忙碌通知；

将所述忙碌通知从所述应用节点发送至网关，以便所述网关根据所述忙碌通知将所述应用节点的IP设置为忙碌状态。

可选的，所述若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略，包括：

若所述当前请求路径是所述紧急限流路径，则判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态；

若全部所述应用节点的IP都已设置为所述忙碌状态，则执行所述紧急限流策略；

若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，则执行所述基于预设请求转发规则将所述当前请求转发至对应的应用节点的步骤。

可选的，所述基于预设请求转发规则将所述当前请求转发至对应的应用节点，包括：

获取全部所述应用节点的IP的状态信息；

从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息不是所述忙碌状态的所述应用节点，以得到目标应用节点；

将所述当前请求转发至对应的所述目标应用节点。

可选的，所述获取全部所述应用节点的IP的状态信息之后，还包括：

从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息是所述忙碌状态的所述应用节点，以得到忙碌节点；

等待预设时间后，将所述忙碌节点的IP的所述状态信息更改未非忙碌状态。

可选的，所述接收客户端发送的当前请求之前，还包括：

引入网关依赖jar。

第二方面，本申请公开了一种请求转发装置，包括：

请求接收模块，用于接收客户端发送的当前请求；

路径判断模块，用于判断与所述当前请求对应的当前请求路径是否是紧急限流路径；

请求转发模块，用于若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；

策略执行模块，用于若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。

第三方面，本申请公开了一种电子设备，包括：

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

处理器，用于执行所述计算机程序，以实现如前述公开的请求转发方法的步骤。

第四方面，本申请公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现如前述公开的请求转发方法。

可见，本申请提供了一种请求转发方法，包括：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。由此可见，本申请通过判断客户端发送的当前请求对应的当前请求路径是否是紧急限流路径，若时则需要执行紧急限流策略，从而优化了网关请求转发策略，充分利用下游服务器中各节点资源，降低了服务不可用的风险。

附图说明

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

图1为本申请公开的一种请求转发方法流程图；

图2为本申请公开的一种具体的请求转发方法流程图；

图3为本申请公开的一种请求转发方法示意图；

图4为本申请公开的一种具体的请求转发方法流程图；

图5为本申请提供的请求转发装置结构示意图；

图6为本申请提供的一种电子设备结构图。

具体实施方式

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

目前，现有的网关技术无法感知下游服务性能状态，因此容易出现导致部分机器负荷较重而部分机器资源得不到充分利用的情况发生；同时在现有网关限流场景下，只能提前对下游接口的流量进行预测以及压测配置限流策略，当在部分条件失效时，例如缓存服务器奔溃、全链路中下游链路奔溃时，会使得已配置的限流策略变得不准确，进而导致服务奔溃。为此，本申请提供了一种请求转发方法，能够优化网关请求转发策略，充分利用下游服务器中各节点资源，并降低服务不可用的风险。

本发明实施例公开了一种请求转发方法，参见图1所示，该方法包括：

步骤S11：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径。

本实施例中，接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径。可以理解的是，在接收客户端发送的当前请求之前，引入网关依赖jar(计算机文件格式)。在接收到客户端发送的当前请求时，判断所述当前请求携带的当前请求路径是否是紧急限流路径，以便根据结果判断是否直接进行请求转发的操作。网关中配置由紧急限流路径及紧急限流策略，将网关接收到的当前请求路径与网关中配置的紧急限流路径比较，若相同则判定当前请求路径是紧急限流路径，同时网关判断应用是否开启紧急限流，若应用开启紧急限流，则匹配路径为紧急限流路径并执行紧急限流策略。

步骤S12：若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点。

本实施例中，判断与所述当前请求对应的当前请求路径是否是紧急限流路径之后，若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点。可以理解的是，若所述当前请求路径不是所述紧急限流路径，则判定当前下游的服务器资源仍有可用的空间，因此根据下游服务器资源节点的自身状态，确定接收所述当前请求的所述应用节点，即根据下游服务实际状态进行请求转发，保护了下游资负荷高的节点，充分利用了各节点资源。

步骤S13：若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。

本实施例中，判断与所述当前请求对应的当前请求路径是否是紧急限流路径之后，若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。可以理解的是，若所述当前请求路径是所述紧急限流路径，此时无法判断当前下游的服务器资源是否一定没有可用的空间，即存在下游服务器资源仍有可用的空间但所述当前请求路径是所述紧急限流路径的情况出现，因此需要进一步判断下游的服务器资源是否全被占用，若是则执行紧急限流策略。

本方案是网关系统性保护方案，属于软件系统稳定及安全性保护方面，通过优化网关请求转发策略，充分利用下游服务机器资源，并对突发情况提供动态限流策略，从而防止突增流量造成整个服务不可用。提供保底手段(设置紧急限流路径以及对应的紧急限流策略)，防止因为已有限流配置的误差导致系统奔溃，同时配置自由，限流开启/关闭、限流策略、节点忙碌检查都可以自由配置。

可见，本申请提供了一种请求转发方法，包括：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。由此可见，本申请通过判断客户端发送的当前请求对应的当前请求路径是否是紧急限流路径，若时则需要执行紧急限流策略，从而优化了网关请求转发策略，充分利用下游服务器中各节点资源，降低了服务不可用的风险。

参见图2所示，本发明实施例公开了一种请求转发方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。

步骤S21：开启所述应用节点的服务监控系统，获取所述应用节点的目标数据，并基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌。

本实施例中，开启所述应用节点的服务监控系统，获取所述应用节点的目标数据，并基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌。其中，所述目标数据包含tomcat线程数、数据库连接数、dubbo线程数以及接口响应时间。在开启所述应用节点的服务监控系统之前，配置开启系统稳定性监控以及不健康状态判断策略，同时开启紧急限流、配置紧急限流路径以及紧急限流策略。

如图3所示，应用节点中设置并开启服务监控系统，通过服务监控系统获取该节点的tomcat线程数、数据库连接数、dubbo线程数以及接口响应时间等信息，并根据上述目标数据以及预设忙碌策略判断所述应用节点是否忙碌。若所述应用节点忙碌，则通过服务通知模块生成该节点对应的忙碌通知，并将所述忙碌通知从所述应用节点发送至网关，以便所述网关根据所述忙碌通知将所述应用节点的IP设置为忙碌状态。在网关接收到客户端请求后，第一步首先判断客户端请求携带的当前路径是否为紧急限流路径，然后根据判断结果进入第二部转发策略的选择，以便确定接收当前请求的应用节点。

具体的，每个应用节点对应的应用系统均配置预设忙碌策略，然后根据所述预设忙碌策略判断所述应用节点是否忙碌，例如当tomcat线程数量达到90％时，则判定该应用节点忙碌。可以理解的是，每个应用系统都开启状态监控线程，并通过状态监控线程读取tomcat线程数、数据库连接数、dubbo线程数以及接口响应时间等数据，并通过结合上述数据以及预设忙碌策略判断该应用节点是否忙碌。

步骤S22：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径。

步骤S23：若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。

步骤S24：若所述当前请求路径不是所述紧急限流路径，则获取全部所述应用节点的IP的状态信息。

本实施例中，判断与所述当前请求对应的当前请求路径是否是紧急限流路径之后，若所述当前请求路径不是所述紧急限流路径，则获取全部所述应用节点的IP的状态信息。获取全部所述应用节点的IP的状态信息之后，从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息是所述忙碌状态的所述应用节点，以得到忙碌节点。可以理解的是，设置一个预设时间，以便忙碌节点处理自身的任务，因此在等待预设时间后，将所述忙碌节点的IP的所述状态信息更改为非忙碌状态，例如等待一分钟后将该节点由忙碌更改为不忙碌，当等待预设时间后节点为非忙碌状态时即可向其转发请求。

步骤S25：从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息不是所述忙碌状态的所述应用节点，以得到目标应用节点。

本实施例中，获取全部所述应用节点的IP的状态信息之后，从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息不是所述忙碌状态的所述应用节点，以得到目标应用节点。可以理解的是，在得到目标应用节点之后，可以根据当前请求的需求从目标应用节点中确定唯一一个要转发请求的接收请求应用节点，例如根据节点的当前负载情况确定所述接收请求应用节点，或者通过其他节点确定方式来决定所述接收请求应用节点。

步骤S26：将所述当前请求转发至对应的所述目标应用节点。

关于上述步骤S22、S23、S26的具体内容可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本申请实施例通过开启所述应用节点的服务监控系统，获取所述应用节点的目标数据，并基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌；接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略；若所述当前请求路径不是所述紧急限流路径，则获取全部所述应用节点的IP的状态信息；从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息不是所述忙碌状态的所述应用节点，以得到目标应用节点；将所述当前请求转发至对应的所述目标应用节点，优化了网关请求转发策略，充分利用下游服务器中各节点资源，降低了服务不可用的风险。

参见图4所示，本发明实施例公开了一种请求转发方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。

步骤S31：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径。

步骤S32：若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点。

步骤S33：若所述当前请求路径是所述紧急限流路径，则判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态。

本实施例中，判断与所述当前请求对应的当前请求路径是否是紧急限流路径之后，若所述当前请求路径是所述紧急限流路径，则判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态。可以理解的是，如上述图3所示，网关可以查询到管理的全部应用节点的当前状态信息，因此网关通过各个应用节点的当前状态信息判定每个应用节点对应的应用系统是监控应用还是不健康应用，若所述应用节点的状态信息为忙碌状态，则判定该应用节点为不健康应用；若所述应用节点的状态信息为非忙碌状态，则判定该应用节点为健康应用。应用节点开启服务监控，根据监控状态策略判断应用节点是否健康，若应用节点不健康则上报网关，即应用达不到健康标准，则将该应用节点的健康状态上报网关，以便网关监控并接收到不健康节点上报的通知，将其状态设置为不健康。

步骤S34：若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，则执行所述基于预设请求转发规则将所述当前请求转发至对应的应用节点的步骤。

本实施例中，判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态之后，若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，则执行所述基于预设请求转发规则将所述当前请求转发至对应的应用节点的步骤。可以理解的是，若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，即表面网关管理的应用节点中存在健康应用，此时从健康应用中选择唯一一个要转发请求的接收请求应用节点，并将当前请求转发至所述接收请求应用节点。网关进行请求转发时选择满足当前需求的应用节点，例如判断当前节点是否是不健康节点，如果是不健康节点则在一分钟内绕过该节点选择其它的健康节点进行请求转发操作。

步骤S35：若全部所述应用节点的IP都已设置为所述忙碌状态，则执行所述紧急限流策略。

本实施例中，判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态之后，若全部所述应用节点的IP都已设置为所述忙碌状态，则执行所述紧急限流策略。可以理解的是，若全部所述应用节点的IP都已设置为所述忙碌状态，则表面此时网关管理的全部应用节点都为不健康应用，无法接收当前请求，此时通过执行所述紧急限流策略来避免系统奔溃。

关于上述步骤S31、S32的具体内容可以参考前述实施例中公开的相应内容，在此不再进行赘述。

可见，本申请实施例通过接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；若所述当前请求路径是所述紧急限流路径，则判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态；若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，则执行所述基于预设请求转发规则将所述当前请求转发至对应的应用节点的步骤；若全部所述应用节点的IP都已设置为所述忙碌状态，则执行所述紧急限流策略，优化了网关请求转发策略，充分利用下游服务器中各节点资源，降低了服务不可用的风险。

参见图5所示，本申请实施例还相应公开了一种请求转发装置，包括：

请求接收模块11，用于接收客户端发送的当前请求；

路径判断模块12，用于判断与所述当前请求对应的当前请求路径是否是紧急限流路径；

请求转发模块13，用于若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；

策略执行模块14，用于若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。

可见，本申请包括：接收客户端发送的当前请求，并判断与所述当前请求对应的当前请求路径是否是紧急限流路径；若所述当前请求路径不是所述紧急限流路径，则基于预设请求转发规则将所述当前请求转发至对应的应用节点；若所述当前请求路径是所述紧急限流路径，则执行紧急限流策略。由此可见，本申请通过判断客户端发送的当前请求对应的当前请求路径是否是紧急限流路径，若时则需要执行紧急限流策略，从而优化了网关请求转发策略，充分利用下游服务器中各节点资源，降低了服务不可用的风险。

在一些具体实施例中，所述请求接收模块11，具体包括：

Jar引入单元，用于引入网关依赖jar；

监控系统开启单元，用于开启所述应用节点的服务监控系统；

目标数据获取单元，用于获取所述应用节点的目标数据；其中，所述目标数据包含tomcat线程数、数据库连接数、dubbo线程数以及接口响应时间；

忙碌判断单元，用于基于所述目标数据以及预设忙碌策略判断所述应用节点是否忙碌；

忙碌通知生成单元，用于若所述应用节点忙碌，则生成忙碌通知；

忙碌通知发送单元，用于将所述忙碌通知从所述应用节点发送至网关，以便所述网关根据所述忙碌通知将所述应用节点的IP设置为忙碌状态；

请求接收单元，用于接收客户端发送的当前请求。

在一些具体实施例中，所述路径判断模块12，具体包括：

当前请求路径判断单元，用于判断与所述当前请求对应的当前请求路径是否是紧急限流路径。

在一些具体实施例中，所述请求转发模块13，具体包括：

信息获取单元，用于若所述当前请求路径不是所述紧急限流路径，则获取全部所述应用节点的IP的状态信息；

忙碌节点确定单元，用于从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息是所述忙碌状态的所述应用节点，以得到忙碌节点；

忙碌节点状态更改单元，用于等待预设时间后，将所述忙碌节点的IP的所述状态信息更改未非忙碌状态；

目标应用节点确定单元，用于从全部的所述应用节点的IP的所述状态信息中筛选出所述状态信息不是所述忙碌状态的所述应用节点，以得到目标应用节点；

第一请求转发单元，用于将所述当前请求转发至对应的所述目标应用节点。

在一些具体实施例中，所述策略执行模块14，具体包括：

节点状态判断单元，用于若所述当前请求路径是所述紧急限流路径，则判断所述网关管理的全部所述应用节点的IP是否都已设置为所述忙碌状态；

紧急限流策略执行单元，用于若全部所述应用节点的IP都已设置为所述忙碌状态，则执行所述紧急限流策略；

第二请求转发单元，用于若所述网关中存在未设置为所述忙碌状态的所述应用节点的IP，则执行所述基于预设请求转发规则将所述当前请求转发至对应的应用节点的步骤。

进一步的，本申请实施例还提供了一种电子设备。图6是根据一示例性实施例示出的电子设备20结构图，图中的内容不能认为是对本申请的使用范围的任何限制。

图6为本申请实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的请求转发方法中的相关步骤。另外，本实施例中的电子设备20具体可以为电子计算机。

本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本申请技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。

另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222等，存储方式可以是短暂存储或者永久存储。

其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，其可以是Windows Server、Netware、Unix、Linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的请求转发方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。

进一步的，本申请实施例还公开了一种存储介质，所述存储介质中存储有计算机程序，所述计算机程序被处理器加载并执行时，实现前述任一实施例公开的请求转发方法步骤。

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

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

以上对本发明所提供的一种请求转发方法、装置、设备及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。