Page 131 - 《软件学报》2021年第5期
P. 131
贺祥 等:多版本共存的微服务系统自适应演化方法 1355
集 1 和服务集 2 进行了实验 4 和实验 5,时间窗口为 5 分钟.由于发布新服务的时间会严重影响服务的可用性,
因此仅采用平均响应时间和失败的用户需求数量进行评估.结果显示在图 7 中.
(a) 实验 4:服务集合 1,演化时间窗口为 5 分钟
(b) 实验 5:服务集合 2,演化时间窗口为 5 分钟
Fig.7 Average response time and count of failed demands in new demands scenario
图 7 新需求实验场景下的平均响应时间和失败需求数量
结果表明:无论是在具备简单的服务依赖的情况或是复杂的服务依赖的情况下,MF4MS 均能够在新服务
注册到系统后,稳定平均响应时间并满足用户的新需求.当开发者将能够满足之前无法满足的用户需求的新服
务后,系统会在一个演化时间窗口内快速响应,在考虑服务之间的复杂版本依赖关系的同时,快速对服务进行编
译打包以及部署,保持了 QoS 的稳定.
[9]
[8]
目前已有的一些方法,如 APP-bisect 、VMAMVS 等,虽然考虑到了微服务之间的依赖关系,且能够在一
定程度上对系统中出现的问题进行自动修复,但这些方法不具备针对用户需求变化以及开发者敏捷 DevOps 的
自适应能力,无法用于对比实验;而像文献[10−12]等提出的方法尽管具备一定的自适应能力,能够针对系统中
的性能问题进行横向拓展,却也无法处理用户的需求变化及 DevOps 流程中的部署需求.此外,这些方法无法处
理微服务多版本共存以及微服务之间依赖关系,亦无法作为对比实验.
4.2 DevOps流程中部署需求自适应实验
该部分实验选取了实验集合 1 和集合 2 中的部分服务作为 DevOps 操作的对象,并通过 DevOps 指令数量、
实例部署数量、实例删除数量、是否需要人工参与、是否支持带依赖部署以及是否支持多版本共存、是否修
改源码且停止服务实例这 7 个方面对第 3.2 节给出的各种操作在考虑依赖关系的情况下进行实验对比.其中,
DevOps 指令数量是指由开发者发送给系统或者工具的指令数量;实例部署、删除数量是指完成对应的 DevOps
操作过程中部署、删除了多少个实例;是否需要人工参与是指在执行 DevOps 操作过程中是否需要参与进行决
策、判断等人工操作;是否支持带依赖部署是指该种方法是否能够自动处理依赖关系;是否支持多版本共存是
指该种方法是否能够允许同一个服务不同版本同时存在;是否修改源码、停止服务实例表示在服务依赖变更过
程中,是否需要人工修改服务源代码,并停止原服务实例.这里选取 Kubernetes 以及 JRO(jolie redeployment
optimizer) [13] 进行对比实验.其中,Kubernetes 是一套流行的容器管理工具,JRO 是一套考虑了服务之间的依赖关