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

1232 Journal of Software 软件学报 Vol.32, No.5, May 2021

before the system is released, are the research questions in microservice development. According to the microservice resilience
measurement model which is proposed in authors’ previous research, by integrating the chaos engineering practice, resilience risk
identification and analysis approaches for microservice architecture systems are proposed. The identification approach continuously
generates random system environment disruptions to the target system and monitors variations in system service performance, to find
potential resilience risks, which greatly reduces human effort in risk identification. For identified resilience risks, by collecting
performance monitoring data during chaos engineering, the analysis approach uses the causality search algorithm to build influence chains
among system performance indicators, and provide chains with high possibility to system operators for further analysis. Finally, the
effectiveness of the proposed approach is proved by a case study on a microservice architecture system.
Key words: microservice; resilience; software risk identification; chaos engineering

[1]
微服务架构(microservice architecture)是由马丁·福勒所提出的一种新的软件架构模式 ,它将一个单体的
软件系统拆分为若干可独立运行、部署的微服务(microservices).微服务架构将软件功能变更的规模控制在一
个微服务内部,且不影响其他的微服务,大幅减少了软件功能迭代过程中系统重新构建、测试、部署的成本,因
[2]
此,采用微服务架构成为了 DevOps 开发模式中常用的手段 .近年来,微服务架构已成为许多互联网公司会使
用的一种主流软件架构模式 [3−5] .
相对于早年面向服务架构的软件系统,采用微服务架构的软件系统(以下简称微服务架构系统)对服务的划
分更细粒度化,并且通常会使用容器技术提高系统资源的利用率,以致微服务架构系统部署结构更为复杂.受此
影响,微服务架构系统会面临更多非软件设计缺陷因素(如服务器意外宕机、网络不稳定等)所引发的软件系统
[6]
故障 .除了软件系统故障以外,软件系统的升级、系统部署配置(如微服务的冗余备份配置、虚拟机的资源分
[7]
配)的动态变更、未预期的工作负载等情况,均可能导致微服务架构系统不能正常提供其服务 .
[8]
在传统的软件系统质量度量中,描述系统应对故障能力的度量指标有可用性、可靠性、容错性等 ,这些度
量指标往往将系统的状态分为“可用/可靠”和“不可用/不可靠”两种.但是,近年来对云计算故障模式的相关研究
表明 [7,9] :故障除了能直接导致系统服务本身的不可用之外,也可能会使系统服务质量(性能)受到严重影响,但是
系统服务仍处于可访问状态.在这种情况下,可用性、可靠性这一类指标并不能完全体现出一个微服务架构系
统在故障发生时其系统服务性能受到影响的严重程度.例如,一个系统在情况 A 下系统服务的平均响应时间从
3s 延长至 5s,在情况 B 下系统服务的平均响应时间从 3s 延长至 12s,假设情况 A 和情况 B 持续的时长相同,那么
系统在情况 A 和情况 B 下的可靠性也是相同的.但是很明显,系统在情况 B 下服务性能受影响的程度比在情况
A 下严重.另一方面,现有对软件系统服务性能的评估方法主要以性能测试为主,通过性能测试可以识别出系统
在一定服务压力下体现出来性能设计缺陷.但是系统在故障发生时,系统服务性能受到的影响并不会在性能测
试中验证.
基于上述原因,微服务架构系统的相关研究人员开始使用“韧性(resilience)”一词表示系统处理故障的能
力 [10,11] (“resilience”一词在不同学术领域中有多种翻译,通常被翻译为“弹性”“韧性”,而国内计算机领域目前对
resilience 的翻译尚未确定.由于“弹性”一词早已在云计算中被用来形容软件系统的伸缩性和可扩展性,本文使
用“韧性”一词作为 resilience 的翻译).为了提高微服务架构系统的韧性,负载均衡、熔断机制、心跳检测等一些
常用的系统容错机制 [12] 被开发人员和架构设计人员应用在系统上.
在计算机领域中,目前还没有对软件韧性有统一的定义.根据其他领域研究中对韧性的定义 [13] 以及韧性这
一概念在微服务架构系统开发者中被使用的情况,本文作者在先前的研究工作 [14] 中从服务性能的角度将微服
务架构系统的韧性定义为:“一个微服务架构系统在系统环境扰动发生并导致其服务性能下降后,维持其服务性
能在一个可接受的水准,并快速将服务性能恢复至正常状态的能力”.其中,系统环境扰动(disruption)是其他领域
韧性研究中的一个通用概念,意为影响系统(非特指软件系统)功能正常运作的事件.在微服务架构系统中,系统
环境扰动既包括软件系统的内部组件故障,也包括上文中所提及的诸如系统升级、配置变更等使微服务架构系
统产生“变更”的事件.在上述定义的基础上,该研究提出了微服务韧性度量模型 MRMM(microservice resilience
measurement model),该模型将微服务架构中有关韧性的概念进行概念建模,并给出用于度量系统环境扰动发生
时服务性能变化的 3 个度量维度,以评估其对微服务架构系统服务性能的影响程度.