提升云服务可靠性：Web服务组合的应用研究

本章聚焦于运行在云计算平台下、长期运行或计算密集型的应用服务的故障诊断。由于云应用较高的组合本质，软件错误、恶意服务和无效的输入很可能会发生，因此我们提出如图5.2所示的自动化云服务诊断架构。该框架能够提供更多有效的修复策略，能够快速、精确地分析和定位故障节点。

图5.2　云服务诊断架构

这里我们做了一个假设，假设云组合服务的BPEL进程是已知的，并且该进程的执行数据被保存在服务执行日志当中。日志格式要求如下：

（1）服务执行日志形式化地表示为SEL={sel1，sel2，…，selm}，日志由m条记录组成，每条记录seli（1≤i≤m）用于描述组合服务进程的一次执行路径；

（2）每条记录行形式化地表示为seli={service1，service2，…，servicer，result}，每条记录有r个服务组件和一个执行结果组成，执行结果用于描述此次执行是否成功，成功用succ表示，失败用fail表示；

（3）每个服务组件形式化地表示为service（sv.in，sv，sv.out），sv表示一个服务组件本身，sv.in表示sv的输入，sv.out表示sv的输出。

基于上面的假设，我们提出图5.2的云服务诊断架构。我们的诊断架构主要包括以下几部分。

（1）商务进程：一个存在异常的组合服务进程，在进程运行期间抛出了异常警告。

（2）异常处理器：负责捕捉抛出的异常，收集或生成服务执行日志，选择并调用适当的诊断服务。根据诊断服务的诊断结果，异常处理器从修复选择器中获取相对应的修复策略，使得商务进程从故障影响中恢复正常。如果故障节点调用了其他的服务进程，那么该异常处理器还负责触发相对应的服务进程的异常处理器处理该异常。

（3）修复选择器：用于存储诊断策略，根据异常处理器的请求提供恰当的修复策略。它主要由以下3种策略组成：①重试。该策略主要用于再次运行发生故障的行为。每次重试时发生故障的行为最多执行3次，若3次都未成功，则认为修复失败。②替换。该策略主要是使用一个与故障服务具有相同功能的新服务代替故障服务节点来修复故障。③跳过。该策略通过跳过故障节点，运行进程的下一个节点来避免故障发生。

（4）预处理器：当预处理器从异常处理器处接收到诊断请求时，它首先从异常处理器中获取相对应的进程信息，如BPEL文件、服务执行日志；然后分别将获取到的信息转换成服务依赖图和测试用例，用于分析服务依赖关系。(www.xing528.com)

（5）建模器：负责应用相似度系数来度量服务节点与进程故障之间的依赖相似度。

（6）诊断器：应用一个内嵌的模型，使用从建模器处获得的服务节点的依赖相似度来计算并分配一个故障可疑度分数给进程中的每一个服务节点，通过将分数从高到低排序的方式找出前k个可疑的服务节点来定位故障。此外，诊断器还会发送诊断结果给异常处理器，以便异常处理器修复故障。

通过图5.3，我们描述了所提出的诊断架构中服务组件的信息交换过程。假设一个BPEL进程抛出一个异常，且异常处理器捕捉到了该异常。异常处理器首先收集该进程用于故障诊断的进程信息，然后从云诊断平台中选择一个诊断服务并给该诊断服务发送一个诊断请求。当诊断服务的预处理器接收到诊断请求后，预处理器将进程信息转换成形式化的建模信息，并将转换后的信息发送给建模器。建模器应用接收到的信息构建该进程的诊断模型，然后将构建好的诊断模型发送给诊断器。诊断器接收到诊断模型后，应用适当的诊断算法诊断故障并将诊断结果返回给异常处理器。异常处理器则将诊断结果和修复请求发送给修复选择器。修复选择器根据故障类型从策略数据库中选取合适的修复策略返回给异常处理器并将之用于修复进程故障。

图5.3　服务组件间的信息交换过程

在所提出的诊断架构和诊断方法中，我们考虑的主要情况包括如下几方面。

（1）为了使诊断资源在网络上可被共享与重用，诊断架构中的预处理器、建模器和诊断器被从诊断服务中解耦出来。例如，如果一个故障服务进程是通过一种特定语言定义的，那么可以从云诊断平台中找到一个相对应的预处理器服务或定制一个可读取该语言并能将它转换成所需信息格式的预处理服务。同时，仍然使用所提出的架构中的建模器和诊断器完成诊断任务。此外，异常处理器也可根据故障或异常的类型选择具有与该类型故障相对应的诊断机制的诊断服务进行故障诊断。

（2）服务依赖图主要用于从进程规约中抽取进程节点间的数据依赖关系和控制依赖关系。应用该方法可以使进程节点间复杂的、不清晰的依赖关系变得清晰，便于故障的诊断。

（3）由于云环境的复杂性，所提的诊断模型无法考虑到所有故障类型。然而，在进程执行期间，服务执行日志能够被自动化地生成，并且在网络上是可获取的。这些执行日志中包含了服务进程所有的正常执行记录和异常执行记录，因此我们采用服务执行日志作为测试用例，以便能够进行故障的自动诊断。此外，随着进程的不断执行，可以获取到越来越多的诊断信息，这有利于诊断准确性的提高。当可获取的诊断信息量过少时，可以使用异常处理器从云诊断平台中选择合适的诊断服务来进行诊断。

（4）在所提出的诊断模型中，当确定计算得出的最可疑节点并不是故障时，通过服务进程中前k个可疑节点，我们可以尽可能地减少再次定位故障的时间，仅需要检查下一个可疑节点是否是故障即可。根据给定的前k个可疑节点，所提方法也可诊断包含多个故障的服务进程。

（5）在程序故障诊断研究中，通过假设存在一个可识别故障状态的完备程序模型，研究者可以诊断任何程序故障类型。然而，这样的假设对于云应用当中的服务进程是不现实的。这是因为一个云服务的可靠性不仅仅依赖于云应用自身，很大程度上也取决于它所部署的物理位置以及不可预测的网络状态。我们所提出的方法聚焦于诊断云服务自身的故障，如商务逻辑故障、数据语义故障。对于云应用来说，这些故障类型是最难定位的，但也是最关键的。