CN103546542A - 服务器负载均衡方法和装置 - Google Patents

Abstract

本发明提供一种服务器负载均衡方法和装置。该方法包括：接收并解析用户提交的包括应用请求、应用请求所属应用的标识以及应用的已部署服务器列表的应用请求信息，服务器列表中的每个服务器中可部署至少一个应用；将应用请求发送至服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量和吞吐量阈值分别根据部署在各服务器中的每个应用的请求到达率和在单应用环境下的请求到达率阈值得到。本发明提供的服务器负载均衡方法和装置，通过将应用请求发送至吞吐量小于吞吐量阈值的服务器中，有效地保证了服务器中所有应用的服务质量需求。

Description

服务器负载均衡方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种服务器负载均衡方法和装置。

背景技术

近年来随着互联网技术的不断发展，云计算在商业界与学术界都得到了广泛的应用与研究。云计算的关键特征是按需提供服务，根据云计算中提供的服务的层次，可以将云计算的主要服务分为云应用、云平台及云基础设施3个层次。

多租户（multi-tenancy）技术，也称为多重租赁技术，是一种软件架构技术，用于实现如何在多用户环境下共用相同的系统或程序组件，并确保各用户间数据的隔离性。多租户技术应用于云平台中，是指多个应用共享同一个操作系统实例即同一个服务器。

现有技术中，随着分布式集群等技术的发展，一个网络Web应用能够同时运行于不同的服务器节点中，从而为持续增长的用户提供服务。负载均衡策略，即根据各个服务器的负载情况，把一个应用的多个应用请求分配给不同的服务器节点，使得多个服务器可以同时参与相同的工作，提高应用的伸缩性。

但现有的负载均衡方法，只适用于传统环境（例如分布式集群计算），对于采用多租户技术的云平台，由于未考虑多个应用之间的相互竞争，当分配至某个服务器的应用请求的数量很大时，很可能导致该服务器的负载过大，无法保证部署在该服务器中的所有应用的服务质量需求。

发明内容

本发明提供一种服务器负载均衡方法和装置，用以解决现有技术中存在的对于采用多租户技术的云平台，无法保证所有应用的服务质量需求的问题。

一方面，本发明提供了一种服务器负载均衡方法，包括：

接收并解析用户提交的应用请求信息，所述应用请求信息中包括应用请求、所述应用请求所属应用的标识以及所述应用的已部署服务器列表，所述服务器列表中的每个服务器中可部署至少一个应用；

将所述应用请求发送至所述服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

另一方面，本发明提供了一种服务器负载均衡装置，包括：

接收模块，用于接收并解析用户提交的应用请求信息，所述应用请求信息中包括应用请求、所述应用请求所属应用的标识以及所述应用的已部署服务器列表，所述服务器列表中的每个服务器中可部署至少一个应用；

发送模块，用于将所述应用请求发送至所述服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

本发明提供的服务器负载均衡方法和装置，通过将应用请求发送至可部署至少一个应用且吞吐量小于吞吐量阈值的服务器中，其中服务器的吞吐量和吞吐量阈值根据该服务器中每个应用的请求到达率和在单应用环境下的请求到达率阈值得到，有效地保证了服务器中所有应用的服务质量需求。

附图说明

图1为本发明提供的服务器负载均衡方法一个实施例的流程示意图；

图2为本发明提供的服务器负载均衡方法又一个实施例的流程示意图；

图3为本发明提供的服务器负载均衡装置一个实施例的结构示意图。

具体实施方式

下面通过具体的实施例及附图，对本发明的技术方案做进一步的详细描述。

图1为本发明提供的服务器负载均衡方法一个实施例的流程示意图。如图1所示，该方法具体可以包括：

S101，接收并解析用户提交的应用请求信息，应用请求信息中包括应用请求、应用请求所属应用的标识以及应用的已部署服务器列表，服务器列表中的每个服务器中可部署至少一个应用。

具体的，本实施例提供的服务器负载均衡方法适用于多个应用共享同一个服务器的情况，每个服务器中包括多个中央处理器（CentralProcessing Unit，简称CPU）核心，且服务器中部署的多个应用为CPU密集型应用，即同一个服务器中的多个应用之间存在竞争资源的关系。

接收并解析用户通过客户端等提交的应用请求信息，应用请求信息具体可以为网络Web应用请求信息，例如Servlet等应用请求信息。应用请求信息中包括该应用请求所属应用的标识，用于标识该请求是属于哪个应用的一个请求。应用请求信息中还包括该应用的已部署服务器列表，即每个应用对应的服务器为预先部署好的，每个服务器中可部署多个应用，每个应用的多个应用请求被分配至不同的服务器中，使得多个服务器同时参与相同的工作，提高应用的伸缩性。

S102，将应用请求发送至服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

具体的，将上述服务器列表中的每个服务器的吞吐量和各自的吞吐量阈值进行比较，如果存在吞吐量小于吞吐量阈值的服务器，则将该应用请求发送至该服务器中，如果不存在吞吐量小于吞吐量阈值的服务器，则丢弃该应用请求。每个应用在单应用环境下的请求到达率阈值，即服务器中只部署一个应用的情况下，该应用的请求到达率阈值。

本实施例提供的服务器负载均衡方法，通过将应用请求发送至可部署至少一个应用且吞吐量小于吞吐量阈值的服务器中，其中服务器的吞吐量和吞吐量阈值根据该服务器中多个应用的请求到达率和在单应用环境下的请求到达率阈值得到，有效地保证了服务器中所有应用的服务质量需求。

图2为本发明提供的服务器负载均衡又一个实施例的流程示意图。如图2所示，该方法具体可以包括：

S201，根据服务器中每个应用的平均响应时间阈值，计算服务器的吞吐量阈值。具体为：

根据服务器中每个应用的平均响应时间阈值，计算服务器中每个应用在单应用环境下的请求到达率阈值；

根据服务器中每个应用在单应用环境下的请求到达率阈值、服务器中每个应用的平均处理时间以及服务器的中央处理器核心数量，计算服务器中每个应用在单应用环境下的负载强度阈值；

将服务器中每个应用在单应用环境下的负载强度阈值中的最小值作为服务器的负载强度阈值，并将服务器的负载强度阈值和服务器的中央处理器核心数量相乘，得到服务器的吞吐量阈值。

具体的，本实施例提供的服务器负载均衡方法适用于多个应用共享同一个服务器的情况，每个服务器中包括多个CPU核心，且服务器中部署的多个应用为CPU密集型应用，即同一个服务器中的多个应用之间存在竞争资源的关系。

可以采用排队模型对多应用服务器进行建模，一个典型的排队模型由输入过程、排队规则和服务过程三部分组成。通常假定应用请求的到达过程为泊松过程，排队规则为先来先服务，服务过程为应用请求在服务台中的处理过程，应用请求在服务器中的响应时间为等待时间加上处理时间。

排队过程属于马尔可夫过程，可以用某个时刻服务器中应用请求的数量来表示服务器的状态，应用请求的到达或完成可以用应用请求数量的变化，即服务器状态的转换来表示。假设给定应用请求的到达分布与处理时间分布，则可以构造出该服务器的状态转移概率矩阵。

一个排队模型可以由六个系数表示，例如A/S/c/K/N/D。其中，A表示应用请求到达间隔时间的分布，S表示应用请求的处理时间分布，c表示服务器中CPU核心的数量，K表示服务器最大可容纳的应用请求的数量，N表示应用请求的数量，D表示排队规则。在实际应用中，最后两个系数通常被省略，即表示应用请求的数量为无限多个，且排队规则为先来先服务。

本实施例中，采用的排队模型具体为M/G/s/s+r，其中，M表示应用请求到达间隔时间的分布为泊松分布，G表示应用请求的处理时间分布为一般分布，s表示服务器中CPU核心的数量为s个，r表示队列长度，s+r表示服务器最大可容纳的应用请求的数量为s+r个。由于该模型中应用请求的处理时间为一般分布，因而不再具有负指数分布的无记忆性，目前还没有确定性的解法。鉴于此，本实施例采用T.Kimura的近似方法，得出M/G/s/s+r排队模型在平稳状态下应用请求数量的概率分布如下：

$P_j=\left\{\begin{array}{c}\frac{{\left(\mathrm{s\ρ}\right)}^j}{j!}{P}_0,j=0,...s-1\\ \frac{{\left(\mathrm{s\ρ}\right)}^s}{s!}\frac{1-\mathrm{\δ}}{1-\mathrm{\ρ}}{\mathrm{\δ}}^{j-s}{P}_0,j=s,...s+r-1\\ \frac{{\left(\mathrm{s\ρ}\right)}^s}{s!}{{\mathrm{\δ}}^{r}P}_0,j=s+r\end{array}\right.---\left(1\right)$

其中：

$P_0={[\underset{j=0}{\overset{s-1}{\mathrm{\Σ}}}\frac{{\left(\mathrm{s\ρ}\right)}^j}{j!}+\frac{{\left(\mathrm{s\ρ}\right)}^s}{s!}\frac{1-\mathrm{\ρ}{\mathrm{\δ}}^r}{1-\mathrm{\ρ}}]}^{-1}$

$\mathrm{\δ}=\frac{\mathrm{\ρ}{R}_G}{1-\mathrm{\ρ}+\mathrm{\ρ}{R}_G}---\left(3\right)$

$\mathrm{\&rho;}=\frac{\mathrm{\&lambda;\&mu;}}{s}<1---\left(4\right)$

其中，R_G表示M/G/s模型与M/M/s模型中平均等待时间的比值，Sze给出了该比值的近似解：

$R_G=\frac{\mathrm{EW}(M/G/s)}{\mathrm{EW}(M/M/s)}=\frac{1+C_v^2}{2}---\left(5\right)$

λ表示应用请求到达率，即单位时间内到达的应用请求的数量。μ表示应用请求处理时间分布的期望，即平均处理时间。C_v表示应用请求处理时间分布的变异系数。ρ表示负载强度。P₀表示服务器中无应用请求的概率。

根据公式（1）和科特尔法则，得出M/G/s/s+r排队模型中应用请求的平均响应时间W为：

$W=\frac{L}{\mathrm{\&lambda;}(1-P_{s+r})}=\frac{{\mathrm{\&Sigma;}}_{j=0}^{s+r}j{P}_j}{\mathrm{\&lambda;}(1-P_{s+r})}---\left(6\right)$

其中，L表示平均应用请求数，P_s+r表示服务器中队列被占满的概率。

尽管由公式（6）可以推导出W的具体形式，但由于其复杂性，因此并没有实际意义。考虑到实际应用中，服务器中队列长度r通常很大，但对W的影响却很小，且W是r的递增函数，因此可以通过对W关于队列长度r取极限，从而消除队列长度r的影响，得到平均响应时间W为：

$\begin{array}{c}W=\frac{\frac{s!}{{\left(\mathrm{s\&rho;}\right)}^{s-1}}{\mathrm{\&Sigma;}}_{j=0}^{s-1}\frac{{\left(\mathrm{s\&rho;}\right)}^j}{j!}-s+\frac{s-\mathrm{s\&delta;}+\mathrm{\&delta;}}{(1-\mathrm{\&rho;})(1-\mathrm{\&delta;})}}{\mathrm{\&lambda;}(\frac{s!}{{\left(\mathrm{s\&rho;}\right)}^s}{\mathrm{\&Sigma;}}_{j=0}^{s-1}\frac{{\left(\mathrm{s\&rho;}\right)}^j}{j!}+\frac{1}{1-\mathrm{\&rho;}})}\\ =\mathrm{\&mu;}+\frac{{\mathrm{\&mu;R}}_G}{s(\frac{s!}{{\left(\mathrm{\&lambda;\&mu;}\right)}^s}{\mathrm{\&Sigma;}}_{j=0}^{s-1}\frac{{\left(\mathrm{\&lambda;\&mu;}\right)}^j}{j!}{(1-\frac{\mathrm{\&lambda;\&mu;}}{s})}^2+1-\frac{\mathrm{\&lambda;\&mu;}}{s})}\\ =\mathrm{\&mu;}+\mathrm{\&Delta;}\left(\mathrm{\&lambda;}\right)\end{array}---\left(7\right)$

由于服务器中每个应用的平均响应时间阈值W_max，每个应用的平均处理时间μ，CPU核心数量s，M/G/s模型与M/M/s模型中平均等待时间的比值R_G均为已知参数，根据公式（7），可计算得到服务器中每个应用在单应用环境下的请求到达率阈值λ_max。

根据计算得到的服务器中每个应用在单应用环境下的请求到达率阈值λ_max，以及公式（4），可计算得到服务器中每个应用在单应用环境下的负载强度阈值ρ_max。

将计算得到的服务器中每个应用在单应用环境下的负载强度阈值ρ_max中最小的负载强度阈值ρ_max-min作为该服务器的整体负载强度阈值，因此在多应用环境下，当服务器的整体负载强度小于或者等于该服务器的整体负载强度阈值ρ_max-min时，该服务器中每个应用的负载强度ρ均小于或者等于各自的负载强度阈值ρ_max，而且根据公式（4）和（7）可知，该服务器中每个应用的负载强度ρ和自身的平均响应时间W成正比，因此当服务器的整体负载强度小于或者等于该服务器的整体负载强度阈值ρ_max-min时，该服务器中每个应用的平均响应时间W均小于或者等于各自的平均响应时间阈值W_max。根据公式（4），服务器的整体负载强度小于或者等于该服务器的整体负载强度阈值ρ_max-min可以转化为

其中，n为该服务器中部署的应用的数量，我们定义不等式左边为服务器的吞吐量，右边为服务器的吞吐量阈值。因此只需要保证服务器的吞吐量小于或者等于服务器的吞吐量阈值，即可保证服务器中每个应用的平均响应时间W均小于或者等于各自的平均响应时间阈值W_max。

根据服务器的整体负载强度阈值ρ_max-min，以及CPU核心数量s，计算得到该服务器的吞吐量阈值T_max=sρ_max-min。

S202，将服务器中每个应用的平均处理时间和请求到达率的乘积相加，得到服务器的吞吐量。

具体的，假设该服务器中部署有n个应用，则根据服务器中每个应用的平均处理时间μ_i以及服务器中每个应用的请求到达率λ_i，计算得到该服务器的吞吐量

S203，接收并解析用户提交的应用请求信息，应用请求信息中包括应用请求、应用请求所属应用的标识以及应用的已部署服务器列表，服务器列表中的每个服务器中可部署至少一个应用。

S204，将应用请求发送至服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

步骤S203和S204参见图1所示实施例中关于步骤S101和S102的相关描述，此处不再赘述。

S205，更新服务器的吞吐量。具体为：

更新服务器中该应用的请求到达率；

根据该应用的平均处理时间、更新后服务器中该应用的请求到达率以及服务器中其他应用的平均处理时间以及请求到达率，更新服务器的吞吐量。

具体的，假设应用请求所属的应用为第k（k≤n）个应用，则将应用请求发送至吞吐量小于吞吐量阈值的服务器之后，更新第k个应用的请求到达率λ_k为λ'_k=λ_k+1。然后根据第k个应用的平均处理时间μ_k、更新后第k个应用的请求到达率λ'_k以及服务器中其他应用的平均处理时间μ_i（1≤i≤n，且i≠k）、请求到达率λ_i（1≤i≤n，且i≠k），更新服务器的吞吐量T为

以便于后续接收到应用请求时，准确判断该服务器的吞吐量是否小于吞吐量阈值。

本实施例提供的服务器负载均衡方法，通过将应用请求发送至可部署至少一个应用且吞吐量小于吞吐量阈值的服务器中，其中服务器的吞吐量和吞吐量阈值根据该服务器中每个应用的请求到达率和在单应用环境下的请求到达率阈值得到，使得服务器中每个应用的平均响应时间均小于各自的平均响应时间阈值，有效地保证了服务器中所有应用的服务质量需求。

图3为本发明提供的服务器负载均衡装置一个实施例的结构示意图。如图3所示，本实施例提供的服务器负载均衡装置为执行上述服务器负载均衡方法的特定执行主体。该装置具体可以包括：接收模块31和发送模块32，其中：

接收模块31，用于接收并解析用户提交的应用请求信息，应用请求信息中包括应用请求、应用请求所属应用的标识以及应用的已部署服务器列表，服务器列表中的每个服务器中可部署至少一个应用。

具体的，本实施例提供的服务器负载均衡装置适用于多个应用共享同一个服务器的情况，每个服务器中包括多个CPU核心，且服务器中部署的多个应用为CPU密集型应用，即同一个服务器中的多个应用之间存在竞争资源的关系。

接收模块31接收并解析用户通过客户端等提交的应用请求信息，应用请求信息具体可以为网络Web应用请求信息，例如Servlet等应用请求信息。应用请求信息中包括该应用请求所属应用的标识，用于标识该请求是属于哪个应用的一个请求。应用请求信息中还包括应用的已部署服务器列表，即每个应用对应的服务器为预先部署好的，每个服务器中可部署多个应用，每个应用的多个应用请求被分配至不同的服务器中，使得多个服务器同时参与相同的工作，提高应用的伸缩性。

发送模块32，将应用请求发送至服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

具体的，发送模块32将上述服务器列表中的每个服务器的吞吐量和各自的吞吐量阈值进行比较，如果存在吞吐量小于吞吐量阈值的服务器，则将该应用请求发送至该服务器中，如果不存在吞吐量小于吞吐量阈值的服务器，则丢弃该应用请求。每个应用在单应用环境下的请求到达率阈值，即服务器中只部署一个应用的情况下，该应用的请求到达率阈值。

进一步的，该装置还可以包括：

计算模块33，用于在接收模块31接收用户提交的应用请求信息之前，根据服务器中每个应用的平均响应时间阈值，计算服务器的吞吐量阈值。具体用于：

根据服务器中每个应用的平均响应时间阈值，计算服务器中每个应用在单应用环境下的请求到达率阈值；

根据服务器中每个应用在单应用环境下的请求到达率阈值、服务器中每个应用的平均处理时间以及服务器的中央处理器核心数量，计算服务器中每个应用在单应用环境下的负载强度阈值；

将服务器中每个应用在单应用环境下的负载强度阈值中的最小值作为服务器的负载强度阈值，并将服务器的负载强度阈值和服务器的中央处理器核心数量相乘，得到服务器的吞吐量阈值。

具体的，计算模块33可以采用M/G/s/s+r排队模型对多应用服务器进行建模，根据上述公式（7），计算得到服务器中每个应用在单应用环境下的请求到达率阈值λ_max。根据计算得到的服务器中每个应用在单应用环境下的请求到达率阈值λ_max，以及公式（4），计算得到服务器中每个应用在单应用环境下的负载强度阈值ρ_max。将计算得到的服务器中每个应用在单应用环境下的负载强度阈值ρ_max中最小的负载强度阈值ρ_max-min作为该服务器的整体负载强度阈值，根据服务器的整体负载强度阈值ρ_max-min，以及CPU核心数量s，计算得到该服务器的吞吐量阈值T_max=sρ_max-min。具体过程可以参见图2所示实施例中步骤S201中的相关描述，此处不再赘述。

进一步的，计算模块33还可以用于：

在接收模块31接收用户提交的应用请求信息之前，将服务器中每个应用的平均处理时间和请求到达率的乘积相加，得到服务器的吞吐量。

具体的，假设该服务器中部署有n个应用，则计算模块33根据服务器中每个应用的平均处理时间μ_i以及服务器中每个应用的请求到达率λ_i，计算得到该服务器的吞吐量

进一步的，该装置还可以包括：

更新模块34，用于在发送模块32将应用请求发送至服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理之后，更新服务器的吞吐量。具体用于：

更新服务器中该应用的请求到达率；

根据该应用的平均处理时间、更新后服务器中该应用的请求到达率以及服务器中其他应用的平均处理时间以及请求到达率，更新服务器的吞吐量。

具体的，假设应用请求所属的应用为第k（k≤n）个应用，则将应用请求发送至吞吐量小于吞吐量阈值的服务器之后，更新第k个应用的请求到达率λ_k为λ'_k=λ_k+1。然后根据第k个应用的平均处理时间μ_k、更新后第k个应用的请求到达率λ'_k以及服务器中其他应用的平均处理时间μ_i（1≤i≤n，且i≠k）、请求到达率λ_i（1≤i≤n，且i≠k），更新服务器的吞吐量T为

以便于后续接收到应用请求时，准确判断该服务器的吞吐量是否小于吞吐量阈值。

本实施例提供的服务器负载均衡装置，通过将应用请求发送至可部署至少一个应用且吞吐量小于吞吐量阈值的服务器中，其中服务器的吞吐量和吞吐量阈值根据该服务器中每个应用的请求到达率和在单应用环境下的请求到达率阈值得到，使得服务器中每个应用的平均响应时间均小于各自的平均响应时间阈值，有效地保证了服务器中所有应用的服务质量需求。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (10)

1.一种服务器负载均衡方法，其特征在于，包括：

接收并解析用户提交的应用请求信息，所述应用请求信息中包括应用请求、所述应用请求所属应用的标识以及所述应用的已部署服务器列表，所述服务器列表中的每个服务器中可部署至少一个应用；

将所述应用请求发送至所述服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

2.根据权利要求1所述的方法，其特征在于，所述接收用户提交的应用请求信息之前，还包括：

根据所述服务器中每个应用的平均响应时间阈值，计算所述服务器的吞吐量阈值。

3.根据权利要求2所述的方法，其特征在于，所述根据所述服务器中每个应用的平均响应时间阈值，计算所述服务器的吞吐量阈值，包括：

根据所述服务器中每个应用的平均响应时间阈值，计算所述服务器中每个应用在单应用环境下的请求到达率阈值；

根据所述服务器中每个应用在单应用环境下的请求到达率阈值、所述服务器中每个应用的平均处理时间以及所述服务器的中央处理器核心数量，计算所述服务器中每个应用在单应用环境下的负载强度阈值；

将所述服务器中每个应用在单应用环境下的负载强度阈值中的最小值作为所述服务器的负载强度阈值，并将所述服务器的负载强度阈值和所述服务器的中央处理器核心数量相乘，得到所述服务器的吞吐量阈值。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述接收用户提交的应用请求信息之前，还包括：

将所述服务器中每个应用的平均处理时间和请求到达率的乘积相加，得到所述服务器的吞吐量。

5.根据权利要求1所述的方法，其特征在于，所述将所述应用请求发送至所述服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理之后，还包括：

更新所述服务器的吞吐量。

6.根据权利要求5所述的方法，其特征在于，所述更新所述服务器的吞吐量，包括：

更新所述服务器中所述应用的请求到达率；

根据所述应用的平均处理时间、更新后所述服务器中所述应用的请求到达率以及所述服务器中其他应用的平均处理时间以及请求到达率，更新所述服务器的吞吐量。

7.一种服务器负载均衡装置，其特征在于，包括：

接收模块，用于接收并解析用户提交的应用请求信息，所述应用请求信息中包括应用请求、所述应用请求所属应用的标识以及所述应用的已部署服务器列表，所述服务器列表中的每个服务器中可部署至少一个应用；

发送模块，用于将所述应用请求发送至所述服务器列表中吞吐量小于吞吐量阈值的服务器中进行处理，各服务器的吞吐量根据部署在各服务器中的每个应用的请求到达率得到，各服务器的吞吐量阈值根据部署在各服务器中的每个应用在单应用环境下的请求到达率阈值得到。

8.根据权利要求7所述的装置，其特征在于，还包括：

计算模块，用于在所述接收模块接收用户提交的应用请求信息之前，根据所述服务器中每个应用的平均响应时间阈值，计算所述服务器的吞吐量阈值。

9.根据权利要求8所述的装置，其特征在于，所述计算模块具体用于：

根据所述服务器中每个应用的平均响应时间阈值，计算所述服务器中每个应用在单应用环境下的请求到达率阈值；

根据所述服务器中每个应用在单应用环境下的请求到达率阈值、所述服务器中每个应用的平均处理时间以及所述服务器的中央处理器核心数量，计算所述服务器中每个应用在单应用环境下的负载强度阈值；

将所述服务器中每个应用在单应用环境下的负载强度阈值中的最小值作为所述服务器的负载强度阈值，并将所述服务器的负载强度阈值和所述服务器的中央处理器核心数量相乘，得到所述服务器的吞吐量阈值。

10.根据权利要求7-9任一项所述的装置，其特征在于，所述计算模块还用于：

在所述接收模块接收用户提交的应用请求信息之前，将所述服务器中每个应用的平均处理时间和请求到达率的乘积相加，得到所述服务器的吞吐量。

Images