云计算环境下服务故障传播路径判别方法

姒鉴哲，姜 瑛，李荣宸，陈威伟

1.云南省计算机技术应用重点实验室，昆明 650500

2.昆明理工大学 信息工程与自动化学院，昆明 650500

云计算是一种在并行计算、分布式计算等技术的基础上发展而来的计算模式[1]，而服务则是面向云计算环境中承载各项资源及使用模式和能力交付的重要手段。目前，在电子商务、社交网络、互联网金融等领域，在线的服务已构成了人们日常工作、生活中的重要部分。随着云计算技术的不断发展，越来越多的服务开始走向云端[2]，为产业带来了更多发展的可能性和创造性。相较于传统的计算机系统，云计算环境具备开放性、复杂性、不可预测性等特点，其上部署服务及服务组件众多且交互关系复杂，将增加服务发生故障的概率[3]，如果故障随着服务间的持续交互进行传播扩散，将出现更多隐患。

近年来，亚马逊、阿里云等多家云计算服务先后因为出现了故障，故障持续传播后致使威胁用户数据安全、服务大规模失效、严重影响服务运行质量的事件发生[4]，给云计算环境下服务产业带来了极大的挑战。因此，针对云计算环境中运行服务，在故障发生时需要明确发生故障的服务，将其作为问题根源，及时对该故障带来的负面影响进行分析，合理根据故障传播的趋势判别服务故障传播路径，协助相关人员高效有序地对故障进行处理，遏制故障在云计算环境中的持续传播，从而保障服务高质量运行，避免造成更大损失。

1 相关工作

故障传播影响分析在近年得到了广泛发展，在面向服务的架构中，唐伦等人[4]根据网络虚拟化环境下故障的多层传播关系，构建故障与症状的依赖图模型，引入深度信念网络进行提取，利用故障传播的时间相关性，使用动态贝叶斯网络对故障根源进行实时诊断。王焘等人[5]提出了一种面向异常传播的微服务故障诊断方法，首先建立服务依赖图；然后，基于回归分析构建度量与API调用之间的回归模型以检测异常微服务，基于服务依赖图以及异常服务集合得到故障传播分析结果。薛利兴等人[6]提出网络化软件系统故障传播分析与可靠性评估，构件执行过程、构件之间的交互过程，基于马尔可夫链建立软件故障传播性模型，进行故障分析。LIN等人[7]通过抓取服务间网络传输的数据信息用以获取服务调用关系，当服务调用延迟脱离服务水平目标范围，则检测为异常，通过分析服务依赖关系进行传播分析推断引发异常的潜在原因。针对软件资源与任务联系的故障传播与扩散问题，王友俊等人[8]提出一种基于超图的Cyber空间故障传播研究方法，利用Petri网建立关系模型，通过传播能力、传播系数、扩散系数等指标来描述故障的传播过程，采用邻接矩阵分析并推导出指标量化方法，给出故障在Petri网中产生的影响力函数，分析故障扩散路径。

面向复杂系统研究领域，何俊秀等人[9]提出一种基于体系结构的软件故障传播模型，在软件体系结构建模的基础上，考虑组件信号间故障传播效应，通过引入组件容错率和失效率的概念，构建组件状态转移矩阵对信号在软件模块中的故障传播现象建立模型。尹进田等人[10]提出一种基于故障传播与因果关系的故障溯源方法，通过建立体现时空特性的系统故障传播模型，利用因果关系技术判定不同观测点信号间的因果关系，进行故障传播分析。Sun等人[1]提出一种基于高斯贝叶斯网络的故障传播路径识别推理算法，针对工业系统背景下建立的高斯贝叶斯网络中特定故障节点，根据参数权重和值的波动确定父节点，基于条件概率和二分法的分解，进行最大条件概率的估计逐层追踪到网络中的故障传播路径。王林等人[11]提出一种考虑父节点影响的贝叶斯网络故障路径追溯算法，通过构建贝叶斯网络，计算贝叶斯网络中故障子节点的最大条件分布值，然后与真实观测值比较进行故障传播分析，最终在工业系统中得以应用。

对上述相关文献进行分析，以上故障传播影响分析方法均取得了重大技术进步，但仍存在以下局限性：

（1）过多关注历史数据，与故障发生时的实际情况存在偏差，致使方法效果受到限制。尽管历史数据具备重要参考意义，但过度依赖其进行判断易偏离服务实际运行状况，文献[1，6，8-9，11]这些方法过多关注历史数据，而历史数据往往只能体现在某一特定时间段内所蕴含的特征规律且所包含信息并不能对可能发生的状况进行完整覆盖致使方法的准确率受到限制，另外通过大量的历史数据进行分析，往往需要较长时间进行预处理分析，从而使得方法的效率受到影响[6]。

（2）仅考虑单一因素衡量故障的传播影响，造成部分关键因素缺失，导致方法分析存在不足。文献[5，7，10]方法在一定程度上简化了计算复杂度，提高了计算效率，但文献[5]依据服务在整个依赖图中的被调用次数作为故障传播影响力，缺乏对实际服务运行状况、服务间的局部相关关系的分析致使方法存在缺陷；文献[7]仅依赖服务调用延迟时长判定服务异常推断服务故障传播影响，文献[10]仅依赖服务间信号判断组件间的因果关系，忽略了大量有效的可观测信息。例如处在同一运行环境和不同环境下运行的服务受故障影响程度不同、路径上服务的运行状况存在差异性、节点自身属性、吞吐量不同等。调用延迟时长蕴含信息有限，会造成大量故障影响要素缺失从而致使故障传播影响分析准确率不高。

（3）无法适用动态变更的系统结构进行故障传播分析。例如文献[4，11]所需依赖有向无环图构建贝叶斯网络，文献[6]方法的应用需针对系统自身固有拓扑，而云计算环境下服务运行较为复杂且无定式，服务的运行状态、服务间的关系也在持续变更，难以保障满足方法运行条件，因此文献[4，6，11]方法应用在云计算环境中进行服务故障传播分析十分受限。

针对上述故障传播影响分析方法中存在的问题，本文提出了一种云计算环境下服务故障传播路径判别方法，动态建立适用云计算环境的服务交互图；此外，不再重点关注历史数据，分析当前处于运行状态下服务的运行数据、环境数据，确定发生故障的服务，计算服务故障可能性，随后综合分析多种服务故障传播因素计算服务故障传播概率进行服务故障传播路径判别。

2 云计算环境下服务故障传播路径判别方法

在云计算环境中，针对某些目标要求，单个服务往往难以完成，因此需要多个服务交互配合共同完成，这样在服务与服务间就形成了错综复杂的关系，因为服务的运行状态及执行的业务逻辑持续改变，随之致使服务间的关系也是不断变化的，而这样的关系，往往成为了服务故障时故障进行传播的主要途径。同时，服务受故障传播影响至发生故障也是一个持续变化的过程，因此只有明确服务间关系，对服务的服务运行、环境状况持续关注才能对故障传播影响进行合理分析，判别服务故障传播路径，为相关运维人员遏制故障传播态势提供参考依据。

因此，本文依据云计算环境下服务的实际交互情况动态建立服务交互图，在此基础上优化服务交互图结构建立服务关系图，明确服务间关系。后续根据服务的运行、环境状况，在故障发生时，确定发生故障的服务，合理计算服务故障传播概率，有效判别服务故障传播路径。服务故障传播路径判别方法的流程图如图1所示。

图1 服务故障传播路径判别方法的流程图Fig.1 Process of method for discriminating service failure propagation path

2.1 服务交互图的动态建立

当服务发生故障时，故障可能通过服务与服务间的交互连接作为媒介在云计算环境中不断传播，进而致使更多的服务发生故障，导致批量服务失效。因此，明确云计算环境下服务的实际交互情况对于判别服务故障传播路径十分重要，此外云计算环境下服务众多、交互频繁，而图结构能较好地表现这样的复杂状况。为了建立后续判别服务故障传播路径的基础，本节依据服务云计算环境下服务交互状况动态建立服务交互图（service interaction diagram，SID），定义如下：

定义1服务交互图是一个描述服务间交互状况的有向图，表示为一个四元组SID={V,E,S,N}，V={v1,v2,…,vi}，E={＜v1,v2＞,＜v2,v1＞,…,＜vi,vj＞}，S={s1,s2,…,vm}，N={n1,n2,…,nm}。服务交互图具备反自反性，∀v∈V，有＜vi,vi＞∉E。

其中，V表示有穷非空的服务节点集合，包含当前云计算环境中正在运行的全部服务；E是边集，即服务间交互连接集合；S为对应服务间交互关系的状态标记集合，集合中元素s={Running||End}表示不同交互连接具有的正在执行或完成状态；N为对应服务间交互连接的服务交互编号集合，集合中的每一元素作为指定交互连接的唯一标识。

服务交互图可以准确描述服务运行过程中的数据流向、交互状态及服务之间的交互关系，服务交互图建立算法描述如算法1所示。

算法1服务交互图建立算法

服务交互图建立算法的时间复杂度为O(m+sn/2)。其中，m为系统中服务个数，s为处于正在运行状态服务个数，n表示服务交互图中包含的交互连接个数。

在云计算环境下，建立的服务交互图不可能是一成不变的，随着时间的推移，一些已有的交互连接状态在不断发生改变，一些新的交互连接也仍在产生。本节通过持续监测服务运行数据，获取最新服务运行状态，进而以算法1中所述算法变更交互连接的执行状态标记和增补交互连接，实现服务交互图的动态更新。

依照算法1构建服务交互图示例见图2。图中圆形表示服务个体，线条起始为服务的使用者，箭头指向为被使用服务，虚线代表该交互已经结束，实线表示该交互正在进行，边上数值为服务交互编号标识。

图2 服务交互图示例Fig.2 Example of service interaction diagram

2.2 服务关系图的建立

云计算环境中，随着时间的推移，运行的服务数量愈渐增加，服务与服务间的交互不断多样，服务的运行状态瞬息万变，从而使得服务交互图结构十分复杂，在故障发生时，使用服务交互图进行服务故障路径判别将增加系统资源占用，降低服务故障路径判别的效率，削弱方法整体的有效性。因此本节在2.1节服务交互图的基础上，为了保留服务交互图中的交互信息，通过统计相同服务间的交互频次，以达到优化服务交互图结构，提升故障发生时，服务故障传播路径判别效率为目的，建立了服务关系图（service relationship diagram，SRD），服务关系图定义如下：

定义2服务关系图是一个在服务交互图的基础上描述服务间相关关系的有向图，将服务关系图描述为一个三元组SRD={A,R,W}，A={a1,a2,…,ax}，R={＜a1,a2＞,＜a2,a1＞,…,＜ax,ay＞}，W={w1,w2,…,wx}。服务关系图具备反自反性，∀a∈A，有＜ax,ax＞∉R。其中A表示服务交互图中包含的所有服务；R为服务间的关系集合；W为描述服务间关系上交互频次的集合。

服务关系图建立算法如算法2所示。

算法2服务关系图建立算法

服务关系图建立算法的时间复杂度为O(en)。其中e为服务交互图中包含的服务个数，n为服务交互图中服务的平均出度。

算法2首先对已产生的服务交互图进行遍历，依据服务交互图中表述相同服务间的服务交互连接进行统计，实现服务关系图的建立，依照算法2所述服务关系图建立算法构建服务关系图示例如图3所示。

图3 服务关系图示例Fig.3 Example of service relation diagram

图中圆形表示服务个体，线条起始为服务的使用者，箭头指向为被使用服务，边上数值为线条起始服务对箭头后服务的交互频次。

2.3 确定发生故障的服务

在云计算环境下服务发生故障，若要针对故障进行传播影响分析，合理判别故障传播路径，首要任务是确定发生故障的服务。

通常服务故障的表现形式往往可以通过服务产生的运行数据波动映射出来，但由于云计算环境下复杂的服务运行特性，服务与服务间的关系错综交织，在分布式云计算的技术背景下存在着多个服务共同部署于同一物理设备或虚拟节点上，这样无疑使得确定发生故障的服务、计算服务故障可能性不仅需要考虑服务运行数据，还需要对服务运行时的环境数据来综合分析。

在进行确定发生故障的服务时，一些常用的故障检测方法，如文献[12]通过改进粒子群算法优化的支持向量机算法进行故障检测，文献[13]通过模糊C均值聚类与K近邻算法进行故障检测仅能利用获取数据判断当前目标对象是否发生故障，无法针对服务运行处于正常与故障的中间状态进行描述。采用均值检验方法除可以确定发生故障的服务外，还可以清晰地依据服务的运行数据与服务环境数据反映其余服务当前不同运行状况。

均值检验方法采用ADF检验方法[14]检验服务正常运行状态下采集的批量服务运行数据与环境数据平稳性，确保实验数据样本整体符合服务正常运行时的数据特征。随后通过抽取少部分实验数据样本和当前获取的服务运行、环境数据分别同实验数据样本整体执行t检验[14]后求均值进行对比分析服务当前运行、环境状态与服务正常运行、环境状态时的偏离程度。通过主成分分析[15]从服务运行状态、服务环境状态对服务故障发生可能性进行影响贡献确定，将其作为权重分配，以获得最终服务故障可能性结果。

本节通过均值检验方法进行服务故障可能性计算，如算法3所示。

算法3服务故障可能性算法

其中，ADF检验（augmented dickey-Fuller test）为数据集平稳性检验方法，原理为判断服务监测指标数据是否存在单位根，若指标数据平稳，就不存在单位根；反之，则存在单位根[14]；t检验（student’s t test）为用t分布理论来推论服务故障发生的概率，比较两个平均数的差异度，t检验统计量为：

其中，n为样本数，Xˉ为样本平均数，σx为样本标准偏差[14]；主成分分析（principal component analysis，PCA），是一种统计方法。通过正交变换将一组可能存在相关性的变量转换为一组线性不相关的变量，通过这些变量不同程度地反映了针对问题的信息，在数学建模中最常用它来求各项指标对整体的影响的贡献率[15]。

算法3的时间复杂度为O(nf(ADFR)+nf(ADFE)+2nf(tR)+2nf(tE)+f(PCA)），其中n为处于正在运行状态下的服务个数，f(ADFR)为ADF检验服务运行数据的时间复杂度，f(ADFE)为ADF检验服务环境数据的时间复杂度，f(tR)为t检验服务运行数据的时间复杂度，f(tE)为t检验服务环境数据的时间复杂度，f(PCA)为PCA算法的时间复杂度。

此外，为了衡量服务故障可能性，有效确定发生故障服务，本节通过正常与故障时的服务运行及环境数据的表现设定阈值估计值，当计算所得服务故障可能性大于设定阈值估计值时则将该服务确定为故障服务，否则记录该服务的故障可能性。

通过上述方法获取确定发生故障的服务并获取服务关系图中除故障服务外服务的故障可能性，在图3的基础上结合服务运行数据、服务环境数据计算服务故障可能性结果示例如下：

t0时刻，ServiceA故障可能性为0.31，ServiceB故障可能性为0.46，ServiceC故障可能性为0.27，ServiceD故障可能性为0.83，设定阈值估计值为0.8，确定发生故障服务为ServiceD。

2.4 服务故障传播路径判别

当服务发生故障时，故障可能在服务关系图上的服务间不断传播，随之由于故障传播的先后不断进行，逐渐形成故障路径。如果能提前辨别服务故障传播路径，就能及时对故障进行处理，遏制故障在系统中持续蔓延造成大规模服务失效。本节首先在2.2节服务关系图的基础上分析，结合2.3节所得的服务故障可能性，计算服务故障传播概率，最终判别服务故障传播路径。

2.4.1 服务故障传播概率计算

在服务故障发生时，需要多方位考虑服务故障传播影响因素，通过计算服务故障传播概率值，反映故障发生所带来的传播影响，为确定服务故障传播路径提供切实依据。

在计算服务故障传播概率时，除服务故障可能性外，故障传播概率还受其他关系要素影响。从服务角度来看，往往服务与故障服务间交互的局部相关关系紧密程度，同服务故障传播概率呈正相关趋势；其次，从服务关系图整体出发，服务在服务关系图中的全局影响力越大，受故障传播的概率也越大。同时，从业务流程来看，在服务关系图中服务间众多业务流程联系紧密，任一服务交互过程都是整个业务流程中的重要一环，因此在进行服务故障传播概率的计算对服务间的直接与间接交互过程都不容忽视。

本小节通过服务、服务关系图整体、业务流程多角度包含要素，结合2.3节服务故障可能性，引入了SimRank算法计算服务故障传播概率。SimRank是一种基于图结构的相似度计算方法，具有较好的准确性和拓展性，同时基础的SimRank算法表达了如果两个服务的直接交互对象中存在相似性关联，则这两个服务也具备关联关系的思想。因而通过该算法能够较好地挖掘服务间的直接与间接关联关系。但基础的SimRank算法仅使用了服务关系图的结构信息，没有考虑服务关系图中边的信息，同时也缺乏对服务在服务关系图中的影响差异性的考量。因此，本小节在基础的SimRank算法[16]上进行加权，提出一种适用云计算环境下基于服务关系图的服务相似度计算方法称为WsimRank（weighted SimRank）并结合服务故障可能性计算服务故障传播概率，计算方法具体如下：

首先，设置权重计算公式如式（4）所示：

其中，KIi(Vt)表示服务t的第i个邻居服务在服务关系图中的共计交互频次，KIi(Vt)→Vt为服务t的第i个邻居节点与服务进行的交互频次，KGraph表示服务关系图中包含所有服务的共计交互频次。

其次，为使方法计算结果收敛，本节对权值计算结果进行标准化处理，具体计算方式如式（5）所示：

其中，w(Ii(Vt)→Vt)表示服务t的第i个邻居服务与服务t的权值表示服务t的i个邻居节点与服务t的权值之和。获取了标准化权值后，对基础SimRank算法公式进行加权，计算服务间相似度如式（6）所示，式（6）需设置迭代次数，以达到不断深入挖掘服务与服务间的间接交互信息，具体设置次数可依据服务关系图的大小而定。

其中，C为阻尼系数，Va表示服务a，Ii(Va)表示服务a的第i个邻居服务为服务a的第i个邻居节点与服务a的标准化权值，由此获得服务间相似度计算结果。

依据式（6）计算结果，结合服务故障可能性进行综合分析，给出服务故障传播概率公式如式（7）所示：

其中k为2.3节服务故障可能性计算结果。

上述方法的时间复杂度为O(td2n2)，其中t表示迭代次数，d表示服务关系图上服务的平均度数，n表示服务关系图中服务的个数。通过上述方法，完成了对服务局部相关关系、服务关系图整体、业务流程多个角度包含要素的分析，同时综合考量表征服务实际运行情况的服务故障可能性，获得服务故障传播概率。

2.4.2 服务故障传播路径确定

进行服务故障传播路径的确定，必须准确地对服务故障传播顺序与传播范围进行界定，才能为相关人员最大限度地降低损失提供依据。同时因为服务故障传播具有双向性，本节依据2.2节获取的服务关系图，2.3节确定发生故障的服务，2.4.1小节计算的服务故障传播概率，以确定发生故障的服务为路径起点，从该故障服务前驱、后继方向同时对与发生故障的服务直接或间接交互的服务进行分析，不断完善服务故障传播路径。当下一跳节点服务未存在前驱节点服务或后继节点服务时或下一跳节点服务在当前路径中已存在时或下一跳节点服务被故障传播概率不显著时，结束本条路径确定，最终可获得以确定发生故障的服务为起点的一条或多条服务故障传播路径。服务故障传播路径确定算法如算法4所示。

算法4服务故障传播路径确定算法

算法4的时间复杂度为O(2nfl)，其中n为服务关系图中包含服务个数，f为确定发生故障服务的个数，l为服务故障传播路径的平均路径长度。

通过上述算法过程，依照图3示例服务关系图、2.3节实例给出t0时刻确定发生故障服务结果，通过2.4.1节服务故障传播概率计算方法，所得服务故障传播路径确定结果示例如下：确定发生故障的服务为ServiceD；从后继方向确定服务故障传播路径为故障服务ServiceD传播至ServiceB传播概率为69%，再至ServiceA传播概率为37%；确定服务故障传播前驱方向路径为故障服务ServiceD传播至ServiceB传播概率为69%，再至ServiceC传播概率为26%。

依据确定的服务故障传播路径可以协助相关管理人员针对故障发生及时做出反应，避免故障进一步传播扩散。

3 实验及分析

本文搭建了基于OpenStack的弹性云计算平台，并于平台上搭建基于Hadoop2.7的并发计算框架，使用Java语言开发了8个服务，8个服务具备任意两两进行交互的能力，可以通过驱动程序自动生成若干服务交互序列，仿真实际环境中服务的多种行为和状态。服务概况如表1所示。

表1 服务概况表Table 1 Overview of services

通过开发服务数据监测的原型软件用于采集、存储服务的运行、环境数据，采集的服务运行数据属性及含义如表2所示。

表2 服务运行数据属性表Table 2 Monitored data items for service operation

采集的服务环境数据属性及含义如表3所示。

表3 服务环境数据属性表Table 3 Monitored data items for service operating environment

3.1 确定发生故障的服务对比实验

本次实验以资源消耗的故障注入手段，获取云计算环境下部署的8个服务的运行数据89 143条，对应环境数据64 860条，其中包含故障注入时获取运行数据76 748条，对应环境数据58 679条。为了验证本文方法的有效性，设置以下实验：（1）文献[12]所述方法仅使用服务运行数据进行确定发生故障的服务的实验；（2）文献[13]所述方法仅使用服务运行数据进行确定发生故障的服务的实验；（3）以本文所述方法仅采用服务运行数据进行确定发生故障的服务的实验；（4）以本文所述方法使用服务运行数据、服务环境数据进行实验，同（1）（2）（3）获得的实验结果进行比对，确定发生故障的服务对比实验输入数据如表4所示。

表4 确定发生故障的服务对比实验输入数据Table 4 Comparison for input data scale

本次实验以确定发生故障服务准确率、运行时长验证本文方法的有效性，并给出准确率计算公式如式（8）所示：

其中，TP为正确识别的故障样本数，TN为正确识别的非故障样本数，SN为方法所进行识别的总样本数。

运行时长，即自输入数据至方法完成计算并输出结果所损耗时间总和，本次实验结果如表5所示。

表5 确定发生故障的服务对比实验结果Table 5 Comparison for service fault detection

通过表5可以看出，仅使用服务运行数据进行实验时，同文献[12-13]对比，本文方法准确率表现上优于文献[12-13]所述方法，运行时长略低于文献[12]所述方法，但较文献[13]方法具备一定优势。分析实验结果，文献[12]、文献[13]方法依据数据进行分析，都需要通过数据分布状况，确定发生故障的服务，在实验结果上均取得了一定效果。但文献[12]采用的粒子群优化算法与文献[13]的模糊C均值聚类与K近邻算法进行故障检测时，均会随着时间的推移，故障类型的不断扩充，数据特征分布杂乱而致使结果准确率受到影响。此外，文献[12-13]方法均只能就当前服务运行数据对服务进行是否发生故障的二元判断，未能对运行时服务运行时介于正常与故障之间的中间状态进行准确评估。本文方法以服务运行正常数据为基准，通过后续获取的服务数据偏离量同基准值对比，不仅不会受到因为故障类型的变化而影响检测效果，还能依据数据偏移量计算的服务故障可能性可以有效反映环境中的运行时服务状况，但本文除确定发生故障的服务结果外，增加了故障可能性计算，在效率上受到一定影响。

后续利用本文方法，使用服务运行数据、服务环境数据进行确定发生故障的服务实验时，较仅添加服务运行数据的本文方法与文献[12-13]方法，在准确率表现上获得了明显提升。添加服务环境数据进行分析，虽然在一定程度上增加了处理的数据量和时间开销，但使得同一环境下服务运行状况及环境带来的影响在数据上得到了更准确的捕获与体现。

综上所述，本文方法能有效确定发生故障的服务，并根据未发生的故障服务的实际运行情况，计算服务故障可能性，为后续判别服务故障传播路径提供了必要条件。

3.2 服务故障传播路径判别对比实验

本次实验通过驱动程序仿真实际应用场景动态生成多个服务交互序列。单个服务交互序列运行时长预估为1 000 s，首先设置由4个服务同时参与，依照动态生成的服务交互序列连续运行30 h，选择1个服务进行故障注入，观察服务故障传播情况；再次设置由8个服务同时参与，依照动态生成的服务交互序列连续运行30 h，选择3个服务进行故障注入，观察服务故障传播情况。针对服务运行数据与环境数据，以5 s为周期进行监测，后续刷新确定发生故障的服务，更新服务故障传播路径。

本次实验设置两组对照实验，两组对照实验均采用首次确定所得服务故障传播路径时开始进行校验，设置滑动时间窗口为500 s，即确定所得服务故障传播路径的时间为起点，向后延长500 s的范围内，依据方法分析的服务故障传播影响结果同实际故障服务发生情况进行比对。此外，为保证实验结果不受服务交互序列动态变更而致使方法判别条件前后不一致的状况影响，当滑动时间窗口内服务交互序列不一致时产生的判断结果不纳入实验最终结果。

第一组对照实验设置了方法进行故障传播影响分析结果准确率与故障传播影响分析过程中方法运行时长两个指标，对本文方法实验结果同文献[5]中提出的基于特征向量中心度的PageRank故障传播影响分析方法实验结果进行评价。故障传播分析结果准确率计算公式如式（9）所示：

其中，ServiceTP表示单次结果分析正确，即通过单次运行方法所得受故障传播影响的服务集合在时间窗口内均发生故障，与服务实际运行状况吻合，∑ServiceTP表示结果分析正确总数，∑ResultSN表示进行故障传播影响分析结果总数。

运行时长则为方法完成对所有的采集信息进行服务故障传播影响分析的总计消耗时长。

通过上述指标分别对实验方法进行评价，结果如表6所示。

表6 服务故障传播路径判别对比实验结果Table 6 Comparison for service failure propagation path discrimination

从表6可以看出，本文方法在准确率、运行时长上结果更优于文献[5]方法。原因分析为文献[5]采用基于特征向量中心性方法改进的PageRank算法进行故障传播分析时认为某个服务被调用的次数越多用则该微服务的重要程度越高，发生故障时对整个故障传播图的影响也越大[5]，缺乏对服务间的局部相关关系的紧密程度与服务间间接交互过程的分析且在进行故障传播分析时并未考量服务运行的实际状态，致使方法准确率受限。

在运行时长上，文献[5]方法依据服务依赖图，需对图中的每一个服务结合其被调用连接进行故障传播分析，不断计算用于建立服务故障传播子图。本文方法通过提出的WsimRank算法，采用优化后的服务关系图且仅针对除故障服务外的其他服务进行传播概率计算，在故障传播分析后仅更新服务故障传播路径，因此本文方法处理运行时长更短，效率更高。

第二组对照实验设置实际服务运行中的路径准确率、运行时长、路径数量三个指标，对本文方法实验结果同文献[8]所提出的故障传播与扩散路径方法的实验结果进行评价，路径准确率计算公式如式（10）所示：

其中，PathTP表示单条服务故障传播路径分析正确，即故障按照传播路径规划的先后顺序依次发生，与服务实际运行状况吻合。∑PathTP表示服务故障传播路径分析正确总数，∑PathSN表示进行分析服务故障传播路径总数。

运行时长为依照服务故障传播路径的不断更新，计算服务故障传播路径数次变更所耗时间总和；路径数量为通过实验时间内，定位的故障传播路径生成总量。

实验结果如表7所示。

表7 服务故障传播路径判别对比实验结果Table 7 Comparison for service failure propagation path discrimination

从表7可以看出，不论是4个服务或8个服务交互下进行实验，两种方法在故障传播路径分析上都取得了一定效果，但本文方法从路径准确率、运行时长及路径数量上优于文献[8]所述方法。原因分析为文献[8]并未区分路径方向，服务与服务间存在连接，即可在路径上连通，这样导致产出服务故障传播路径数量上更繁多，同时路径上节点数量也更多且其间包含大量冗余节点，致使文献[8]判别方法将会存在更多误判。本文方法加入了对服务当前运行、环境状况的分析，使得判别路径更加贴近服务运行的真实情况，同时，因为对路径上服务选取加以前驱、后继方向限制，符合服务实际交互情况，使得本文所得路径数量低于文献[8]方法，准确率也更高。在运行时长方面，本文方法通过结构更优的服务关系图结合对服务故障传播概率表现判断，依次对路径节点进行扩充而文献[8]方法通过多次矩阵运算后不断进行路径扩充且未对路径扩充条件进行设定致使路径到达结构边界才会停止扩充，在路径计算方式更加复杂且耗时。

综上所述，本文方法能有效判别服务故障传播路径，为服务故障传播影响分析问题提供了可行方案，可对保障云计算环境下服务的高质量运行提供支持。

4 结束语

针对云环境下服务故障传播影响分析，现有部分研究仅考虑单一因素衡量故障的传播影响、不适用动态系统结构、过多关注历史数据等，本文提出了一种云计算环境下服务故障传播路径判别方法，首先根据服务实际运行情况动态建立服务交互图，其次为了提高处理效率，在服务交互图的基础上进一步处理，建立服务关系图。在建立服务关系图后，引入均值检验方法，计算服务故障可能性，确定发生故障的服务。最后依据服务关系图，结合服务故障可能性、WsimRank方法，计算服务故障传播概率，通过以故障服务为起点，从前驱、后继两个方向分别判别服务故障传播路径。

实验表明，通过本文方法进行云计算环境下服务故障传播路径判别是有效的，依据本文方法可以协助相关人员准确地就发生故障服务与可能受故障传播影响的服务及时进行处理，避免故障持续扩散，保障云计算环境下服务的高质量运行。但是，本文方法因增加服务环境数据的分析，在一定程度上会降低方法整体的处理效率且结合云计算环境特性，本文方法未能通过采取措施干预故障发生或针对故障发生时对故障进行处理，因此下一步将重点针对服务故障传播路径的判别效率提升、通过方法驱动干预故障发生或对发生的故障进行处理的目标继续研究。