CN115801679A - 一种通用业务限流方法、装置、设备及介质 - Google Patents

Abstract

本发明涉及计算机技术领域，尤其涉及一种通用业务限流方法、装置、设备及介质。所述方法包括：由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；由所述第一服务器根据所述处理决策处理接收到的调用请求。本发明的方案保证互联网业务系统不会因为过多的异常请求调用导致服务器资源耗尽或者影响系统稳定性。

Description

一种通用业务限流方法、装置、设备及介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种通用业务限流方法、装置、设备及介质。

背景技术

互联网服务提供商发布的服务运行在公网云服务器，服务的访问者可能是普通用户，可能是合作的第三方系统，也有可能是恶意破坏者。无论访问者是谁，在一定时间内大规模的API访问，会导致服务器资源占用增加，严重者会导致系统宕机。各个业务系统除了做必要身份认证等安全机制外，也会对API的调用频次做相应的限制。

为了保护API服务的调用安全，目前已有多种方法来保护API调用的安全，例如：对请求参数做摘要计算、身份认证等机制，但以上机制主要保证业务安全性，例如订单金额不会被修改，转账不会被转错账户等。虽然请求限流在目前互联网厂商的很多场景中均有应用，例如短信验证码发送避免短信轰炸、登录页面验证密码次数避免密码爆破等。限流的实现原理都是保证在一定时间内，API调用次数不会超过一定阈值。但是不同业务限流需要各自开发，存在重复开发问题，且各个业务系统数据无法做到有效融合，无法为运维和风控提供有效依据。

发明内容

有鉴于此，有必要针对以上技术问题，提供一种通用业务限流方法、装置、设备及介质。

根据本发明的第一方面，提供了一种通用业务限流方法，所述方法包括：

由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

由所述第一服务器根据所述处理决策处理接收到的调用请求。

在一些实施例中，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

在一些实施例中，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

在一些实施例中，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

在一些实施例中，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

在一些实施例中，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

在一些实施例中，所述根据所述判断结果生成处理决策并返回给所述第一服务器的步骤包括：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

根据本发明的第二方面，提供了一种通用业务限流装置，所述装置包括：

同步模块，配置用于由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

分析模块，配置用于由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

判断模块，配置用于由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

处理模块，配置用于由所述第一服务器根据所述处理决策处理接收到的调用请求。

根据本发明的第三方面，还提供了一种计算机设备，该计算机设备包括：

至少一个处理器；以及

存储器，存储器存储有可在处理器上运行的计算机程序，处理器执行程序时执行前述的通用业务限流方法。

根据本发明的第四方面，还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时执行前述的通用业务限流方法。

上述一种通用业务限流方法，不对请求业务数据做限制，而是将业务限流和业务系统分离开，使用独立与业务的第二服务器对业务系统所在的第一服务器的调用记录进行监管，能够保证业务系统API的调用频次在正常范围内、保证互联网业务系统不会因为过多的异常请求调用导致服务器资源耗尽或者影响系统稳定性，并据此及时反馈给风控系统，提供运维支持。

此外，本发明还提供了一种通用业务限流装置、一种计算机设备和一种计算机可读存储介质，同样能实现上述技术效果，这里不再赘述。

附图说明

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

图1为本发明一个实施例提供的一种通用业务限流方法的流程图；

图2为本发明另一个实施例提供的应用于用户注册和短信发送场景下的通用业务限流方法的流程图；

图3为本发明另一个实施例提供的一种通用业务限流装置的结构示意图；

图4为本发明另一个实施例中计算机设备的内部结构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明实施例进一步详细说明。

需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。

在一个实施例中，请参照图1所示，本发明提供了一种通用业务限流方法100，具体来说，所述方法包括以下步骤：

步骤101，由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

步骤102，由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

步骤103，由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

步骤104，由所述第一服务器根据所述处理决策处理接收到的调用请求。

上述一种通用业务限流方法，不对请求业务数据做限制，而是将业务限流和业务系统分离开，使用独立与业务的第二服务器对业务系统所在的第一服务器的调用记录进行监管，能够保证业务系统API的调用频次在正常范围内、保证互联网业务系统不会因为过多的异常请求调用导致服务器资源耗尽或者影响系统稳定性，并据此及时反馈给风控系统，提供运维支持。

在一些实施例中，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

在一些实施例中，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

在一些实施例中，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

在一些实施例中，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

在一些实施例中，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

在一些实施例中，步骤103中的所述根据所述判断结果生成处理决策并返回给所述第一服务器，包括：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

在又一个实施中，请参照图2所示，为了便于理解本发明的方案下面以某个客户端可执行用户注册和短信发送的业务系统为例，本实施例提供了应用于该场景的一种通用业务限流方法，具体来说包括客户端和服务端两部分，其中，服务端统一收集和汇总调用记录，并根据相关的请求特征对请求进行存储和反向索引，方便后续的查询；客户端则是以SDK(Software development kit，软件开发工具包)形式方便与各个业务系统做集成，将调用记录通过内置协议同步至服务端模块，服务端判断当前请求调用是否到达了最大阈值，下面详细说明客户端和服务端工作的具体过程：

第一步，服务端接收来自客户端推送的调用记录数据，并识别请求特征，例如：

(1)请求发送的用户代理UserAgent，如浏览器版本、操作系统版本信息等；

(2)请求发送的IP地址；

(3)请求发送代表的用户身份，如回话Cookie、令牌Token等；

(4)请求业务，如密码认证、短信发送、下单等；

(5)请求执行的结果，如成功或者失败；

(6)请求时间。

第二步，服务端识别到请求特征后，请求数据收集器需要对相关特征信息做持久化保存，此类信息存储应该具备以下特点：

特点1：通过请求特征建立反向索引关联到源请求，方便以此特征找到对应的请求记录；

特点2：支持动态数据存储和解析，应对动态的请求特征维护和新的请求特征扩展；

特点3：支持对老旧数据的过期清理，防止数据不断增长导致的存储空间耗尽。

步骤三，服务端对这些特征设置阈值，任一指标超过了阈值则触发限流规则，客户端调用时应返回提示。阈值以业务+特征+时间+次数的维度进行限制，并实现基于时间的阶梯式的调用限流，例如，以发送短信和用户注册这两个业务为例，我们分别赋予两个业务编码为SMS_SEND(发送短信)、USER_REG(用户注册)。某个时间段内有多个来自相同IP(请求特征)的短信发送和用户注册的业务请求，分别记录对应的请求时间。调用限流可以分别设置为以下策略：

策略1：30分钟内，只能调用,3次；

策略2，1小时内，只能调用4次；

策略3：3小时内，只能调用8次；

策略4：24小时内，只能调用48次；

按照时间阶梯分别加以限制，任一策略到达阈值则触发限流，服务端应该返回给客户端对应的响应。

步骤四，需要做调用记录限流的各个业务系统集成客户端，并通过拦截器或者AOP切面等方式选择合适的时机通过客户端SDK同步调用记录给服务端，并在同步请求完成后，接收来自服务端的响应提示，如果返回为触发限流，则本次请求报错；否则本次请求正常进行。同步时机可以有以下几种类型：

类型1：调用前，此项会在关键业务被调用前将本次调用记录同步至服务端；

类型2：调用后，此项会在关键业务被调用后将本次调用记录同步至服务端；

类型3：调用前和调研后，此项会在关键业务被调用前和调研后都将本次调用记录同步至服务端。

一种通用业务限流方法具备以下有益技术效果：不对请求业务数据做限制，目的在于保证业务系统API的调用频次在正常范围内，保证互联网业务系统不会因为过多的异常请求调用导致服务器资源耗尽或者影响系统稳定性，并据此及时反馈给风控系统，提供运维支持。

在一些实施例中，请参照图3所示，本发明还提供了一种通用业务限流装置200，所述装置包括：

同步模块201，配置用于由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

分析模块202，配置用于由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

判断模块203，配置用于由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

处理模块204，配置用于由所述第一服务器根据所述处理决策处理接收到的调用请求。

上述一种通用业务限流装置，不对请求业务数据做限制，而是将业务限流和业务系统分离开，使用独立与业务的第二服务器对业务系统所在的第一服务器的调用记录进行监管，能够保证业务系统API的调用频次在正常范围内、保证互联网业务系统不会因为过多的异常请求调用导致服务器资源耗尽或者影响系统稳定性，并据此及时反馈给风控系统，提供运维支持。

在一些实施例中，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

在一些实施例，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

在一些实施例中，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

在一些实施例中，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

在一些实施例中，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

在一些实施例中，所述判断模块203进一步配置用于：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

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

根据本发明的另一方面，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图请参照图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时实现以上所述的通用业务限流方法，具体来说，所述方法包括以下步骤：

由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

由所述第一服务器根据所述处理决策处理接收到的调用请求。

在一些实施例中，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

在一些实施例中，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

在一些实施例中，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

在一些实施例中，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

在一些实施例中，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

在一些实施例中，所述根据所述判断结果生成处理决策并返回给所述第一服务器的步骤包括：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

根据本发明的又一方面，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以上所述的通用业务限流方法，具体来说，包括执行以下步骤：

由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

由所述第一服务器根据所述处理决策处理接收到的调用请求。

在一些实施例中，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

在一些实施例中，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

在一些实施例中，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

在一些实施例中，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

在一些实施例中，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

在一些实施例中，所述根据所述判断结果生成处理决策并返回给所述第一服务器的步骤包括：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

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

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

Claims (10)

1.一种通用业务限流方法，其特征在于，所述方法包括：

由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

由所述第一服务器根据所述处理决策处理接收到的调用请求。

2.根据权利要求1所述的通用业务限流方法，其特征在于，所述预设时机为业务系统被调用前、业务系统被调用后、业务系统被调用前加在业务系统被调用后的任意一种。

3.根据权利要求2所述的通用业务限流方法，其特征在于，所述请求特征包括：请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中的至少一种。

4.根据权利要求3所述的通用业务限流方法，其特征在于，对所述请求特征进行存储，包括：

存储分析得到的请求特征，并建立调用请求与对应请求特征的索引关系。

5.根据权利要求4所述的通用业务限流方法，其特征在于，所述业务阈值根据请求发送的用户代理、请求发送的IP地址、请求发送代表的用户身份、业务名称、请求执行结果以及请求时间中至少一种进行设置。

6.根据权利要求5所述的通用业务限流方法，其特征在于，所述业务阈值包括多个，所述判断结果包括任意业务阈值被触发或所有业务阈值均未被触发。

7.根据权利要求6所述的通用业务限流方法，其特征在于，所述根据所述判断结果生成处理决策并返回给所述第一服务器的步骤包括：

响应于所述判断结果为任意业务阈值被触，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回拒绝处理；

响应于所述判断结果为多个业务阈值均未被触发，则所述第二服务器根据所述调用请求与对应请求特征的索引关系向所述第一服务器对应的调用请求返回允许处理。

8.一种通用业务限流装置，其特征在于，所述装置包括：

同步模块，配置用于由运行业务系统的第一服务器对接收的调用请求进行记录以形成调用记录，并按照预设时机将所述调用记录同步到第二服务器；

分析模块，配置用于由所述第二服务器对所述调用记录进行分析以得到请求特征，并对所述请求特征进行存储；

判断模块，配置用于由所述第二服务器判断所述请求特征是否达到业务阈值以得到判断结果，以及根据所述判断结果生成处理决策并返回给所述第一服务器，其中，所述处理决策包括拒绝处理和允许处理；

处理模块，配置用于由所述第一服务器根据所述处理决策处理接收到的调用请求。

9.一种计算机设备，其特征在于，包括：

至少一个处理器；以及

存储器，所述存储器存储有可在所述处理器中运行的计算机程序，所述处理器执行所述程序时执行权利要求1-7任意一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时执行权利要求1-7任意一项所述的方法。

Images