软件学报ISSN 1000-9825, CODEN RUXUEW
E-mail:************ Journal of Software ,2021,32(5):1341−1359 [doi: 10.13328/jki.jos.006236]
©中国科学院软件研究所版权所有. Tel: +86-10-62562563
∗
贺 祥, 刘 磊, 涂志莹, 徐晓飞
(哈尔滨工业大学 计算机科学与技术学院，黑龙江 哈尔滨 150001)
通讯作者: 徐晓飞,E-mail:***************
摘 要: 微服务设计模式通过将应用程序拆分成多个相互独立的微服务，实现了各个微服务之间的相互解耦，允许各个微服务能够独立地进行迭代开发、部署，从而对用户需求变化以及DevOps 流程中部署需求作出快速响应.每个微服务的独立迭代升级导致了系统中可能出现多版本共存现象，不同服务的不同版本之间的依赖关系变得更加复杂.如何在这种场景下适应用户不断变化的需求以及开发者敏捷DevOps 流 程中部署需求，是当前面临的一个挑战.为解决这一问题，提出了微服务依赖模型来刻画不同服务的不同版本之间复杂的依赖关系，设计了基于贪婪的优化算法来到最优的微服务系统演化方案，以满足用户需求变化和敏捷DevOps 流程中部署需求，并实现了面向演化的微服务编程框架(MF4MS)和微服务系统自适应架构(MI4MS)，可支持演化方案的自动执行，实现微服务系统运行时的自适应演化.实验结果表明：在有着复杂依赖的微服务系统中，该方法在服务失效时长、服务可用性、开发者DevOps 代价等指标上有很好的表现，可有效支持微服务系统自适应演化，以应对用户需求变化和敏捷DevOps. 关键词: 微服务系统；多版本共存；版本依赖；自适应；用户需求变化;DevOps
中图法分类号: TP311 中文引用格式: 贺祥，刘磊，涂志莹，徐晓飞.多版本共存的微服务系统自适应演化方法.软件学报,2021,32(5):1341−1359. /1000-9825/6236.htm
英文引用格式: He X, Liu L, Tu ZY, Xu XF. Self-adaptative evoluationary method of multi-version coexisting microservice systems. Ruan Jian Xue Bao/Journal of Software, 2021,32(5):1341−1359 (in Chinese). /1000-9825/6236. htm
Self-adaptative Evoluationary Method of Multi-version Coexisting Microservice Systems HE Xiang, LIU Lei, TU Zhi-Ying, XU Xiao-Fei
(School of Computer Science and Technology, Harbin Institute of Technology, Harbin 150001, China)
Abstract : A microservice-based system is composed of a set of microservices that are developed and deployed independently for agile DevOps. Intensive and iterative adaptations/upgrades of microservices are essential for such systems to adapt to user requirement changes and DevOps, and as a consequence, result in the phenomenon of “multi-version microservice coexistence” in a system. Besides traditional API-based functional dependencies between different microservices, there appear complicated dependencies between different versions of difference microservices, which dramatically deteriorate the maintainability of microservice systems, especially when systems evolve to adapt to user requirement changes and DevOps. To meet this challenge, a version dependency model is proposed for describing the complex dependencies between different versions of microservices, and greedy-based optimization algorithms are developed for generating an optimal evolution plan according to changes in user requirements and DevOps at different scenarios. A programming framework (MF4MS) and cloud-edge based infrastructure (MI4MS) are implemented to facilitate microservice systems to automatically ∗
基金项目: 国家重点研发计划(2018YFB1402500); 国家自然科学基金(61832014, 61772155, 61832004, 61802089)
Foundation item: National Key Research and Development Program of China (2018YFB1402500); National Natural Science Foundation of China (61832014, 61772155, 61832004, 61802089)
本文由“面向持续软件工程的微服务架构技术”专题特约编辑张贺教授、王忠杰教授、陈连平研究员和彭鑫教授推荐.
收稿时间: 2020-09-21; 修改时间: 2020-10-26; 采用时间: 2020-12-15; jos 在线出版时间: 2021-02-07
1342
Journal of Software 软件学报 V ol.32, No.5, May 2021
execute the evolution plan. Experiments show that the proposed approach performs well on service down time, service availability, and the developers’ cost of DevOps coping with self-adaptation in the situation where complicated version dependencies exist.
Key words : microservice systems; multi-version coexistence; version dependency; self adaptation; user requirement changes; DevOps
在当今的一些诸如智慧城市(smart city)[1]等较为复杂的计算场景中，由于容器技术和微服务架构模式[2]在持续交付、敏捷开发以及DevOps 方面的优势[3]，随着计算场景中的业务逻辑变得越来越复杂，容器技术和微服务架构模式受到越来越多的关注.然而，微服务的独立开发和部署，导致它们之间可能存在复杂的依赖关系.微服务通过API 相互通信，它们之间存在的调用依赖关系可表示为服务依赖关系图(SDG)[4].将某个微服务升级到新版本后，它的调用依赖关系可能会变化，依赖于该微服务的其他微服务可能会由于不能向前兼容的升级而无法正常调用.考虑到某些用户会请求特定的旧版本，微服务开发人员无法更新系统中已部署的所有微服务实例.因此，同一个微服务会有多个不同版本在系统中同时部署，这称为多版本共存(multi-version coexistence).在多版本共存的微服务系统中，不同微服务的不同版本之间有着不同的依赖关系，这种复杂的依赖关系称为版本依赖(version dependency)，如图1(a)所示，服务S 1在版本v 1时，依赖服务S 2的v 2,v 3版本.而当服务S 1升级至v 3版本后，依赖变为服务S 2的v 3,v 4版本以及服务S 3的v 2,v 3,v 4版本
.
Fig.1 Introduction for multi-version coexisting microservice system
图1 多版本共存的微服务系统介绍
这种复杂的微服务系统面临着频繁的演化需求.
• 一方面，此类系统往往存在着大量的用户和服务，且用户需求处于时刻变化中.而系统无法对变化的用
户需求作出及时响应，导致系统的服务质量(QoS)下降.由于多版本共存导致版本依赖性的复杂性增加，在边缘计算的微服务场景中，如何在复杂版本依赖的情况下让服务系统对用户需求变化作出及时响应，成为了一个新的挑战.为此，需要形成一个针对需求动态变化的演化方案.
• 另一方面，开发者为了完善系统，不断在DevOps 流程中提出需求，如部署新服务、管理现有实例等操作.
服务之间复杂的版本依赖，让一项DevOps 流程中部署需求的实现不再是原子的，而是可能影响到其他微服务的其他版本的DevOps 流程中部署相关的操作，增加了开发者运维微服务系统的负担.
综合起来，考虑到系统中大量的用户、服务以及依赖关系，在云边缘环境中的微服务系统应能够在满足版本依赖的情况下:(1) 针对用户需求变化进行自适应演化以保持QoS 稳定[5];(2) 正确和自适应地满足开发者的(a) 版本依赖 (b) 系统架构概观
贺祥 等：多版本共存的微服务系统自适应演化方法 1343 DevOps 流程中部署需求.该问题如图1(b)所示.考虑到DevOps 是一套完整的快速交付流程，本文仅考虑DevOps 流程中和服务实例部署相关的操作.
在本文中，我们考虑了有关云边缘环境中多版本共存微服务系统自适应演化的3个研究问题(RQ).
RQ1. 如何对微服务之间的版本依赖进行建模?由于每个微服务的版本树都是独立的，版本依赖关系会随时
间变化，因此对于服务系统而言，在运行时对版本依赖关系进行建模至关重要.此外，现有描述微服务之间调用依赖关系的方法如SDG 无法应对微服务的快速迭代开发.当微服务发生兼容升级时，调用该微服务的其他微服务应动态扩展其版本依赖.
RQ2. 如何在考虑版本依的情况下得到最佳演化方案?为了满足不断变化的用户需求，考虑到每个可行的演
红豆杉提取物化计划都有特定的成本，例如货币成本、服务停机时间等，演化方案需要满足一定的约束条件.同时，在版本依赖的约束下，应在有限的时间内得到最佳的演化方案.针对DevOps 流程中的部署需求，需要在考虑版本依赖的情况下，正确执行相关指令.
RQ3. 如何在版本依赖的约束下自动执行演化方案?由于多版本共存微服务系统的复杂性，该系统应具有自
适应性[6]：监视系统的运行时状态、决定何时以及如何演化、自动执行演化方案.在演化过程中，应保
证多版本共存系统中请求路由的正确性，并满足系统中各个微服务实例的版本依赖.此外，为了降低系统维护的复杂度，需要能够自动化处理用户需求变化以及DevOps 流程中部署需求，减少人工操作. 本文主要有3点贡献.
1) 提出了版本依赖模型(version dependency model，简称VDM)以解决RQ1的版本依赖建模，该模型很好
地解决了迭代部署问题，同时实现了编程框架Microservice Framework for Microservice System (MF4MS)，通过将版本依赖描述集成到源代码中，可以让系统在部署之前实现服务依赖的自动分析，并能够让多版本同时部署在系统中.
2) 提出了一系列自适应算法以解决RQ2.这些算法在不同的应用场景中，面对不同种类的用户需求变
化，在版本依赖的约束条件下，到近似最优解的演化方案，从而随着用户需求的变化而维持或者提高QoS；在处理DevOps 流程中的部署需求时，能够自动计算依赖关系，并得到演化方案以自动执行DevOps 流程中部署需求.
3) 开发了基于MAPE-K 模型[7]的微服务系统架构Microservice Infrastructure for Microservice System
(MI4MS)以解决RQ3.它采用自控制循环(self-control loop)，可以在满足版本依赖的情况下，对不同种
类的用户需求变化进行服务系统的运行时监控、演化方案的生成以及演化方案的自动执行.针对DevOps 流程中部署需求，能够接收来自开发者的操作指令，在考虑依赖的情况下自动执行相关指令. 通过对现实世界中常见的应用场景的刻画，构建了真实的云边缘环境来进行实验.结果表明：该方法在有着复杂版本依赖的情况下，针对用户需求变化能够进行自适应演化，并且保持QoS 稳定；针对DevOps 流程中的部署需求，该方法能够正确处理依赖关系并自动执行相关的DevOps 操作，减轻了系统维护的负担.
本文第1节介绍版本依赖模型VDM 以及自适应系统的设计.第2节介绍不同场景下的相关演化算法.第3节介绍编程框架和微服务系统架构的具体实现.第4节介绍实验设计以及实验结果.第5节介绍相关工作.最后在第6节进行总结并探讨未来工作.
1 版本依赖模型与自适应系统设计
1.1 版本依赖模型
考虑到服务依赖关系图只能描述特定版本的微服务的API 之间的调用依赖关系，不适用于不断变化的服务依赖关系进行迭代开发，因此我们提出了基于服务依赖关系图的版本依赖关系模型.
定义1. s =〈I ,c ,m ,v 〉服务系统中的服务定义,s ∈S ,S 是系统中的服务集合，其中,
• I ={i 1,i 2,…,i n }，服务s 提供的功能接口集合.每一个接口都表示为,,,in out i i i i i i f l d d =〈〉，其中,f i 表示服务的
1344
Journal of Software 软件学报 V ol.32, No.5, May 2021
功能接口i i 所提供的非结构化文本形式的功能语义描述,l i 表示接口所提供的质量约束,in i d 和out i d 分 别表示接口输入参数和输出参数的大小(单位KB).
•
c 表示服务器运行服务s 所需的计算资源(如CPU 、RAM 、存储空间、网络带宽总量等). •
m 表示服务s 在资源c 的情况下，能够在保证服务质量前提下的最大用户数量. • v =〈MAJOR ,MINOR ,PATCH 〉表示服务的版本号.采用了广泛使用的Semantic Version 定义:MAJOR 变化
表示发生了不能向前兼容的API 变化,MINOR 变化表示以向前兼容的方式修改、增加了功能,PATCH 表示修复了漏洞且保持向前兼容(/).
现有的大多数微服务框架如SpringCloud 中的传统调用依赖关系可以描述为〈s ,i 〉，通过对服务名称和接口构建相应的路由表以达到服务之间的相互调用，不具备对指定版本的定向请求.且一旦将某些微服务升级到具有不兼容更改的新版本，其他服务就需要在代码级别上对其进行修改，这增加了开发人员的负担.此外，开发人员必须注意系统中越来越复杂的版本依赖，以确保系统中请求的正确路由.为了达到在不进行代码修改且不重启服务实例的情况下，在运行时对依赖关系进行修改，对传统的依赖关系类型进行了拓展:
定义2. D ={p v ,p i ,p f }为服务系统中的3种依赖类型的集合，表示一个服务对其他微服务接口或者功能的具体调用关系，其中,
•
p v (s ,i ,v )=〈s ,i ,v 〉，表示一个服务对服务版本在集合V 中的服务s 的功能接口i 的依赖关系,V ={v 1,v 2,…, v n }.即调用版本集合V 中任意版本的服务s 的接口I . •
p i (s ,i ,L )=〈s ,i ,L 〉，表示一个服务对服务s 的功能接口i ，且其质量约束在集合L 中的依赖关系,L ={l 1,l 2,…, l n }.即调用服务s 任意一个质量约束在L 中的接口I . • p f (f ,L )=〈f ,L 〉，表示一个服务对任意具备功能f 且质量约束在集合L 中的接口的依赖关系.即表示调用任
意一个功能为f 的接口，且该接口的服务质量约束在L 中.
在诸如OpenFeign(spring.io/projects/spring-cloud-openfeign)等现有的微服务框架中，微服务之间的API 调用通常是硬编码在代码中，当出现由于错误修复而导致被调用的微服务发生不兼容升级时，如果不进行代码修改，则无法变更微服务之间的依赖关系，进而导致现有方式无法适应快速迭代开发.而通过3种微服务依赖类型，可以灵活地对微服务之间的依赖关系进行刻画，并在处理请求定向时，由于可以不与具体版本的服务进行绑定，有着更广泛的定向选择，能够更好地调整实例的部署情况.此外，针对调用关系p v ，允许开发者通过版本号表示服务的向前兼容性，从而让系统能够按照版本号进行依赖判断，从而为用户需求选择更加合适的服务.
定义3. VDM ={〈s ,v ,p 〉|s ∈S }，微服务系统中的版本依赖模型VDM 刻画了微服务系统中所有微服务每个版本的依赖关系.P ={p 1,p 2,…,p n },p i ∈D .表示每个服务可能有着多个依赖.〈s ,v ,p 〉表示v 版本的服务s 对其他服务的依赖关系为集合P .
环氧树脂阻燃剂VDM 通过p v 在传统的服务之间的依赖描述上增加了版本集合，对SDG 进行了拓展，允许系统将指定版本范围的请求重定向到兼容版本.此外,VDM 还提供了另外两个新的依赖类型p i 和p f .当尝试请求具有特定SLA 的服务接口时使用p i ，系统可以自动将具备p i 依赖的请求路由到具有期望SLA 的实例上，无需指定服务的具体版本，即使微服务经常升级，也能够主动定向到符合的实例上.而p f 允许开发人员按功能和预期SLA 进行功能请求，这进一步分离微服务之间的依赖关系，服务系统可以将请求重定向到具有最佳SLA 和性能的实例.开发人员无需在微服务的独立迭代开发过程中修改源代码，降低
了开发人员的负担.
1.2 自适应系统设计
多版本共存的微服务自适应系统由两部分构成：支持多版本的微服务编程框架MF4MS 以及微服务系统架构MI4MS.其中,MF4MS 负责在代码层级对多版本共存提供支持，提供对3种依赖关系的配置以及对具备指定依赖关系请求的支持;MI4MS 负责在服务实例层面对服务部署进行针对用户需求变化的自动调控.
1.2.1 编程框架设计
编程框架MF4MS 需要具备以下功能.
(1) 提供对3种版本依赖关系的配置功能，开发者可以通过编写指定格式的配置文件表示该服务的版本
贺祥 等：多版本共存的微服务系统自适应演化方法
1345
铜锌合金依赖关系. (2) 提供对服务的功能接口的功能以及服务质量的描述功能，开发者可以通过注解等方式为服务的每个
接口注明功能及质量信息.
高斯加速器
(3) 提供发起具备任意类型的版本依赖关系的请求功能，考虑到VDM 对现有的微服务依赖关系进行了
拓展，以及已有的编程框架无法满足VDM 的需求,MF4MS 需要提供相关接口允许在请求过程中携带额外的版本依赖信息.
(4) 提供集成与未集成MF4MS 服务实例的区分能力.对于未使用该框架的服务实例，系统不应该将其纳
入管理范围内，不能够对其进行任何操作.
酸洗槽(5) 支持运行时的依赖修改.运行时能够通过特定接口对服务实例的依赖关系进行更新而不需要修改源
代码、重新编译打包、停止旧实例并部署新实例.
此外，编程框架还需要尽量降低开发者对现有代码迁移的负担.
1.2.2 系统架构
MI4MS 旨在借助MAPE-K 模型让微服务系统具备自适应能力，系统可以自动检测用户需求变化，生
成演进计划，并自动执行计划，如图2所示.考虑到不同微服务有着不同的运行环境,MI4MS 使用容器运行每个微服务实例，并使用Kubernetes 搭建边缘侧容器集
锦纶6切片.
Fig.2 Overview of the MI4MS
图2 MI4MS 示意图
MI4MS 有5个主要组件.
• Control Center.在MI4MS 中起主要作用，负责控制整个服务系统.它采用了MAPE-K 模型，并实现了自
适应控制循环：在运行时监视系统状态，分析系统当前QoS 情况以及用户需求变化，通过自适应算法计算出合适的演化方案，最后自动执行方案.该组件应该部署在云端的任意节点上.
•
Service Analyzer.旨在分析符合编程框架MF4MS 规范的微服务源代码，自动从中抽取3种类型的服务依赖信息，同时与Control Center 协作进行版本依赖模型的构建.该组件应该部署在云端节点上. • Cluster Agent.负责借助Kubernetes API Server(kubernetes.io/docs/concepts/overview/components/
#kube-apiserver)和服务注册中心Registry(microservices.io/patterns/service-registry.html)来获
取边缘集的部署状态，并将收集到的信息传递到Control Center.同时，它需要接收来自Control Center 的
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议