CN106936867B

CN106936867B - 一种业务请求的响应方法及装置

Info

Publication number: CN106936867B
Application number: CN201511017716.3A
Authority: CN
Inventors: 曹列忠
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced Nova Technology Singapore Holdings Ltd
Priority date: 2015-12-29
Filing date: 2015-12-29
Publication date: 2020-07-24
Anticipated expiration: 2035-12-29
Also published as: CN106936867A

Abstract

本申请公开了一种业务请求的响应方法及装置，所述方法包括：服务器接收业务请求，获取所述服务器自身当前的各运行参数，根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值，根据所述承载能力预估值，确定所述业务请求对应的超时时间，根据所述超时时间，对所述业务请求进行处理。与现有技术不同的是，本申请根据每一业务请求以及当前时刻服务器的运行状态，来预估出服务器处理了该业务请求后的运行状态，从而根据预估的运行状态为业务请求分配相应的超时时间。这样的方式即保证了对多变的业务请求设置合理的超时时间，也保证了服务器的运行状态不会出现过载的现象。

Description

一种业务请求的响应方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务请求的响应方法及装置。

背景技术

随着信息技术的发展，服务器(如：网站服务器)可以为不同的用户提供丰富的业务服务。

现有技术中，在用户与服务器交互的过程中，服务器往往会针对所处理的业务设置相应的超时时间。具体而言：当用户向服务器发送了获得业务服务的业务请求后，服务器就会针对接收到的业务请求进行处理，对于用户而言，会等待服务器返回响应结果。为了避免出现用户一直等待的情况，当用户的实际等待时间超过了超时时间后，服务器就会针对该用户执行发送失败通知或为该用户变更第三方服务器等操作，对业务请求进行响应。可以认为，在上述过程中，超时时间就是用户的最大等待时间。

但是，在现有的对业务请求进行响应的方式中，当服务器设置了超时时间后，对于任意的用户所发送的业务请求而言，超时时间均固定一致，然而，在实际应用场景下，不同业务请求的实际等待时间可能并不一致，如：在不同时间段，同一服务器所面临的访问压力并不相同，若采用现有的方式设置了固定的超时时间，那么，对于访问压力较大的时间段，可能会导致服务器宕机的情况；又例如：某些业务请求可能需要较长的响应时间(甚至超过预设的超时时间)，这样的场景下，服务器针对该业务请求仍会发出失败(或重试)通知，又或者为业务请求变更第三方服务器，从而影响对业务请求的处理。显然，现有技术中对业务请求的响应方式，并不适合于动态、多变的业务请求。

发明内容

本申请实施例提供一种业务请求的响应方法及装置，用以解决目前对业务请求进行响应的方式适用性较差的问题。

本申请实施例提供的一种业务请求的响应方法，包括：

服务器接收业务请求；

获取所述服务器自身当前的各运行参数；

根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值；

根据所述承载能力预估值，确定所述业务请求对应的超时时间；

根据所述超时时间，对所述业务请求进行处理。

本申请实施例提供的一种业务请求的响应装置，包括：

接收模块，用于接收业务请求；

获取模块，用于获取服务器自身当前的各运行参数；

预估值模块，用于根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值；

超时时间模块，用于根据所述承载能力预估值，确定所述业务请求对应的超时时间；

处理模块，根据所述超时时间，对所述业务请求进行处理。

本申请实施例提供一种业务请求的响应方法及装置，当服务器接收到了业务请求后，将获取该服务器自身的运行参数，在此基础上，服务器将预估处理该业务请求后，服务器届时的运行状态，也即，承载能力预估值，而承载能力预估值反映了服务器处理业务请求后服务器届时的负荷量，再根据承载能力预估值，进一步确定出应该为业务请求配置的超时时间的时长。与现有技术不同的是，在本申请实施例中，并不会统一设置固定的超时时间，而是根据每一业务请求以及当前时刻服务器的运行状态，来预估出服务器处理了该业务请求后的运行状态，从而根据预估的运行状态为业务请求分配相应的超时时间。这样的方式即保证了对多变的业务请求设置合理的超时时间，也保证了服务器的运行状态不会出现过载的现象，有效提升了对业务请求的超时时间进行设置的适用性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的业务请求的响应过程；

图2为本申请实施例提供的业务请求的响应装置结构示意图；

图3为本申请实施例提供的服务器内用于执行业务请求的响应过程的硬件结构示意图。

具体实施方式

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

图1为本申请实施例提供的业务请求的响应过程，该过程具体包括以下步骤：

S101：服务器接收业务请求。

在本申请实施例中，所述的服务器可以是服务提供方(如：网站)后台的服务器，通过该服务器，可以面向不同的用户提供各类业务服务。所述的业务请求，可以是用户为了获得服务器提供的业务服务，而使用相应的终端所发出的，这里并不构成对本申请的限定。

S102：获取所述服务器自身当前的各运行参数。

在实际应用场景下，服务器在对其接收到的业务请求进行处理的过程中，会消耗服务器自身的处理资源，如：处理业务请求会占用中央处理器(Central Processing Unit，CPU)的处理线程、或使用内存等。而服务器所消耗的处理资源可通过相应的运行参数反映出来，例如：CPU的占用率、内存的使用量等等。所以，在上述步骤S102中，可以获取服务器当前自身的运行参数。

S103：根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值。

在本申请实施例中，当服务器接收到了业务请求后，会为该业务请求配置相应的超时时间。而超时时间的配置将由服务器当前的运行状态决定，换言之，服务器将在当前运行状态的基础上，对该业务请求的处理过程进行预先估计，从而进一步决定出为该业务请求分配超时时间的时长。

基于此，可知在本申请实施例中，承载能力预估值反映了服务器处理新增的业务请求后，服务器届时的处理资源的消耗情况。承载能力预估值越高，就表明服务器所消耗的处理资源越多(即负荷越高)，反之，消耗的处理资源越少(即负荷越低)。

需要说明的是，对于上述步骤S103而言，服务器并未对新增的业务请求进行处理，而是对处理了该业务请求后的服务器的工作状态进行预估。从而，在获得了服务器的承载能力预估值后，便可以进一步确定出新增的业务请求应该分配的超时时间。也即，执行下述步骤S104。

S104：根据所述承载能力预估值，确定所述业务请求对应的超时时间。

正如前述，承载能力预估值反映了服务器对新增的业务请求进行处理后，服务器的运行状态，那么，根据承载能力预估值，也就可以进一步地确定出应该为新增的业务请求分配的等待时间，也即，超时时间。

作为本申请实施例中的一种方式，可以认为，服务器的承载能力预估值越高，那么，为业务请求所分配的超时时间越短，这是因为在服务器高负荷的运行状态下，大量的业务请求等待处理，可能会造成服务器出现宕机的现象，这将严重影响对业务请求的顺利处理，此时，可减少业务请求的超时时间，使得业务请求在等待一段时间后，转换值其他渠道进行处理，从而减缓服务器的压力，保证服务器不出现宕机的现象。当然，这里并不构成对本申请的限定。

S105：根据所述超时时间，对所述业务请求进行处理。

在确定了业务请求的超时时间后，便可以根据超时时间，对业务请求进行处理并做出相应的响应。例如：若为业务请求设置了足够长的超时时间，那么，服务器便可以对业务请求进行处理，返回进行处理后的响应结果；而如果为业务请求设置的超时时间较短，可能导致服务器来不及处理该业务请求，那么，服务器在超时时间到达后，就可以向用户返回处理失败或重试的响应结果，也可以自动变更该业务请求对应的业务渠道，即，将业务请求的服务器变更为其他第三方的服务器。当然，上述示例并不构成对本申请的限定。

通过上述步骤，当服务器接收到了业务请求后，将获取该服务器自身的运行参数，在此基础上，服务器将预估处理该业务请求后，服务器届时的运行状态，也即，承载能力预估值，而承载能力预估值反映了服务器处理业务请求后服务器届时的负荷量，再根据承载能力预估值，进一步确定出应该为业务请求配置的超时时间的时长。与现有技术不同的是，在本申请实施例中，并不会统一设置固定的超时时间，而是根据每一业务请求以及当前时刻服务器的运行状态，来预估出服务器处理了该业务请求后的运行状态，从而根据预估的运行状态为业务请求分配相应的超时时间。这样的方式即保证了对多变的业务请求设置合理的超时时间，也保证了服务器的运行状态不会出现过载的现象，有效提升了对业务请求的超时时间进行设置的适用性。

作为本申请实施例中的一种实施例，所述的运行参数包括但不限于：CPU的占用率、内存使用量、线程占用量等。这里并不构成对本申请的限定。

需要说明的是，对于服务器而言，在处理不同类型的业务请求时，所消耗的处理资源各不相同，例如：在处理用户对自身账户的历史支付记录的查询请求时，只需将该账户的历史数据调取出来，并展示给用户，因此，可以认为，查询请求只会消耗极少的服务器的处理资源。又例如：在处理用户的支付请求时，除了需要确定用户所要支付的对象之外，还需从用户账户的部分资源转移给其他账户，以完成支付流程，可以认为，支付请求将消耗一定量的服务器的处理资源。

通过上例可见，服务器在处理不同业务类型的业务请求时，将消耗不同数量的处理资源，因此，对于本申请示例中的上述内容而言，在根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值之前，所述方法还包括：确定所述业务请求所属的业务类型。

那么，在已知了相应的业务请求的业务类型，以及服务器当前的运行参数后，便可以进一步的预估出服务器在当前运行状态的基础上，再对该业务请求进行处理后服务器的负荷状态，也即，本申请实施例中的承载能力预估值。

确定服务器的承载能力预估值时，服务器中的各运行参数之间具有不同的权重，例如：在某服务器中，其CPU具有较强的处理性能，内存较为充足，而可提供的处理线程较少，在此情况下，有效的处理线程数量的多少，将显著影响服务器的工作负荷，因此，可以认为本示例中，处理线程的权重较大。显然，从本示例中可见，在确定服务器的承载能力预估值的过程中，需要考虑各运行参数的权重。

此外，服务器在当前运行状态的基础上，再对新增的业务请求进行处理的情况下，服务器的运行状态就会发生变化，换言之，服务器的各运行参数会发生相应的变化，具体而言，由于服务器对任意业务请求进行处理，都要消耗相应的处理资源，所以，服务器在对新增的业务请求进行处理后，其中的各运行参数的数值将增加。

基于此，在本申请实施例中，根据所述业务类型、运行参数，确定所述服务器处理所述业务请求的承载能力预估值，具体包括：确定所述业务类型所对应的各运行参数增量，根据确定出的各运行参数增量以及获取到的所述服务器自身当前的各运行参数，确定各运行参数估值，根据所述各运行参数估值，以及预先针对各运行参数设定的权重，确定各运行参数估值的加权和值，作为所述服务器处理所述业务请求的承载能力预估值。

上述过程具体可以采用下述公式：

其中，y表示承载能力预估值；

a_i表示服务器处理新增的业务请求后不同的运行参数估值，具体如：CPU占用率、内存使用量、线程使用量等；

ω_i为分别与不同的运行参数相对应的权重；

n表示运行参数的数量。

需要说明的是，在上述公式中，运行参数估值a_i是一种预估值，反映了服务器处理新增的业务请求后，各运行参数可能的取值。也就是说，此时服务器并未针对新增的业务请求进行实际处理。正如前述内容，运行参数估值a_i由服务器当前的运行参数以及处理该业务请求所对应的业务增量确定。

具体而言，运行参数估值a_i的确定可以采用下述公式：

α_i＝α′_i+Δα_i

其中，α′_i为服务器当前的运行参数；

Δα_i为运行参数增量。

需要说明的是，运行参数增量Δα_i表示了若服务器处理新增的业务请求后，其当前的运行参数的变化量。

在本申请实施例中，对于运行参数增量Δα_i而言，不同类型的业务请求所对应的运行参数增量Δα_i并不相同，这是因为：服务器在处理不同类型的业务请求时，所消耗的处理资源的可能并不相同，例如，某些业务请求，只占用一个线程；而另一些业务请求，就要占用两个或多个线程。从而，运行参数增量Δα_i将根据业务请求所对应的业务类型的不同而不同。

考虑到在实际应用中，服务器在历史上处理过各种类型的业务请求(业务请求的类型与服务器所提供的业务服务的类型相匹配)，在服务器处理每一种类型的业务请求后，服务器的各运行参数都会发生变化，因此，可以根据历史上服务器历次处理不同类型的业务请求时各运行参数的历史变化，来估测当前时刻，服务器对新增的业务请求进行处理时各运行参数可能的变化量。

基于此，对于本申请实施例的上述步骤中，确定所述业务类型所对应的各运行参数增量，其具体包括：针对每一运行参数，获取所述服务器在设定的历史时间内，每一次处理属于所述业务类型的业务请求时，该运行参数的历史变化量，在设定的历史时间内，确定所述历史变化量的均值，将所述均值确定为该运行参数增量。

例如：假设在本示例中，服务器中的运行参数包括：占用的线程数量、CPU占用率。

同时假设，在设定的历史时间内，服务器处理了1000个支付请求，服务器在处理每个支付请求时，其自身的各运行参数的历史变化量如下表1所示。

表1

表1中示出了服务器在历史上所处理的1000个支付请求中，每个支付请求所对应的运行参数的历史变化量。假设在本示例中，经过均值处理后，每一个支付请求需要占用CPU均值为0.5％，需要占用的线程数量的均值为1。从就可以认为，该服务器在处理支付类的请求时，每个支付请求的平均CPU占用率就为0.5％，平均占用的线程数量就为1。

如果以a₁代表CPU的占用率，以a₂代表占用的线程数量，那么，在本示例中，Δα₁就为0.5％，Δα₂就为1。

另需要说明的是，对于上述公式中的权重而言，在本申请实施例中的一种方式下，也可以根据业务请求的业务类型进行设定，换言之，不同类型的业务请求所对应各运行参数的权重可不相同，这是因为：在实际应用中，服务器在处理不同类型的业务请求时，所消耗的处理资源并不相同，某些业务请求可能占用的线程数量较多，而另一些业务请求消耗的CPU占用率较高。所以，在本申请中，可针对不同类型的业务请求设置不同的运行参数的权重，当然，具体的权重值也可以根据历史数据而得出，这里并不构成对本申请的限定。

通过上述内容，便可以针对任一业务请求，预估出服务器处理该业务请求后服务器的承载能力预估值。从而，便可以进一步地确定出应该为业务请求分配的超时时间，具体而言，在本申请实施例中，在所述承载能力预估值的上限和下限之间设有若干承载能力预估值区间，上述步骤S104，根据所述承载能力预估值，确定所述业务请求对应的超时时间，具体包括：确定所述承载能力预估值所落入的承载能力预估值区间，确定该承载能力预估值区间所对应的超时时间，将所述承载能力预估值区间所对应的超时时间确定为所述承载能力预估值对应的超时时间。

在本申请实施例中的一种方式下，服务器的承载能力预估值可在1～100之间取值，也就是说，在这种方式下，承载能力预估值的下限为1，上限为100。那么，在1～100之间，就可以设置若干区间，如：[1，5]、[6，10]……等等；或者[1，40]、[41，59]……等等。区间的分档通常会根据服务器的负载阶段进行设置，这里并不构成对本申请的限定。

每一个承载能力预估值区间都对应着相应的超时时间，如：区间[1，5]对应的超时时间为20s；区间[41，59]对应的超时时间为22s等。当然，在本申请实施例中，承载能力预估值区间也可以对应超时时间范围，如：区间[41，59]对应的超时时间范围为15s～22s。那么，在实际确定承载能力预估值对应的超时时间时，就可以从承载能力预估值区间对应的超时时间范围内任意选择出一个超时时间，作为业务请求的超时时间。这里并不构成对本申请的限定。

但在实际应用中，随着服务器工作负荷的不断增加，服务器的处理能力将逐渐下降，当服务器处于高负载的情况下，处理业务请求的速度将明显降低，而如果此时，仍有大量的业务请求处于等待状态，服务器将不断工作，甚至会出现宕机的情况，而一旦服务器宕机，将严重影响对业务请求的处理。

所以，为了避免出现服务器出现宕机的情况，在本申请实施例中，在所述承载能力预估值上限和下限之间还设有承载阀值，其中，不超过所述承载阀值的承载能力预估值区间所对应的超时时间递增，也即，随所述承载能力预估值的增加而增加；而超过所述承载阀值的承载能力预估值区间所对应的超时时间递减，也即，随所述承载能力预估值的增加而减少。

可以认为，承载阀值是服务器处理能力的转折点，一旦服务器的运行状态超过其承载阀值，那么，服务器的处理效率将出现明显下降。从而可见，如果服务器的承载能力预估值超过了其承载阀值，那么，将缩短业务请求的超时时间，使得业务请求在等待一定的时间后，服务器对业务请求发出失败(重试)响应，或变更第三方服务器对业务请求进行处理，这样的方式能够缓解服务器所面临的访问压力。而对于未达到承载阀值的状态，就表明服务器的运行状态良好，可以尽可能多的处理业务请求，从而，将业务请求对应的超时时间延长，使得服务器有时间充分处理各业务请求。

正因为此，不超过所述承载阀值的承载能力预估值区间所对应的超时时间递增，超过所述承载阀值的承载能力预估值区间所对应的超时时间递减。

当然，在实际应用场景下，考虑到超时时间包括连接超时时间和处理超时时间，而连接超时时间可能会受到网络环境的干扰(如：网络抖动，其中，网络抖动是指受网络环境的影响而产生的连接超时时间的突然变化)，那么，在本申请实施例中，上述的超时时间通常大于或等于网络抖动的干扰时间+处理超时时间。其中，网络抖动的干扰时间可以由服务器根据获取到的网络环境参数来确定。这里并不构成对本申请的限定。

以上为本申请实施例提供的业务请求的响应方法，基于同样的思路，本申请实施例还提供一种业务请求的响应装置，如图2所示。

在图2中，所述业务请求的响应装置包括：接收模块201、获取模块202、预估值模块203、超时时间模块204以及响应模块205，其中，

接收模块201，用于接收业务请求。

获取模块202，用于获取服务器自身当前的各运行参数。

预估值模块203，用于根据所述业务类型、各运行参数，确定所述服务器处理所述业务请求的承载能力预估值。

超时时间模块204，用于根据所述承载能力预估值，确定所述业务请求对应的超时时间。

处理模块205，用于根据所述超时时间，对所述业务请求进行处理。

在本申请实施例中，上述装置中还包括：确定模块206，用于确定所述业务请求所属的业务类型。

在确定模块206的作用下，预估值模块203，具体用于确定所述业务类型所对应的各运行参数增量，根据确定出的各运行参数增量以及获取到的所述服务器自身当前的各运行参数，确定各运行参数估值，根据所述各运行参数估值，以及预先针对各运行参数设定的权重，确定各运行参数估值的加权和值，作为所述服务器处理所述业务请求的承载能力预估值。

更为具体地，预估值模块203，用于针对每一运行参数，获取所述服务器在设定的历史时间内，每一次处理属于所述业务类型的业务请求时，该运行参数的历史变化量，在设定的历史时间内，确定所述历史变化量的均值，将所述均值确定为该运行参数增量。

在本申请实施例中，在所述承载能力预估值的上限和下限之间设有若干承载能力预估值区间，在此基础上，超时时间模块204，具体用于确定所述承载能力预估值所落入的承载能力预估值区间，确定该承载能力预估值区间所对应的超时时间，将所述承载能力预估值区间所对应的超时时间确定为所述承载能力预估值对应的超时时间。

另外，在所述承载能力预估值上限和下限之间还设有承载阀值，其中，不超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而增加；超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而减少。

在本申请实施例中，上述的运行参数包括但不限于：中央处理器CPU的占用率、内存使用量、线程占用量等。

另外，对于本申请实施例中的上述方法和装置而言，在实际应用中，可由服务器中的硬件元件实现，具体而言，如图3所示，为本申请实施例中所提供的一种用于实现业务请求响应方法的服务器内部的硬件结构，其中包括：

通信接口，用于传输包含有业务请求和/或处理结果的数据。

存储器，用于存储针对业务请求进行响应处理的计算机程序。

处理器，用于在接收到了通信接口所传输的包含有业务请求的数据后，从存储器中调用上述计算机程序并运行，通过运行该计算机程序，执行下述步骤：

获取所述服务器自身当前的各运行参数，根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值，根据所述承载能力预估值，确定所述业务请求对应的超时时间，根据所述超时时间，对所述业务请求进行处理，将处理后的结果以数据形式通过通信接口传输。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种业务请求的响应方法，其特征在于，包括：

服务器接收业务请求；

获取所述服务器自身当前的各运行参数；

根据所述超时时间，对所述业务请求进行处理；

其中，根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值，具体包括：

确定所述业务请求所属的业务类型所对应的各运行参数增量；

根据所述各运行参数增量以及所述各运行参数确定各运行参数估值；

根据所述各运行参数估值确定所述承载能力预估值。

2.如权利要求1所述的方法，其特征在于，在根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值之前，所述方法还包括：

确定所述业务请求所属的业务类型。

3.如权利要求1所述的方法，其特征在于，根据所述各运行参数，确定所述服务器处理所述业务请求的承载能力预估值，具体包括：

根据所述各运行参数估值，以及预先针对各运行参数设定的权重，确定各运行参数估值的加权和值，作为所述服务器处理所述业务请求的承载能力预估值。

4.如权利要求1所述的方法，其特征在于，确定所述业务类型所对应的各运行参数增量，具体包括：

针对每一运行参数，获取所述服务器在设定的历史时间内，每一次处理属于所述业务类型的业务请求时，该运行参数的历史变化量；

在设定的历史时间内，确定所述历史变化量的均值；

将所述均值确定为该运行参数增量。

5.如权利要求1所述的方法，其特征在于，在所述承载能力预估值的上限和下限之间设有若干承载能力预估值区间；

根据所述承载能力预估值，确定所述业务请求对应的超时时间，具体包括：

确定所述承载能力预估值所落入的承载能力预估值区间；

确定该承载能力预估值区间所对应的超时时间；

将所述承载能力预估值区间所对应的超时时间确定为所述承载能力预估值对应的超时时间。

6.如权利要求5所述的方法，其特征在于，在所述承载能力预估值上限和下限之间还设有承载阀值，其中，不超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而增加；

超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而减少。

7.如权利要求1～6任一所述的方法，其特征在于，所述运行参数包括：中央处理器CPU的占用率、内存使用量、线程占用量中的至少一种。

8.一种业务请求的响应装置，其特征在于，包括：

接收模块，用于接收业务请求；

获取模块，用于获取服务器自身当前的各运行参数；

处理模块，用于根据所述超时时间，对所述业务请求进行处理；

其中，所述预估值模块，具体用于确定所述业务请求所属的业务类型所对应的各运行参数增量，根据所述各运行参数增量以及所述各运行参数确定各运行参数估值，根据所述各运行参数估值确定所述承载能力预估值。

9.如权利要求8所述的装置，其特征在于，所述装置还包括：确定模块，用于确定所述业务请求所属的业务类型。

10.如权利要求8所述的装置，其特征在于，所述预估值模块，具体用于根据所述各运行参数估值，以及预先针对各运行参数设定的权重，确定各运行参数估值的加权和值，作为所述服务器处理所述业务请求的承载能力预估值。

11.如权利要求8所述的装置，其特征在于，所述预估值模块，具体用于针对每一运行参数，获取所述服务器在设定的历史时间内，每一次处理属于所述业务类型的业务请求时，该运行参数的历史变化量，在设定的历史时间内，确定所述历史变化量的均值，将所述均值确定为该运行参数增量。

12.如权利要求8所述的装置，其特征在于，在所述承载能力预估值的上限和下限之间设有若干承载能力预估值区间；

超时时间模块，具体用于确定所述承载能力预估值所落入的承载能力预估值区间，确定该承载能力预估值区间所对应的超时时间，将所述承载能力预估值区间所对应的超时时间确定为所述承载能力预估值对应的超时时间。

13.如权利要求12所述的装置，其特征在于，在所述承载能力预估值上限和下限之间还设有承载阀值，其中，不超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而增加；超过所述承载阀值的承载能力预估值区间所对应的超时时间，随所述承载能力预估值的增加而减少。

14.如权利要求8～13任一所述的装置，其特征在于，所述运行参数包括：中央处理器CPU的占用率、内存使用量、线程占用量中的至少一种。