Page 9 - 《软件学报》2021年第5期

殷康璘 等:基于混沌工程的微服务韧性风险识别和分析 1233

通过设立由 MRMM 的 3 项度量指标构成的服务韧性目标,可以描述出一个微服务架构系统预期达到的服
务韧性;随后,微服务架构系统的开发人员将在各种可能的系统环境扰动中寻找出会超出韧性目标阈值的扰动,
将其认定为威胁微服务韧性的软件风险(以下简称为韧性风险),并为其设计系统应对机制 [15] .在传统的软件风
险分析过程中,对软件风险的识别通常采用头脑风暴、专家经验等人为分析方法,然而在微服务架构系统中,随
着微服务数量的增加以及服务之间调用关系的复杂化,根据微服务架构系统中各类型系统资源可能发生的环
境扰动事件类型,人为地列举出所有可能发生的具体系统环境扰动(如某一个服务存在一种扰动类型,就需要穷
尽目标系统的各个服务在发生这种扰动后可能的情况)并逐个验证这些扰动是否会产生严重的服务降级,显然
会消耗大量的人力成本以及时间成本.对于识别到的韧性风险,现有的故障诊断和分析方法需要对目标系统的
所有通信过程植入监控代码,或对历史性能数据人工地标注系统正常异常与否,将花费大量额外的系统开发成
本或人工成本.此外,没有统一的韧性度量方法,使得微服务架构系统的研究人员难以界定服务性能受系统环境
扰动影响的严重程度,并在迭代过程中选择需要优先处理的韧性风险.综上所述,微服务架构系统的韧性风险识
别过程中存在着以下两个问题.问题 1:如何使用较少的人力和时间成本识别出目标微服务架构系统的韧性风
险?问题 2:如何分析识别到的韧性风险对目标微服务架构系统的影响?
针对上述问题,本文提出了微服务韧性风险的识别和分析方法,其整体流程如图 1 所示.首先,本方法根据
MRMM 模型中的韧性度量指标为目标微服务系统中的服务设立韧性目标;随后,基于混沌工程的方法执行若干
次混沌实验,在每次混沌实验中,以随机的方式生成系统环境扰动,通过比较实验中系统环境扰动产生的服务降
级是否超出服务韧性目标的阈值范围,识别出目标系统中的韧性风险.针对每一个被识别的韧性风险,为了免去
对微服务架构系统的额外开发成本和对性能数据的人工标注成本,本文通过因果关系搜索算法无监督地分析
实验结果数据中各系统性能指标之间的因果关系,并给出可能的韧性风险影响链路.

Fig.1 Process of microservice resilience risk identification and analysis
图 1 微服务韧性风险的识别和分析过程

本文第 1 节概述本文的相关研究.第 2 节介绍基于混沌工程的韧性风险识别方法.第 3 节介绍针对微服务
架构系统的韧性风险分析方法.第 4 节以一个微服务架构系统 Sock-Shop 为例,对本文提出的方法进行案例研
究.第 5 节进一步分析案例研究的实验结果,总结本文的工作,并提出下一步的研究计划.
1 相关工作

在学术研究中,韧性最早由生态学家 Holling 于 1973 年所提出,用以表示一个生态系统响应外部干扰并恢
复由外部干扰所带来的损害的能力 [16] .随后,韧性这一概念逐渐被引入至社会-生态系统、经济学、组织管理、
城市规划等多个领域 [17,18] .在软件/计算机领域中,韧性的概念虽然在微服务架构诞生之前就已被提出,但计算
机领域有关韧性的研究相对于其他领域仍处于初步阶段.Laprie 于 1992 年在可靠性(dependability)相关定义的
综述中提出了韧性的概念,并将韧性定义为软件系统对故障的恢复能力 [19] ;随后,于 2008 年提出将韧性作为可
靠性(reliability)的引申研究,重新将韧性定义为:在软件系统在面对系统环境、配置等因素变化时,系统维持服务
发布状态的能力 [20] .2012 年,由科因布拉大学和纽卡斯尔大学建立的 AMBER(assessing, measuring, and
benchmarking resilience)组织回顾了各文献对韧性的定义,并阐述了韧性在云计算中的必要性以及与软件韧性
的相关研究 [21] .一些针对软件/计算机韧性的研究 [22−24] 基本都通过应用其他领域的定义来说明韧性这一概念,
并尝试解释韧性与可靠性、容错性等软件质量特性的关系.
在微服务架构被提出的几年内,微服务架构韧性的重要性就已在一些应用书籍 [10,25] 以及学术研究 [11] 中被