CN104486129A - 分布式环境下保障应用服务质量的方法及系统 - Google Patents

Abstract

本发明提供一种分布式环境下定位瓶颈节点和保障应用服务质量的方法及系统。定位瓶颈节点的方法包括计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；并且根据延迟波动值确定瓶颈节点。其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的。保障应用服务质量的方法包括对于存在长尾延迟的服务定位瓶颈节点；以及，检查瓶颈节点的延迟波动值是否超过预定阈值，根据检查结果执行故障诊断或者对该瓶颈节点的服务请求执行请求调度或加速。本发明降低了请求响应时间波动并且减少了长尾延迟，此外还减少了逐级逐个对节点进行优化的开销。

Description

分布式环境下保障应用服务质量的方法及系统

技术领域

本发明涉及分布式计算技术领域，更具体地，涉及一种分布式环境下定位瓶颈节点和保障应用服务质量的方法及系统。

背景技术

目前，诸如电子邮件、搜索、网络购物、社交网络、在线视频、网络地图等的互联网应用已经成为人们生活的一部分。这些应用往往要为上亿用户服务，意味着互联网应用已变成如电力一样的社会公共服务，而支撑拥有海量用户互联网应用的各种分布式计算环境也成为如同发电厂一样的社会核心基础设施。

在分布式环境下，一般地，互联网应用会被划分由许多服务节点(或称服务模块)进行分步处理，并且这些服务模块会被部署到多个服务器上。尽管资源共享方式能够显著提高资源利用率，但同时也会带来应用之间相互干扰的问题，从而会影响到一些应用的服务质量(QoS)。例如，在分布式环境下，请求响应时间的长尾延迟效应会被进一步放大。举例来说明长尾延迟效应：假设一台机器处理请求的平均响应时间为1ms，只有1％的请求处理时间会大于1s，但如果一个请求需要由100个这样的节点一起处理，那么就可能会出现63％的请求响应时间大于1s。对于部署在分布式环境下的应用服务(简称服务)来说，服务之间的耦合模式包括划分/聚合(Partition/Aggregate)和依赖/串行(Dependent/Sequential)等。对于前者来说，请求的响应时间取决于所访问的最慢的服务器，这种模式面临严重的长尾延迟效应；对于后者来说，由于服务节点都在关键路径上，每个节点的处理延迟会累加，从而这种模式会放大长尾延迟效应。

现有的一种保障应用服务质量的方法是将请求响应时间约束在每一个处理阶段进行动态传播，同时根据每个阶段的处理消耗更新传播的响应时间约束，使用该约束对请求的优先级进行调整。然而，这种方法会在请求传递路径上的每个节点都进行优先级动态调整，并且只适用于依赖/串行模式，当应用到划分/聚合模式时，会有比较大的开销。

发明内容

为解决上述问题，根据本发明的一个实施例，提供一种分布式环境下定位瓶颈节点的方法。其中，节点是在分布式环境下划分应用服务得到的在一个或多个处理阶段处理请求的服务模块，所述方法包括：

步骤1)、计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的；

步骤2)、根据延迟波动值确定瓶颈节点。

可选的，采用下式计算节点在其处理阶段的延迟波动值：

$\mathrm{flux}\left(\mathrm{Proces}\sin \mathrm{gTme}\right)=\frac{{\mathrm{\Σ}}_{j=1}^m(\mathrm{Proces}\sin {\mathrm{gTime}}_j-E\left(\mathrm{Proces}\sin \mathrm{gTime}\right))}{m}$

其中，m表示一段时间内该节点在其处理阶段处理请求的时间不小于其处理请求时间均值E(ProcessinTime)的请求个数；ProcessinTime_j表示该节点在其处理阶段处理请求j的时间；并且 $E\left(\mathrm{Proces}\sin \mathrm{gTime}\right)=\left({\mathrm{\Σ}}_{i=1}^n\mathrm{Proces}\sin \mathrm{gTim}{e}_i\right)/n,$ 其中，n表示一段时间内该节点在其处理阶段处理的请求个数。

可选的，对于服务间采用划分/聚合模式，步骤1)还包括：查找服务的关键路径。其中，查找服务的关键路径可包括：

对于一段时间内对该服务的每个请求，查找处理该请求的关键路径，从而得到每个请求对应的一个或多个关键路径；

在预定的时间窗口内，将出现次数最多的关键路径作为该服务的关键路径。

可选的，所述方法的步骤1)还包括：记录一段时间内对服务的请求的相关信息。

可选的，对服务的请求的相关信息包括：处理阶段，以及在该处理阶段在节点上处理该请求的开始时间和完成时间。

可选的，对服务的请求的相关信息还包括：使当前节点处理该请求的开始时间最大的前一个处理阶段的节点。则步骤1)还可包括：根据所记录的使节点处理该请求的开始时间最大的前一个处理阶段的节点的信息，得到该请求对应的关键路径。

根据本发明的一个实施例，还提供一种分布式环境下定位瓶颈节点的装置，其中，节点是在分布式环境下划分应用服务得到的在一个或多个处理阶段处理请求的服务模块，所述装置包括：

瓶颈节点定位设备，用于计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；以及用于根据延迟波动值确定瓶颈节点；

其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的。

可选的，所述的装置还包括关键路径查找设备，用于查找服务的关键路径。

可选的，所述的装置还包括请求跟踪设备，用于记录一段时间内对服务的请求的相关信息。

根据本发明的一个实施例，还提供一种分布式环境下保障应用服务质量的方法，包括：

步骤A)、对于存在长尾延迟的服务，采用上述分布式环境下定位瓶颈节点的方法定位瓶颈节点；

步骤B)、检查瓶颈节点的延迟波动值是否超过预定阈值；如果超过则对该瓶颈节点执行故障诊断，如果不超过则对该瓶颈节点的服务请求执行请求调度或加速。

可选的，步骤A)还包括：对于每一个服务，判断该服务是否存在长尾延迟。其中，根据以下步骤判断服务是否存在长尾延迟：

根据对该服务的请求的响应时间的历史数据，得到服务请求的响应时间的累积分布函数；

如果响应时间大于预期响应时间的累积分布函数值大于预定阈值，则认为该服务存在长尾延迟。

可选的，在执行步骤B)后返回步骤A)。

根据本发明的一个实施例，还提供一种分布式环境下保障应用服务质量的系统，包括：

上述分布式环境下定位瓶颈节点的装置；以及

请求调度/加速设备，用于对瓶颈节点的服务请求执行请求调度或加速。

可选的，所述系统还包括：

长尾延迟判定设备，用于对于每一个服务判断该服务是否存在长尾延迟。本发明根据请求传递路径得到服务关键路径并且定位延迟波动大的瓶颈节点，对瓶颈节点上的请求进行加速或调度，具有如下有益效果：

1)有针对性地对瓶颈节点上的请求进行加速或调度处理，降低了请求响应时间波动并且减少了长尾延迟，此外减少了逐级逐个对节点进行优化的开销，适用于划分/聚合模式；

2)方便管理员快速排查系统故障、进行故障诊断；

3)在记录请求传递路径信息的时候记录了请求在网络上传输的开销，可用于定位是否在网络上存在瓶颈或故障，并减少网络延迟。

附图说明

以下参照附图对本发明实施例作进一步说明，其中：

图1是根据本发明一个实施例的分布式环境下保障应用服务质量的方法的流程图；

图2(a)和图2(b)是根据本发明一个实施例的不存在应用混布和存在应用混布的服务响应时间累积分布函数的示意图；

图3是根据本发明一个实施例的请求传递路径的树形示意图；

图4是根据本发明一个实施例的服务在节点上的延迟波动值的示意图；

图5是根据本发明一个实施例的分布式环境下保障应用服务质量的系统的操作流程图。

具体实施方式

为了使本发明的目的，技术方案及优点更加清楚明白，以下结合附图通过具体实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明

根据本发明的一个实施例，提供一种分布式环境下定位瓶颈节点的方法。

概括而言，该方法包括：计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的。该方法还包括：根据延迟波动值确定瓶颈节点。

需要说明的是，文中的节点是指从应用服务中划分出的服务模块(可看作服务节点，但其不同于具体的物理节点)，每个节点作为服务请求过程中的某一个步骤或多个步骤来处理服务请求，多个服务节点可以部署在同一个物理节点(如服务器)上。此外，说明书中描述的方法的各个步骤并非一定是必须的，而是可以省略其中一个或多个步骤，此外，各步骤之间的顺序也是可以调整的。

现参考图1，详细描述该方法的各个步骤。

第一步：记录服务请求在传递过程中的相关信息

在分布式环境中部署一个应用服务时，一般而言，其节点的划分和对请求的处理步骤(或称处理阶段)是相对固定的。服务请求的处理步骤是指首先在一个或多个节点上处理(如第一处理阶段)，接着传递到一个或多个节点进行处理(如第二处理阶段)，依此类推，直到对该请求的处理结束。针对某个服务请求，可将应用服务的各节点处理该服务请求的整个过程称为该服务请求的传递过程(其中，同一个节点可能在不同的处理阶段处理该请求)。因此，可记录服务请求在传递过程中的相应信息，并构建出该服务请求的传递路径图。例如，针对发起的一个搜索查询请求，首先搜索引擎可能会根据查询关键词进行切词，接着对搜索结果进行排序，最后返回和展示搜索结果与文档摘要等。

在本步骤中，记录一段时间内对该服务的所有请求在传递过程中的相关信息。

在一个实施例中，记录的相关信息包括：ServiceType、RequestId、ServiceLevel、NodeId、StartTime、endTime、ParNodeId、C(ParNodeId,NodeId)、Candidate(CriticalPath)和ProcessingTime。其中，ServiceType表示应用服务的类型，用于区分不同的服务；RequestId表示请求的ID号，其区分一段时间内对ServiceType服务的所有请求中的每个请求；ServiceLevel表示请求在传递过程中所处于的处理阶段(或简称阶段)；NodeId表示节点号；StartTime表示请求在ServiceLevel阶段由节点NodeId进行处理的开始时间；endTime表示请求在ServiceLevel阶段由节点NodeId处理完成的时间；C(ParNodeId,NodeId)表示服务请求从节点ParNodeId传递到节点NodeId的网络延迟，Candidate(CriticalPath)表示请求的关键路径候选节点，ProcessingTime表示请求在节点上的处理时间。

在一个实施例中，对于应用服务类型为ServiceType的服务以及请求ID号为RequestId的请求，记录该服务请求在传递过程中的相关信息的步骤如下：

1)、设置ServiceLevel＝1，同时记录发出该请求的客户端所处的节点号NodeId以及请求发出的时间StartTime_{NodeId-ServiceLevel}(NodeId节点所处的ServiceLevel阶段)；当该请求在在这个节点上处理完毕，记录该请求在该阶段该节点的endTime_{NodeId-ServiceLevel}，并且记录父节点ParNodeId＝null。计算出请求在该阶段的节点上的请求处理时间ProcessingTime_{NodeId-ServiceLevel}＝endTime_{N odeId-ServiceLevel}-StartTime_{NodeId-ServiceLevel}。

2)、当通过远程调用将该请求传递到其他节点时，则记录新的处理节点号NodeId和网络延迟C(ParNodeId,NodeId)，并且记录其父节点ParNodeId，分为以下两种情况：

如果只有一个父节点，那么更新该节点对应的请求处理阶段ServiceLevel_NodeId＝ServiceLevel_ParNodeId(父节点所对应的请求处理阶段)+1，然后记录该请求在新节点上的StartTime_{NodeId-ServiceLevel}及endTime_{NodeId-ServiceLevel}，并且可计算出请求在该阶段的该节点上的请求处理时间ProcessingTime_{NodeId-ServiceLev el}＝endTime_{NodeId-ServiceLevel}-StartTime_{NodeId-ServiceLevel}。

如果有多个父节点，查看每个父节点对应的ServiceLevel，选择最大的ServiceLevel，然后在最大的父节点的ServiceLevel值上再加1，并用这个值更新该节点对应的请求处理阶段ServiceLevel。由于存在多个父节点，那么在该节点上会对请求在上一阶段的处理结果进行聚合处理，而且会等上一阶段的所有处理结果返回后再进行处理，在该聚合节点上的请求处理的开始时间StartTime_{NodeId-ServiceLevel}＝max{endTime_{parNodeId-ServiceLevel}+C(ParNodeId,NodeId)}。计算完毕后，将令StartTime_{NodeId-ServiceLevel}最大的父节点记录到关键路径候选节点的字段Candidate(CriticalPath)上，然后再记录请求处理结束时间endTime_{NodeId-ServiceLevel}，并且可计算出请求在该阶段的该节点上的请求处理时间ProcessingTime_{NodeId-ServiceLevel}＝endTime_{NodeId-ServiceLevel}-StartTime_{NodeId-ServiceLevel}。

3)、依此类推，直到返回该请求的最后结果为止。

在一个实施例中，可将服务请求在传递过程中的相关信息记录在表中。但应理解，本发明并不限定存储该信息的具体形式，可以通过表格保存，也可以通过文件或其他形式保存。

举例来说，对于ServiceType＝1的服务，针对RequestId＝1的请求，假设该请求的传递路径如图3所示，则该服务请求在传递过程中记录的相关信息可如表1(或称请求传递信息表)所示。

表1

第二步：查找服务的关键路径

本领域技术人员应理解，请求关键路径是指服务请求在传递过程中花费时间最长的那条路径。对于记录的每一个请求的相关信息，其对应的请求传递过程中会包括一条或多条关键路径。本发明中，针对在一个时间窗口内的多个请求，可统计每一条请求关键路径出现的次数，并将具有最大次数的请求关键路径定义为该服务的关键路径。

在一个实施例中，查找服务的关键路径包括以下子步骤：

1)、查找请求关键路径。

在一个实施例中，根据所记录的请求在传递过程中的相关信息，可构建出请求的传递路径图，通过相关的图算法(如关键路径算法)可找到该请求的关键路径。

在另一个实施例中，可查找上述请求传递信息表，例如，ServiceType＝1且RequestId＝1的请求传递信息表。从最后一个处理阶段ServiceLevel＝5，找到该处理阶段上01节点对应的关键路径候选节点04；继续查找ServiceLeve＝4阶段上节点号Nodeid为04的节点，其对应的关键路径候选节点为09；同理，查找3阶段上的09节点所对应的关键路径候选节点，此时关键路径候选节点字段为空，那么可结束查找请求的关键路径，得到ServiceType＝1且RequestId＝1的关键路径01-04-09。

2)、获得服务的关键路径。

设置时间窗口TW，统计对于一种服务所有的请求关键路径在时间窗口TW中出现的次数Count_{Critical Path}，将出现次数最多的请求关键路径确定为服务的关键路径。

在一个实施例中，设置时间窗口为TW，在TW时间内，对ServiceType＝1的所有请求，查找每个请求的请求关键路径，若每找出一条新的请求关键路径，就将其记录到请求关键路径频次表中，同时将该请求关键路径的次数Count_{Critical Path}设置为1；若找出了请求关键路径频次表中已有的请求关键路径，就只将该请求关键路径的次数Count_{Critical Path}加1。最后，将Count_{Criti cal Path}最大的请求关键路径作为该服务的关键路径。

举例来说，如果设时间窗口为TW＝6小时，且统计的请求关键路径频次表如表2所示，从表2可见，ServiceType＝1的服务的关键路径为01-04-09。

表2

关键路径	CountCritical Path
		01-04-09	703
01-02-06	106
		01-02-07	191

本领域技术人员应理解，以上查找服务的关键路径适用于划分/聚合模式，而对于串行/依赖模式来说，由于该模式下的请求只有一条传递路径，所以无需查找服务的关键路径，该传递路径就是服务的关键路径。

第三步：定位瓶颈节点

在已获得的服务的关键路径上，找出延迟波动最大的节点，将其作为瓶颈节点。在一个实施例中，定位瓶颈节点包括以下子步骤：

1)、针对服务类型为ServiceType的服务，根据所记录的该服务的关键路径上节点的请求处理时间ProcessingTime，统计节点在其处理阶段的请求处理时间ProcessingTime的均值，计算公式如下：

$E\left(\mathrm{Proces}\sin \mathrm{gTime}\right)=\left({\mathrm{\Σ}}_{i=1}^n\mathrm{Proces}\sin \mathrm{gTim}{e}_i\right)/n---\left(1\right)$

其中，n表示某服务在服务阶段ServiceLevel在NodeID节点上的请求个数；i表示第i个请求；Pr oces sin gTime _i表示第i个请求在服务阶段ServiceLevel在NodeID节点上的处理时间。

2)、根据延迟波动公式计算请求在节点上的延迟波动值，其中延迟波动公式表示如下：

$\mathrm{flux}\left(\mathrm{Proces}\sin \mathrm{gTme}\right)=\frac{{\mathrm{\Σ}}_{j=1}^m(\mathrm{Proces}\sin {\mathrm{gTime}}_j-E\left(\mathrm{Proces}\sin \mathrm{gTime}\right))}{m}---\left(2\right)$

其中，m表示在阶段ServiceLevel上NodeID节点的请求处理时间不小于请求处理时间均值的请求个数；ProcessingTime_j表示第j个请求的请求处理时间，并且ProcessingTime_j≥E(ProcessingTime)。

参考图4，flux(ProcessingTime)的直观意义是超过请求处理时间均值的请求处理时间与请求处理时间均值之间的距离的平均值，在某节点上，如果上述延迟波动值越大，表明超过请求处理时间均值的请求处理时间与请求处理时间均值之间的差距越大，因此请求的延迟也就越大。此外，如果某个节点上的flux(ProcessingTime)特别大，那么还表示有一些请求的处理时间特别长，可能预示着这个节点将要失效或已经失效。因此，将上述延迟波动值最大的节点视为瓶颈节点。

例如，在服务关键路径01-04-09上，通过延迟波动公式计算出的各阶段节点上的延迟波动值如表3所示，从表3中可看到第3阶段的节点09上的延迟波动值最大，因此将节点09看做瓶颈节点。

表3

NodeId	ServiceLevel	E(ProcessingTime)	flux(ProcessingTime)
				01	1	20.05	4.08
04	2	15.38	9.44
				09	3	82.51	32.16
04	4	42.91	27.02
				01	5	13.23	11.20

根据本发明的一个实施例，还提供一种分布式环境下保障应用服务质量的方法。

仍参考图1，该方法包括：

第一步：判断服务是否存在长尾延迟

在本步骤中，可采用本领域公知的方法来判断每一个服务是否存在长尾延迟。在一个实施例中，该判断过程包括以下子步骤：

1)、获取要判断的服务的服务类型号。

2)、统计该服务请求(即对该服务的请求)的响应时间的历史数据，得到该服务请求的响应时间的累积分布函数CDF(ResponseTimeServiceType)。例如，每一个处理阶段上请求响应时间的累积分布函数可表示如下：

$P(d\left(R_i\right)\&le;d_i)={F_R}_i\left(d_i\right)={\&Integral;}_0^{d_i}f\left(R_i\right)d{R}_i(0<R_i<d_i)---\left(3\right)$

其中，d_i表示每一处理阶段上可容忍的最大响应时间，也可看作每一阶段的Deadline_i，近似可看作d_i≈E(R_i)；R_i表示第i个请求的请求处理时间；P(f)R_i)≤d_i)表示每一处理阶段上，应用的请求处理时间不大于每一阶段Deadline_i的概率。

图2(a)和2(b)分别描述了Memcached服务请求在不同情况下的响应时间的累积分布函数，其中图2(a)示出了不存在应用混布情况的响应时间的累积分布函数，图2(b)示出了存在应用混布情况的响应时间的累积分布函数。

3)、设置该服务请求的预期响应时间Deadline。

4)、如果服务请求的响应时间超过Deadline的累积分布函数值大于预先设定的阈值Threshold，即CDF(服务请求的响应时间>Deadline)>Threshold，则认为该服务存在长尾延迟。

举例说明，如果设置Deadline＝200ms，Threshold＝2％，如果CDF(服务请求的响应时间<＝200ms)＝97.7％，即CDF(服务请求的响应时间>200ms)＝1-97.7％＝2.3％，其中2.3％>2％，那么认为该服务存在长尾延迟。

第二步：定位瓶颈节点

对于存在长尾延迟的服务，使用上述分布式环境下定位瓶颈节点的方法得到瓶颈节点；

第三步：保障应用服务质量。

在第二步中，找出瓶颈节点后，检查该瓶颈节点对应的延迟波动值是否超过预先定义的波动阈值Threshold(Flux)；如果超过，则可以启动故障诊断方案，检查该瓶颈节点是否出现故障或者即将失效；如果不超过，则可以进行请求加速或调度，从而降低服务请求的长尾延迟。

在一个实施例中，可采用基于Deadline的请求优先级调度在瓶颈节点进行请求调度，包括以下子步骤：

1)、为服务请求分配服务响应时间约束deadline，将服务响应时间约束信息附加到请求中，如Request(data,deadline)。

2)、为瓶颈节点上的请求更新deadline信息，对请求的处理顺序进行调整，优先处理紧急请求(其中，根据计算出来的请求优先级来定义紧急请求，某个请求的请求优先级的数值越大，表明该请求越紧急)，以降低该节点上请求处理时间的波动。在一个实施例中，可以设置更新的deadline＝deadline-StartTime_{NodeId-ServiceLevel}，请求优先级＝1-更新的deadline/deadline。

例如，设置某类服务请求的响应时间约束deadline＝200ms，在瓶颈节点09上，可根据不同请求到达该节点的StartTime更新deadline信息并计算请求优先级，假设RequestId为1、2、3的请求的请求优先级如表4所示，那么就可按照2-3-1的优先级顺序进行调度。

表4

RequestId	StartTime	更新的deadline	请求优先级(1-更新的deadline/deadline)
				1	40	160＝(200-40)	0.2＝(1-160/200)
2	55	145＝(200-145)	0.275＝(1-145/200)
				3	50	150＝(200-50)	0.25＝(1-150/200)

在一个实施例中，在执行完第三步后，返回第一步重新定位瓶颈节点。如果找到新的瓶颈节点，则可以在新的瓶颈节点上进行请求调度或加速。

根据本发明的一个实施例，还提供一种分布式环境下保障应用服务质量的系统，其包括分布式环境下定位瓶颈节点的装置。

分布式环境下定位瓶颈节点的装置包括请求跟踪设备、关键路径查找设备和瓶颈节点定位设备。其中，请求跟踪设备用于为新服务分配服务类型号ServiceType，并且用于记录服务请求在传递过程中的相关信息。关键路径查找设备用于查找服务的关键路径。瓶颈节点定位设备用于在已经找到的服务的关键路径上找出延迟波动最大的节点，将其看作瓶颈节点。

分布式环境下保障应用服务质量的系统还包括请求调度/加速设备，用于对服务的关键路径上瓶颈节点上的请求进行加速或调度。分布式环境下保障应用服务质量的系统还包括长尾延迟判定设备，用于判断服务是否存在长尾延迟。

图5描述了该系统中各设备的操作流程，具体操作步骤参见上文结合图1的描述。

应当理解，虽然本说明书是按照各个实施例描述的，但并非每个实施例仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

以上所述仅为本发明示意性的具体实施方式，并非用以限定本发明的范围。任何本领域的技术人员，在不脱离本发明的构思和原则的前提下所作的等同变化、修改与结合，均应属于本发明保护的范围。

Claims (17)

1.一种分布式环境下定位瓶颈节点的方法，其中，节点是在分布式环境下划分应用服务得到的在一个或多个处理阶段处理请求的服务模块，所述方法包括：

步骤1)、计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的；

步骤2)、根据延迟波动值确定瓶颈节点。

2.根据权利要求1所述的方法，其中，采用下式计算节点在其处理阶段的延迟波动值：

$\mathrm{flux}\left(\mathrm{Proces}\sin \mathrm{gTime}\right)=\frac{{\mathrm{\&Sigma;}}_{j=1}^m(\mathrm{Proces}\sin \mathrm{gTim}{e}_j-E\left(\mathrm{Proces}\sin \mathrm{gTime}\right))}{m}$

其中，m表示一段时间内该节点在其处理阶段处理请求的时间不小于其处理请求时间均值E(ProcessinTime)的请求个数；ProcessinTime_j表示该节点在其处理阶段处理请求j的时间；并且 $E\left(\mathrm{Proces}\sin \mathrm{gTime}\right)=\left({\mathrm{\&Sigma;}}_{i=1}^m\mathrm{Proces}\sin \mathrm{gTim}{e}_i\right)/n,$ 其中，n表示一段时间内该节点在其处理阶段处理的请求个数。

3.根据权利要求1或2所述的方法，其中，对于服务间采用划分/聚合模式，步骤1)还包括：

查找服务的关键路径。

4.根据权利要求3所述的方法，其中，查找服务的关键路径包括：

对于一段时间内对该服务的每个请求，查找处理该请求的关键路径，从而得到每个请求对应的一个或多个关键路径；

在预定的时间窗口内，将出现次数最多的关键路径作为该服务的关键路径。

5.根据权利要求1或2所述的方法，其中，步骤1)还包括：

记录一段时间内对服务的请求的相关信息。

6.根据权利要求5所述的方法，其中，对服务的请求的相关信息包括：

处理阶段，以及在该处理阶段在节点上处理该请求的开始时间和完成时间。

7.根据权利要求6所述的方法，其中，对服务的请求的相关信息还包括：

使当前节点处理该请求的开始时间最大的前一个处理阶段的节点。

8.根据权利要求7所述的方法，其中，步骤1)还包括根据所记录的使节点处理该请求的开始时间最大的前一个处理阶段的节点的信息，得到该请求对应的关键路径。

9.一种分布式环境下定位瓶颈节点的装置，其中，节点是在分布式环境下划分应用服务得到的在一个或多个处理阶段处理请求的服务模块，所述装置包括：

瓶颈节点定位设备，用于计算服务的关键路径上的每个节点在其处理阶段的延迟波动值；以及用于根据延迟波动值确定瓶颈节点；

其中，服务的关键路径是根据一段时间内处理对该服务的请求的关键路径得到的；延迟波动值是根据一段时间内节点在其处理阶段处理请求的时间得到的。

10.根据权利要求9所述的装置，还包括：

关键路径查找设备，用于查找服务的关键路径。

11.根据权利要求9或10所述的装置，还包括：

请求跟踪设备，用于记录一段时间内对服务的请求的相关信息。

12.一种分布式环境下保障应用服务质量的方法，包括：

步骤A)、对于存在长尾延迟的服务，采用如权利要求1-8中任何一个所述的方法定位瓶颈节点；

步骤B)、检查瓶颈节点的延迟波动值是否超过预定阈值；如果超过则对该瓶颈节点执行故障诊断，如果不超过则对该瓶颈节点的服务请求执行请求调度或加速。

13.根据权利要求12所述的方法，其中，步骤A)还包括：

对于每一个服务，判断该服务是否存在长尾延迟。

14.根据权利要求13所述的方法，其中，根据以下步骤判断服务是否存在长尾延迟：

根据对该服务的请求的响应时间的历史数据，得到服务请求的响应时间的累积分布函数；

如果响应时间大于预期响应时间的累积分布函数值大于预定阈值，则认为该服务存在长尾延迟。

15.根据权利要求12所述的方法，其中，在执行步骤B)后返回步骤A)。

16.一种分布式环境下保障应用服务质量的系统，包括：

如权利要求9-11中任何一个所述的分布式环境下定位瓶颈节点的装置；以及

请求调度/加速设备，用于对瓶颈节点的服务请求执行请求调度或加速。

17.根据权利要求16所述的系统，还包括：

长尾延迟判定设备，用于对于每一个服务判断该服务是否存在长尾延迟。