具体实施方式
在现有技术中,通常设备会配置至少一个接口,用于接收外部(如,用户终端、第三方设备)的业务请求。而维护设备的工作人员通常在预见未来一段时间内设备的负载会超过该设备处理业务能力的上限时(如,促销季、节假日时用户访问可能有大幅度增加),可以根据设备处理业务能力的上限,为该设备的各接口分别设置不完全相同的流量限制(如,限制各接口单位时间内可接收的业务请求的数量),以避免由于设备的负载过高导致的负面影响。并在设备的负载恢复正常之后,再解除为各接口设置的流量限制。
需要说明的是在本说明书中,流量是指在单位时间内,接收的业务请求的数量。
例如,假设设备A配置有接口a以及接口b,并分别用于接收不同的业务请求。该设备A处理业务能力的上限为每分钟处理10个业务请求。进一步假设,由工作人员为接口a以及接口b设置的流量限制均为:每分钟接收5个务请求。则在一分钟内无论向该设备A发送多少业务请求,通过该接口a以及接口b,该设备A在一分钟内最多只接收10个业务请求并进行处理。
进一步地,由于单台设备处理业务的能力有限,而业务的增长通常远高于设备性能的增长,所以为了应对快速增加的业务量,通常会以多台设备组成的系统(如,分布式服务器),接收业务请求并进行业务处理。
并且,由于不同的业务所需要调用的数据、需要进行的计算、业务流程等等可能不完全相同,所以为了方便业务管理以及更有效的利用设备资源,通常可采用以不同的接口接收不同类型业务的业务请求。于是,服务器中通常存在多个接口。并且,各接口用于接收不完全相同业务的业务请求。
但是,由于对于不同业务的业务请求的处理耗时不完全相同,单位时间内接收的不同业务的业务请求的数量也可能不完全相同,并且上述处理耗时以及单位时间内的业务请求的数量都是动态变化的,所以通过对接口进行流量限制的方法难以适应实际情况,有可能导致设备资源的浪费、过多业务请求被拒绝等问题。
例如,登录请求与支付请求的耗时可能不同,前者可从数据库中调用数据进行身份验证,耗时通常较短,而后者通常涉及与第三方服务器之间的数据传输,所以耗时通常较长。并且单位时间内接收的支付请求的数量可能出现大幅度井喷的情况(如,促销期内用户购买的商品增加),而相对的登录请求的数量通常不会出现大幅度的变化。
进一步假设,服务器通过接口a接收支付请求,通过接口b接收登录请求,该服务器每分钟处理业务请求的上限为15个,由工作人员配置的流量限制为:接口a每分钟10个,接口b每分钟5个。当出现交易高峰时,服务器每分钟接收到15个支付请求以及2个登录请求。则每分钟接口a可能拒绝接收5个支付请求,但是服务器每分钟仅处理了12个业务请求,并没有达到每分钟处理15个业务请求的处理能力的上限,造成了资源浪费。
于是,本说明书各实施例提供一种流量控制方法,解决现有技术在进行流量控制时,难以动态的对各接口进行流量控制,导致设备资源浪费的问题。
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于说明书中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为说明书实施例提供的一种流量控制过程,具体可包括以下步骤:
S102:监测负载。
在本说明书一个或多个实施例中,监测的负载可以是服务提供方的服务器的负载。该服务器可通过预设的接口接收业务请求,并执行对应的业务,为用户提供相应的服务。并且,具体可由服务器中安装的用于进行流量控制的程序或者硬件,监测该服务器的负载以及执行后续步骤的操作,本说明书对此不做限定。
具体的,正如前述的,服务器中可配置有多个接口用于接收不同业务的业务请求。于是在本说明书一个或多个实施例中,可根据需要配置各接口的优先级。其中,各接口的优先级可以与各接口接收的业务请求对应的业务的重要程度对应。
不同业务的重要程度可以不完全一致,可以以数值的方式体现接口的优先级。如,以0至10表示优先级从低到高,为各接口配置不同的数值用以表示各接口的优先级。当然,具体如何配置各接口的优先级本说明书不做限定,在本说明书一个或多个实施例中可以根据需要进行配置。如表1所示。
接口标识 |
优先级 |
a |
1 |
b |
5 |
c |
10 |
d |
8 |
表1
表1为本说明书实施例提供的多个接口的优先级的示意,该优先级以0至10表示,数值越大优先级越高。
另外,在本说明书一个或多个实施例中,该服务器可以单独的一台设备,或者由多台设备组成的系统。在监测服务器的负载时,可以对服务器或者系统中的每个中央处理器(Central Processing Unit,CPU)的CPU使用率以及CPU负载进行监测,以确定服务器或者系统的负载。
其中,由于CPU使用率以及CPU负载与实际业务处理情况相关,也就是说服务器的负载是不断变化的,所以为了准确确定服务器的负载,可以根据预设周期,监测该服务器中各CPU的CPU使用率以及CPU负载。其中,该预设周期可以根据需要进行设置,例如,1秒、5秒或者1分钟,本说明书实施例对此不做限定。
CPU使用率可表示CPU的运算能力的使用情况,随CPU当前处理的业务的复杂程度而变化。而CPU负载为单位时间内CPU正在处理以及等待该CPU处理的业务的数量,随CPU处理业务的速度以及接收到业务的数量等原因而变化。并且,CPU负载与CPU使用率之间并不存在直接的对应关系,通常来说,CPU使用率较高时CPU负载也会较高,但是也存在CPU使用率较低但是CPU负载较高等情况。
例如,以身份验证业务为例,若需要对接收的账户标识以及登录密码的对应关系进行验证,则CPU使用率可能较低,而若需要对接收的生物特征进行识别,则CPU使用率可能较高。但是无论是进行何种身份验证,CPU负载可能较高,如,在单位时间内接收到大量的身份验证业务。
当然,需要说明的是,由于CPU负载通常为数量值(如,CPU最大每分钟处理5个任务),并在CPU制造时便已经确定,所以CPU负载对应的第二阈值既可以是数值,也可是百分比。例如,CPU负载对应的第二阈值为每分钟5个任务或者90%,该90%表示该CPU每分钟处理任务数量为该CPU最大每分钟处理任务数量的90%。
进一步地,由于服务器中可以存在多个CPU,并且不同的CPU可用于处理不同的业务或者同一个业务流程中的不同步骤,所以在该服务器中的各CPU的CPU使用率以及CPU负载可能不完全相同。于是在本说明书实施例中,还可以对各CPU的CPU使用率以及CPU负载的分别进行平均值的计算,确定该服务器的CPU平均使用率以及CPU平均负载。则在后续步骤中,可根据CPU平均使用率以及CPU平均负载,判断服务器的负载是否过高,是否需要进行流量限制。
更进一步地,在本说明书实施例中,在监测服务器的负载时,还可以监测CPU的温度、CPU的频率、CPU的电压以及服务器的功耗等等,并将其作为服务器的负载进行后续的判断步骤。其中,CPU的温度越高负载越高、CPU的频率越高负载越高、CPU的电压越高负载越高、服务器的功耗越高负载越高。本说明书实施例并不限定通过何种方式监测服务器的负载,以及监测那种数值作为衡量服务器负载的数值,可根据需要进行设置。为方便描述,后续仅以CPU的使用率以及CPU的负载为例进行说明。
S104:判断所述负载是否高于预设阈值,若是,则执行步骤S106,若否则执行步骤S108。
在本说明书一个或多个实施例中,在确定服务器的负载之后,便可判断该服务器的负载是否高于预设阈值,若是,则执行步骤S106选择至少一个接口减少通过该接口接收的业务请求的数量,即进行流量限制,避免服务器的负载继续升高及其带来的负面影响,若否,则执行步骤S108。
具体的,该预设阈值可以视为是为判断服务器负载是否过高的条件,并且可根据需要进行设置。例如,若需要服务器在较高负荷运行,则该阈值可以设置的较高,如90%,若需要服务器在较稳定的状态运行,则该阈值可设置的相对较低,如,80%。
另外,由于CPU使用率以及CPU负载表示不同的运行状况,所以在本说明书一个或多个实施例中,可设置分别对应CPU使用率的第一阈值以及对应CPU负载的第二阈值。于是在判断服务器的负载是否超过预设阈值时,可根据预设的CPU使用率对应的第一阈值以及CPU负载对应的第二阈值,判断步骤S102中监测得到的服务器的CPU使用率以及CPU负载中的任意一个,是否高于其所对应的阈值。
即,当判断CPU使用率不高于第一阈值以及CPU负载不高于第二阈值时,执行步骤S108,若CPU使用率高于第一阈值,或者CPU负载高于第二阈值时,则执行步骤S106。
S106:根据预先配置的各接口的优先级,选择至少一个接口,减少通过选择的接口接收的业务请求的数量。
在本说明书一个或多个实施例中,在确定服务器负载高于预设阈值时,可根据预先配置的各接口的优先级,选择至少一个接口进行流量限制,以降低服务器的负载,避免由于负载过高导致的负面影响。在本说明书一个或多个实施例中,通过选择的接口接收的业务请求的数量,为选择的接口当前在单位时间内可接收的业务请求的最大数量。
具体的,正如前述的,通常服务器中的不同接口用于接收不同业务的业务请求,而不同业务有不完全相同的重要程度,所以预先配置的各接口的优先级可与业务的重要程度存在对应关系。
于是,在本说明书实施例中,可为各接口预先配置优先级,在确定服务器的负载高于预设阈值,需要进行流量限制时,可以根据预先配置的接口的优先级,按照从低到高的顺序,先对优先级低的至少一个接口进行流量限制。一方面可以避免流量限制对优先级的接口的影响,进而避免重要程度高的业务受影响,另一方面通过限制流量,可以使服务器将更多处理业务的能力用于处理优先级高的接口接收的业务请求。也就是说,通过选择优先级低的接口进行流量限制,可以先从重要程度较低的业务开始进行流量限制,减少重要程度较高的业务受到的影响。
另外,在本说明书实施例中,还可以根据预先设置流量步长以及流量上限,进行流量限制。具体的,对于选择进行流量限制的接口,可先判断该接收的业务请求的数量是否高于预设的流量上限,若是,则将该接口接收的业务请求的数量减少至流量上限,若否,则按照预设的流量步长,减少通过该接口接收的业务请求的数量。也就是说,流量上限为,对各接口进行第一次流量限制时的流量。
例如,假设预先设置的流量步长为每分钟2个业务请求,流量上限为每分钟10个业务请求,则在第一次确定对接口a进行流量限制时,可将该接口a的流量限制为每分钟10个业务请求,而当后续再次对该接口a进行流量限制时,则以每分钟2个业务请求为步长逐次减少该接口a接收的业务请求的数量,如第二次减少接口a接收的业务请求的数量时,则将该接口a的流量限制为每分钟8个业务请求,第三次减少为每分钟6个业务请求,以此类推。
当然,流量上限以及流量步长可根据实际需要进行设置,并且对于不同的接口可以设置不完全相同的流量上限以及流量步长,本说明书实施例对此不做具体限定。
进一步地,在本说明书实施例中,在对接口进行流量限制时,针对每个接口若该接口流量限制为不接收任何业务请求时,在后续需要选择接口进行流量限制时,可以不再选择该接口。以避免选择已经没有流量的接口反复进行流量限制,也就是说在本说明书实施例中,可针对未被限制为不接收任何业务请求的接口进行选择,并进行流量限制。
具体的,在本说明书实施例中,还可针对服务器中的每个接口,配置该接口的流量下限。该流量下限为,对该接口进行限流时可限制的最低流量。于是,在本说明书实施例中,当判断负载高于预设阈值时,可根据预先为各接口配置的流量下限,先从各接口中确定流量不小于该流量下限的接口,之后再按照优先级从低到高的顺序,从确定出的各接口中选择至少一个接口。
另外,在本说明书实施例中,针对每个接口,当限制该接口的流量为该接口配置的流量下限时,后续不再对该接口进行流量限制。即,在本说明书实施例中,当判断负载高于预设阈值时,可先根据所述预先配置的各接口优先级,按照从高到低的顺序,选择至少一个接口。之后针对每个选择的接口,判断该选择的接口的流量是否不大于为该接口配置的流量下限,若是,则不再减少该选择的接口接收的业务请求的数量,并且当后续判断负载高于预设阈值时,也不再选择该接口,若否,则减少该选择的接口接收的业务请求的数量。
其中,针对每个接口,当确定该接口当前的流量不大于为该接口配置的流量下限时,则后续不再选择该接口进行流量限制。
具体的,为各接口配置的流量下限可如表2所示。
接口标识 |
优先级 |
流量下限 |
a |
1 |
1个/分钟 |
b |
2 |
0个/分钟 |
c |
5 |
4个/分钟 |
d |
10 |
1000个/分钟 |
表2
以表2所示的各接口为例,假设在减少流量的过程中,根据各接口的权重值,首先,可对接口a进行流量限制。假设在经过多次限流之后,接口a的流量被限制为1个/分钟时,则后续不再选择接口a,并减少接口a的流量。进而对接口b进行流量限制直至接口b的流量被限制为0个/分钟,再对接口c进行流量限制等等以此类推。
S108:在根据所述预先配置的各接口的优先级,选择至少一个接口,增加通过选择的接口接收的业务请求的数量。
在本说明书一个或多个实施例中,由于服务器的负载是不断变化的,而对负载的监测是按照周期进行的,所以在执行步骤S102时,可能没有被减少接收业务请求的数量的接口,也可能有被减少接收业务请求的数量的接口。于是,当确定服务器的负载不高于预设阈值时,还可以从各接口中,确定被减少接收业务请求的数量的接口。并按照确定出的各接口的优先级从高到低的顺序,从确定出的各接口中选择至少一个接口,增加通过选择的接口接收的业务请求的数量。
具体的,可判断在该服务器中是否存在被减少接收业务请求的数量的接口,若是,则可进一步根据预先配置的各接口的优先级,从被减少接收业务请求的数量的接口中,选择至少一个接口,增加通过选择的接口接收的业务请求的数量,若否,则可等待下一次流量控制的过程。
也就是说,当可增加接口接收的业务请求的数量时,可根据接口的优先级,先增加优先级高的接口的流量。以减少在进行流量限制的接口中,相对较重要的接口被限制流量所带来的影响。也可视为,优先级高的接口被限流后产生的负面影响较高,所以可以先解除优先级高的接口的流量限制。
另外,在本说明书实施例中,可根据预设的流量步长,增加通过选择出的接口接收的业务请求的数量,以减少突然增加接口接收的业务请求数量过多,导致负载再次超过阈值的概率。
具体的,在确定出增加哪一个接口接收业务其请求的数量后,可先根据预设的流量步长,增加该接口接收的业务请求的数量,之后再判断增加后该接口接收的业务请求的数量是否不高于预设的流量上限,若是,按照增加后的数量,限制该接口接收的业务请求的数量,若否,则不限制该接口接收的业务请求的数量。
继续沿用上例,假设接口a已经被限制为每分钟接收2个业务请求,则在确定需要增加该接口a每分钟接收业务请求数量时,可以先将该接口a的流量限制变更为每分钟4个业务请求。再判断该接口接收的业务请求的数量是否不高于预设的流量上限(即,每分钟10个业务请求),则此时按照每分钟4个业务请求限制接口a的流量。
当再次确定增加该接口a每分钟接收业务请求数量时,则将该接口a的流量限制变更为每分钟6个业务请求,以此类推。直至将该接口a每分钟接收业务请求数量变更为每分钟12个业务请求之后,判断增加后该接口a接收的业务请求的数量高于预设的流量上限,则不限制该接口a接收的业务请求的数量。
可见,通过本说明书实施例提供的方法,在确定服务器的负载较低(可理解为服务器接收的业务请求数量的峰值已经过去),且存在被限制流量的接口时,还可以增加被减少流量的至少一个接口的流量,从而充分利用服务器处理业务的能力,避免资源浪费。同时,逐步增加接口流量限制,使得负载不会突然增加,减少了负载突然超过服务器处理业务能力的上限,导致设备宕机的可能。
通过图1所示的流量控制过程,针对每个接口,可预先配置该接口的优先级,在判断监测的负载是否高于预设的阈值时,若是,则根据预先配置的各接口的优先级,选择至少一个接口,减少通过该接口接收的业务请求的数量,若否,根据各接口的优先级,选择至少一个接口,增加通过该接口接收的业务请求的数量。本说明书提供的流量控制方法,由于可根据预设周期不断的监测负载,所以可以动态的对选择不完全相同的接口,并对选择的接口进行流量控制,使得在避免了设备长时间在高负载运行的同时,又保证了设备资源不会造成浪费。
另外,在本说明书一个或多个实施例中,可以根据需要设置在进行流量限制以及解除流量限制时,选择的接口的数量,本说明书实施例对此不做限定。例如,设置为选择3个接口进行流量限制,则可根据如表1所示的各接口的优先级,在确定需要进行流量限制时,可以选择接口a、b、d进行流量限制。
进一步地,在本说明书实施例中,优先级可包括:为各接口配置的权重值以及各接口处理业务请求的耗时,其中,所述权重值越高,则优先级越高;当权重值相同时,所述耗时越短,则优先级越高。则在进行流量控制时,若选择出多个接口的权重值一致时,还可以根据选择出的各接口的处理业务请求的耗时,选择接口进行流量限制。
具体的,由于服务器中各接口处理业务的时间可以根据日志中记录的数据确定,所以可以确定服务器处理单个业务请求的耗时。其中,该耗时可以是一段时间内的处理单个业务请求的平均耗时。该一段时间可以根据需要进行设置,例如,15分钟。则当进行流量控制时,若选择出多个接口的优先级一致时,还可以根据选择出的优先级一致的各接口处理单个业务请求的耗时,按照耗时从长到短的顺序,选择接口进行流量控制,如表3所示。
接口标识 |
接口权重值 |
耗时 |
a |
1 |
1分钟 |
b |
1 |
10秒 |
c |
2 |
10分钟 |
d |
1 |
2分钟 |
表3
表3所示的接口优先级以及耗时的对应关系。其中,接口a、b、d的优先级一致,并且低于接口c的优先级。当以优先级低的先进行流量控制,并且仅选择一个接口进行流量控制时,首先可以确定选择接口a、b、d中的一个进行流量控制,之后在根据接口a、b、d分别处理业务请求的耗时,确定对接口d进行流量控制。通过上述过程,可以避免处理业务请求耗时快的接口受到流量限制,减少排队等待接口接收的业务请求的数量。
当然,在本说明书实施例中,如何确定接口处理单个业务请求的耗时,该耗时是最近一次处理业务请求的耗时,还是一段时间内处理业务请求的平均耗时,是按照耗时从长到短选择进行流量控制的接口,还是按照耗时从短到长选择进行流量控制的接口,本说明书并不做具体限定。
进一步地,在本说明书实施例中,在步骤S108中选择接口增加流量时与减少流量时类似,也可根据进行流量限制的各接口的优先级,以及各接口处理业务请求的耗时,按照耗时从短到长的顺序,选择接口增加流量。
具体的,在确定需要增加接口的流量时,可以先确定各被减少流量的接口的权重值,当按照权重值从高到低的顺序选择出多个权重值一致的接口时,可以进一步确定选择出的各接口处理业务请求的耗时,再按照耗时从短到长的顺序,选择至少一个接口增加流量。
需要说明的是,该权重值可以根据需要设置,可以与业务的重要程度存在对应关系。例如,重要程度越高的业务,接收该业务的业务请求的接口权重值越高。
更进一步地,在本说明书实施例中,针对每个接口,当按照流量步长减少该接口接收的业务请求的数量时,该被减少后该接口接收业务请求的数量低于为该接口配置的流量下限时,可以按照该流量下限限制该接口接收业务请求的数量。并且,由于该接口接收业务请求的数量已经达到流量下限,所以后续可不再减少该接口接收业务请求的数量,即不再对该接口进行流量限制。反之,在针对被减少接收的业务请求的数量的接口,按照流量步长增加接收的业务请求的数量时,若增加后该接口接收的业务请求的数量,超过为该接口配置的流量上限,则不再对该接口接收的业务请求的数量进行限制。
于是,在本说明书实施例中,针对每个接口当确定减少该接口的流量时,可以根据为该接口配置的流量上限、流量步长以及流量下限中的至少一种进行限流,如图2a以及图2b所示。
图2a为本说明书实施例提供的减少接口的流量的示意图。其中,该示意图显示接口a的流量上限每10秒9个、流量步长每10秒3个以及流量下限每10秒2个。纵轴表示该接口a每10秒接收的业务请求数量,横轴表示时间,每个时间刻度的时间间隔为预设的周期,即10秒钟。当判断服务器负载高于预设阈值时(如,第20秒),通过按照周期监测服务器的负载,确定减少该接口a接收到的业务请求数量,直至达到该接口a的流量下限,图2a所示。图2b为本说明书实施例提供的增加接口的流量的示意图,当判断服务器负载低于预设阈值时(如,第120秒),按照周期增加该接口a接收到的业务请求数量,直到超过为接口a配置的流量上限,不再对该接口a进行流量控制(如,从第150s开始),如图2b所示。
当然,在本申请实施例中,针对每个接口,也可不设置该接口对应的流量上限。则当确定减少任一接口接收的业务请求的数量时,可以根据该接口当前接收到的接收的业务请求的数量为基础,按照流量步长减少该接口接收的业务请求的数量。
需要说明的是,本申请实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤S102和步骤S104的执行主体可以为设备1,步骤S106和步骤S108的执行主体可以为设备2;又比如,步骤S102和骤S106的执行主体可以为设备2,步骤S104和步骤S108的执行主体可以为设备1;等等。上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
基于图1所示的流量控制过程,本说明书实施例还对应提供另一种流量控制详细过程,如图3所示。
S302:监测负载;
S304:判断所述负载是否高于预设阈值,若是则执行步骤S306,若否则执行步骤S308;
S306:根据预先配置的各接口的优先级,选择至少一个接口,减少通过选择的接口接收的业务请求的数量;
S308:判断是否存在被减少接收业务请求的数量的接口,若是则执行步骤S310,若否则执行步骤S312;
S310:根据所述预先配置的各接口的优先级,从所述被减少接收业务请求的数量的接口中选择至少一个接口,增加通过选择的接口接收的业务请求的数量;
S312:不进行流量控制。
基于图1所示的流量控制过程,本说明书实施例还对应提供另一种流量控制装置,如图4所示。
图4为本说明书实施例提供的一种流量控制装置的结构示意图,具体包括:
监测模块202,监测负载;
判断执行模块204,判断所述负载是否高于预设阈值,若是,则根据预先配置的各接口的优先级,选择至少一个接口,减少通过选择的接口接收的业务请求的数量,若否,则根据所述预先配置的各接口的优先级,选择至少一个接口,增加通过选择的接口接收的业务请求的数量。
所述监测模块202,按照预设的周期,监测中央处理器CPU使用率和/或CPU负载。
所述判断执行模块204,根据预设的CPU使用率对应的第一阈值,判断监测得到的所述CPU使用率,是否高于所述第一阈值,和/或根据预设的CPU负载对应的第二阈值,判断监测得到的所述CPU负载是否高于所述第二阈值。
所述判断执行模块204,当判断所述负载高于预设阈值时,根据所述预先配置的各接口优先级,按照从低到高的顺序,选择至少一个接口。
所述判断执行模块204,当判断所述负载不高于预设阈值时,根据所述预先配置的各接口优先级,按照从高到低的顺序,选择至少一个接口。
所述优先级包括:为各接口配置的权重值以及各接口处理业务请求的耗时,其中,所述权重值越高,则优先级越高,当权重值相同时,所述耗时越短,则优先级越高。
所述判断执行模块204,当判断所述负载不高于预设阈值时,从各接口中,确定被减少接收业务请求的数量的接口,按照确定出的各接口的优先级从高到低的顺序,从所述确定出的各接口中选择至少一个接口。
所述判断执行模块204,当判断所述负载高于预设阈值时,根据预先配置的各接口的流量下限,从各接口中确定流量不小于所述流量下限的接口,按照确定出的各接口的优先级从低到高的顺序,选择至少一个接口。
所述判断执行模块204,判断所述选择的接口接收的业务请求的数量是否高于预设的流量上限,若是,则将所述选择的接口接收的业务请求的数量减少至所述流量上限,若否,则按照预设的流量步长,减少通过选择的接口接收的业务请求的数量。
所述判断执行模块204,根据预设的流量步长,增加通过所述选择出的接口接收的业务请求的数量,判断增加后所述选择的接口接收的业务请求的数量是否不高于预设的流量上限,若是,则按照增加后的数量,限制所述选择出的接口接收的业务请求的数量,若否,则不限制所述选择出的接口接收的业务请求的数量。
具体的,所述流量控制装置,可以位于服务器中。该服务器可以是单独的一台设备,或者多台设备组成的系统,本说明书对此不做限定。
基于图1所示流量控制方法,本申请实施例还对应提供一种服务器的结构示意图,如图5所示。
图5为本申请实施例提供的一种服务器的结构示意图,所述服务器包括一个或多个处理器及存储器,所述存储器存储有程序,并且被配置成由所述一个或多个处理器执行以下步骤:
监测负载;
判断所述负载是否高于预设阈值;
若是,则根据预先配置的各接口的优先级,选择至少一个接口,减少通过选择的接口接收的业务请求的数量;
若否,则根据所述预先配置的各接口的优先级,选择至少一个接口,增加通过选择的接口接收的业务请求的数量。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于本申请实施例提供的移动终端以及服务器而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。