PaaS级别云环境可靠性硬件架构研究

PaaS级别云环境变化的可靠性陶新秀引用此版本：陶新秀。PaaS级别云环境变化的可靠性硬件架构[cs.AR]。格勒诺布尔阿尔卑斯大学，2019年。英语NNT：2019GREAM001。电话：02143040HAL Id：tel-02143040https://theses.hal.science/tel-021430402019年5月29日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaireTHAPOSE为了获得等级格勒诺布尔阿尔卑斯大学博士专业：信息Arrêté ministériel：25 mai 2016Présentée par陶新秀Thèse dirigée parFabienne BOYER，MCF，LIG /UGANoël DE PALMA，LIG-UGA和Xavier ETCHEVERS，研究工程师，Orange Labs准备在巴黎高等数学、科学和信息技术学院的LIG和Orange实验室学习在Cloud au niveau平台即服务中固定当前任务PaaS级别Thèse soutenue publiquement le29 janvier 2019，devant le jury composé de：法国国家科学研究中心的FrançoiseBaude Mesquerseur女士，特别报告员Lionel SeinturierMesquerseur先生，Inria，特别报告员DanielHagimontMesquerseur先生，IRIT/ENSEEIHT，校长ThomasLedoux先生Enseignant-chercheur，IMT检查员，检查员Fabienne BOYER会议主任，LIG/UGA，主任诺埃尔·德帕尔马UGA/LIG联合主任泽维尔·埃切弗斯研究工程师，Orange Labs，联合主任i摘要微服务架构被认为在IT组织中实现DevOps有很大的希望，因为它们将应用程序拆分为可以相互独立更新的服务。但是，为了在更新微服务时保护SLA（服务水平协议）属性，DevOps团队必须处理复杂且容易出错的管理操作脚本来执行更新。更确切地说，更新脚本必须遵循特定的策略，例如着名的BlueGreen策略[1]，该策略旨在以零停机时间更新微服务，但需要在停止和卸载旧服务之前部署和启动所有新的微服务相比之下，金丝雀策略[2]最大限度地减少了更新时使用的资源，但代价是降低了可用性：微服务以增量方式就地更新（新实例取代旧实例），以缓慢地将负载从当前版本转移到新版本。在这篇论文中，我们提出了一个更新框架[3，4]，它利用基于架构的方法来提供一种简单安全的方法来更新微服务和程序策略。更新策略不是处理PaaS命令的脚本，而是定义为应用于微服务应用程序架构模型简单地说，这个架构模型反映了微服务如何部署在PaaS站点上以及如何配置它们利用基于架构的方法会带来两个主要挑战：（i）确定包含部署在异构PaaS站点上的微服务的架构模型，以及（ii）定义依赖于该架构模型的策略驱动的更新这些文档的以下部分描述了如何解决这些挑战，以提供一个更新框架，可以添加，删除，迁移，拆分或扩展微服务，以及在分布式和潜在异构的PaaS站点上升级代码或更改配置。ii内容4.2.3微服务的自省和重新配置1介绍12问题位置32.1微服务. . . . . . . . . . . . . . . . . . . . . . . . . .52.2云计算。. . . . . . . . . . . . . . . . . . . . . . . .72.2.1资源虚拟化. . . . . . . . . . . . . . . .72.2.2云服务模型。. . . . . . . . . . . . . . . . .82.2.3 PaaS/CaaS层和微服务。. . . . . . . . .92.3持续交付. . . . . . . . . . . . . . . . . . . . . .112.4动机和目标. . . . . . . . . . . . . . . . . . .132.5挑战。. . . . . . . . . . . . . . . . . . . . . . . . . . . .153现有技术173.1现有的动态软件更新方法。 . . . . .183.1.1 DSU。. . . . . . . . . . . . . . . . . . . . . . . . . . .183.1.2组件。. . . . . . . . . . . . . . . . . . . . . .183.1.3参与者。. . . . . . . . . . . . . . . . . . . . . . . . . .193.2现有的微服务动态更新方法。.193.2.1比较网格。. . . . . . . . . . . . . . . . . . . .193.2.2三角帆。. . . . . . . . . . . . . . . . . . . . . . . .203.2.3 IBM UrbanCode部署。. . . . . . . . . . . . . . . .233.2.4AWS CodeDeploy 。. . . . . . . . . . . . . . . . . . .263.2.5 Push2cloud.. . . . . . . . . . . . . . . . . . . . . . .273.2.6管理微服务的其他相关方法。293.2.7摘要. . . . . . . . . . . . . . . . . . . . . . . .304命题344.1使用原则. . . . . . . . . . . . . . . . . . . . . . . .364.2建筑模型。. . . . . . . . . . . . . . . . . . . . . .384.2.1数据结构。. . . . . . . . . . . . . . . . . . . . .384.2.2基本操作. . . . . . . . . . . . . . . .应用程序.. . . . . . . . . . . . . . . . . . . . . . .3941iii内容4.3战略驱动的更新454.3.1更新过程概述454.3.2策略驱动更新协议464.4战略规划494.4.1战略设计494.4.2教学案例：蓝绿战略514.5更新稳健性544.5.1核心原则. 544.5.2识别故障564.5.3摘要615评价645.1SLA保护5.1.1油漆应用655.1.2帐户应用程序685.2稳健性705.2.1网络故障725.2.2更新过程故障745.2.3错误的战略755.2.4微服务故障785.3使用方便795.3.1方案拟订战略5.3.2更新微服务815.3.3与强制性方法的836结论866.1结论866.2限制和未来的工作88Bibliography参考书目951第1介绍为了促进敏捷开发和运营（DevOps），许多公司，包括Netflix [5]和Uber[6]等老牌公司，正在为其云应用转向微服务架构例如，到2020年，Orange的目标是将其约50%的生产应用程序（为全球2.4亿客户提供服务）迁移使用微服务方法，应用程序被设计为部署在分布式PaaS（平台即服务）站点上的松耦合服务，并在自己的全栈中运行[8]。微服务的关键属性是独立替换和可更新性的概念。特别是，微服务具有独立的生命周期：它们可以彼此独立地部署和更新。目标是支持小型开发团队的反应能力，每个团队负责通过简单快速的流程开发和发展自己的这样的目标是有吸引力的，但现实要复杂得多，因为微服务通常与SLA属性有关可用性，性能和资源成本[9，10]。为了在更新时保持这些属性，DevOps团队遵循复杂的策略。通常，著名的蓝绿策略[1]旨在以零停机时间更新微服务，但需要在停止和卸载旧服务之前部署和启动所有新的微服务。相比之下，金丝雀策略[2，11]最大限度地减少了更新时使用的资源，但代价是降低了可用性：微服务以增量方式就地更新（新实例取代旧实例），以缓慢地将负载从当前版本转移到新版本。使用策略来更新微服务被认为是相关的[12]，但到目前为止，该过程是手动管理的，或者仅通过使用脚本自动化[13]。虽然它们提供了灵活性，但它们的命令式形式限制了它们的易用性。当为DevOps团队提供独立于应用程序的脚本时，他们必须确定可以应用什么脚本来处理给定的更新。此外，他们必须检查其应用程序的当前状态2介绍阳离子符合所选脚本的要求这很麻烦，而且容易出错，因为大多数更新脚本都包含复杂的PaaS命令管道。当更新脚本专门为给定的应用程序设计时，它们可以以更容易和更安全的方式使用，但代价是DevOps团队必须编写这些脚本，面临通常的编码和调试挑战。本文主张从基于脚本的方法切换到基于架构的方法来自动化微服务更新：更新策略被定义为应用于微服务应用程序架构模型的元素更改序列，而 不 是 脚 本 处 理 PaaS 命 令 。 简 单 地 说 ， 这 个 架 构 模 型 （ 也 称 为model@runtime [14]）反映了微服务如何部署在PaaS站点上以及如何配置它们与脚本相比，拟议方法的预期好处如下：用途：要更新微服务应用程序，DevOps团队只需提供所需的目标架构以及要遵循的策略作为输入，而无需处理低级PaaS命令。预览：任何更新都可以在架构模型上处理，而不需要应用到有效的系统上，允许根据架构更改预览其控制：可以在架构模型上观察到更新的所有阶段。此外，在任何阶段，可以停止更新，并利用新的目标架构和/或策略恢复更新。• 鲁棒性：支持更新时发生的故障。本文件的其余部分组织如下。第2章介绍了问题的背景、我们的目标和主要的相关挑战。第三章介绍了动态更新的相关研究工作，并对当前微服务应用程序更新管理的工业解决方案进行了第4章提出了通过基于架构的方法更新微服务应用程序的框架。• 第五对我们的框架进行了评价第六总结了本文的主要内容并展望了未来的工作。·······3第2问题位置内容2.1微服务. . . . . . . . . . . . . . . . . . . .52.2云计算. . . . . . . . . . . . . . . . .72.2.1资源虚拟化. . . . . . . . . . . . . .72.2.2云服务模型。. . . . . . . . . . . . . . .82.2.3 PaaS/CaaS层和微服务。. . . . . . .92.3持续交付。. . . . . . . . . . . . . . . .112.4动机和目标。. . . . . . . . . . . .132.5挑战. . . . . . . . . . . . . . . . . . . . . .15变更管理现在是一个众所周知的术语，指的是将软件系统向新版本演进的动作，这种新版本集成了系统的结构、代码或配置中的变更。变更管理在应用程序生命周期中变得越来越重要，无论遵循何种软件开发方法来设计、开发和测试应用程序。瀑布法[15]是一种著名的线性软件开发方法，它将软件开发分为几个著名的阶段：分析需求、设计、编码、测试和维护。这种方法促使在早期阶段花费大量时间，以减少变更的风险无论如何，变更需求将随着时间的推移而出现，并且需要在对应用程序的影响最小的情况下进行管理。与传统的瀑布方法相比，当前流行的敏捷方法[16]提倡拥抱变化而不是减少变化。通过频繁地向最终客户交付小的更改，敏捷开发可以更好地适应客户在这篇论文中，我们解决了敏捷方法的具体情况下的变更管理，但我们的建议的原则可以应用于更一般的情况。多种范例有助于实施敏捷方法：问题位置4微服务应用程序架构：通过将应用程序解耦为可独立部署的单元，微服务旨在降低应用程序更改的成本。云环境：它们为部署和执行基于微服务的应用程序提供按需底层基础设施持续交付原则：它意味着每个变更都可以自动发布到生产环境中。本节的其余部分介绍了这些主要的范式，然后解释了本论文所面临的挑战。···问题位置52.1微服务如前所述，微服务没有标准定义，但有共同的指导方针影响分布式应用程序应该如何设计，开发和管理。因此，微服务可以被认为是一组用于设计应用程序的架构模式，旨在简化其部署和管理。更准确地说，基于微服务的架构将应用程序构建为一组称为微服务的松散耦合单元。每个微服务都与明确定义的业务能力相关联（例如，产品目录管理、订单管理）。基于此，每个微服务负责管理数据并处理与其业务功能相关的请求更确切地说，每个微服务可以通过提供的服务公开其功能，并且可以消费由其他微服务提供的服务（即所需的服务）。微服务的一个非常重要的方面是它们的生命周期独立性。事实上，给定应用程序的微服务具有独立的生命周期，因为每个微服务都可以独立部署，扩展和更新[17]。为了实现这一点，每个微服务都被打包为一个自包含的部署和执行单元。这样的包包含操作系统、运行时、框架、库和微服务工件（源代码和配置文件）。微服务的生命周期独立性有利于其分散治理，这是敏捷方法的关键能力每个微服务确实可以由指定的小团队独立开发和运营。每个团队负责技术和工艺选择（例如，编程语言、数据库解决方案、测试和交付工具）来构建自己的微服务，而不依赖于任何其他外部决策。为了促进这种生命周期独立性，微服务架构使用三种主要的设计模式微服务架构中的数据管理是分散的。虽然单体应用程序更喜欢使用单个数据库来存储持久数据，但微服务更喜欢让每个服务管理自己的数据库实例。每个微服务负责封装、管理和保护自己的数据库。这种分解允许每个微服务基于数据形状和读/写访问模式选择不同的数据存储。微服务通过轻量级协议进行通信，例如HTTP REST请求-响应或异步消息传递总线。当微服务实例开始运行时，它可以将其服务发布为··问题位置6Web服务，并在注册表1中注册其地址和端点，例如Consul [18]，Apache ZooKeeper [19]或Netflix Eureka [20]。当微服务实例不可用时，它将从注册表中注销2.通过注册表，微服务的客户端可以随时了解微服务的可用实例，并提供允许访问它们的地址信息。微服务容忍它们消费的服务（即访问的服务）的不可用性这种能力依赖于在设计微服务时符合特定的模式[21]（例如Circuit Breaker，Bulkhead 和 几 个 编 程 库 （ 例 如 ， Hystrix [22] 、 Finagle [23] 、Phantom [24]）可以简化这些模式的开发例如，开发人员可以很容易地为其访问的服务定义一个回退功能，这样当访问的服务不可用时，微服务就可以得到一个回退响应此外，微服务的管理员可以部署多个冗余和分布式实例，并使用智能代理来实现微服务的高可用性智能代理管理访问的服务不可用的情况。最常见的情况是，根据所访问的微服务的SLA属性，代理可以（i）选择另一个服务实例，（ii）等待服务恢复，或者（iii）生成默认回复。总的来说，通过将应用程序拆分为一组可独立部署的服务，微服务架构最大限度地减少了更改对运行应用程序的影响。对于经典的单片应用程序，将更改应用于任何单个模块通常需要重新部署整个应用程序。相反，在面向微服务的方法中，单个服务更改仅意味着重新部署所考虑的微服务。换句话说，微服务架构旨在解耦应用程序更改周期。1注册表服务通常由特定的应用程序部署和使用。2服务注册和注销可以由微服务管理，也可以由底层PaaS在启动和停止微服务时自动执行。·问题位置72.2云计算云环境使消费者能够在集中管理的数据中心中运行其应用程序消费者不能投资新的物理硬件资源来满足应用程序的要求，而只能从云提供商那里租用必要的计算、存储和网络资源。由于云环境提供的虚拟化和自主管理功能，消费者可以以自助服务的方式操作其应用程序的部署。此外，云环境通过在运行时使用冗余和弹性技术，帮助消费者构建高度可用和可扩展的应用程序[25]。本节首先介绍虚拟化技巧和技术。然后介绍了不同的云服务模型，最后重点介绍了平台即服务（PaaS）层，因为该层的目标是与微服务相关的层。2.2.1资源虚拟化云计算的关键技术是虚拟化。通过在逻辑上将物理资源划分为多个虚拟资源，虚拟化便于共享硬件资源。目前有两个主要的虚拟化级别：虚拟机（VM）和容器。除了划分系统资源外，这两种技术还可用于将应用程序封装特别是，它们目前都用于打包和部署微服务。在基于虚拟机的方法中，硬件IT资源（即计算、存储、存储）被封装在其行为模仿物理机器环境的软件单元（即虚拟机或VM）应用程序管理员可以将应用程序运行环境打包到VM中，该VM包含完整的软件堆栈，包括操作系统（OS）、中间件以及应用程序二进制文件和配置元素。然后，VM可以使用hypervi- sor在任何物理机器上执行。由于虚拟机在硬件级别提供虚拟化，因此管理员在虚拟机上的体验与在专用物理机上的体验相同基于容器的虚拟化方法发生在操作系统级别。操作系统内核和可能的一些中间件在运行在公共主机上的所有容器之间共享因此，应用管理员仅将某些特定的中间件和应用与容器打包。因此，该容器包括相当简化的软件栈，并且不需要安装完整的系统引导。由于它们减少了软件堆栈，与VM相比，容器的大小更小然而，相反，基于虚拟机的方法提供了更多的安全性，因为它具有更好的隔离性，问题位置8完全独立。因此，为了从这两种方法的优点中受益，将它们结合起来可能是相关的[26]。2.2.2云服务模型根据NIST的定义[ 27 ]，云环境根据服务抽象级别分为三个SaaSPaaSIaaS图2.1：云服务模型。改编自[28]基础设施即服务（IaaS）：在这个级别，云提供商提供虚拟化硬件（例如，虚拟化机器、网络）提供给消费者。应用程序操作的控制和责任完全交给了消费者。IaaS产品的一些例子是Amazon ElasticCompute Cloud （ Amazon EC2 ） [29] ， Google Compute Engine（GCE）[30]，OpenStack [31]。平台即服务（PaaS）：云提供商提供应用程序的运行环境，消费者只提供他们的应用程序代码。提供者有责任安装用于构建应用程序环境的操作系统和中间件层与IaaS模型相比，消费者对基础设施的控制较少。PaaS产品的一些例子是Google App Engine [32]，AppScale[33]，OpenShift [34]，Heroku [35]，Cloud铸造厂[36]。软件即服务（SaaS）：云提供商完全管理应用程序。消费者是应用程序的最终用户SaaS服务的一些例子是Gmail和Dropbox。除了这三种经典的服务模型之外，容器即服务（CaaS）产品也出现了，例如Google Kubernetes Engine [37]，Amazon EC2容器服务（ECS）[38]，Azure容器服务[39]。··应用中间件操作系统虚拟化服务器存储联网·问题位置9作为一种介于以基础设施为中心的IaaS和以应用程序为中心的PaaS之间的服务模型，CaaS是以容器为中心的，这意味着它提供容器作为应用程序的运行环境。与PaaS一样，CaaS也包含编排工具（例如， Kubernetes [40]，ApacheMesos [41]和Docker Swarm [42]）用于容器的部署和集群管理。此外，CaaS通常还提供容器映像注册表和API支持，以促进容器运行时的管理。无论如何，与PaaS不同，CaaS客户负责将其应用程序打包到容器中。这样做的一个优点是CaaS2.2.3PaaS/CaaS层和微服务PaaS和CaaS服务层与微服务有着内在的联系，因为它们提供了一种简单的方法来部署和运行微服务。在PaaS模型中，预期的用户体验是PaaS客户只负责他们的代码。在CaaS层，客户也有责任打包他们的代码，但部署由CaaS层负责。总的来说，这两层都负责安装、配置和操作（例如，路由、监控、扩展）的应用程序。PaaS/CaaS层提供的典型基本部署操作如下：• 创建：安装微服务（下载其代码等）。• 编译：编译微服务start：启动一个微服务（启动一个或多个微服务实例）• stop：停止一个微服务（停止一个或多个微服务实例）scale：扩展微服务（添加或删除一个或多个微服务实例）更改：更改微服务• remove：卸载微服务如前所述，PaaS/CaaS层的主要功能是自动化应用程序部署。目前，几种PaaS解决方案（例如，Heroku、Cloud Foundry、OpenShift）提供了即推即部署功能。也就是说，消费者可以部署他们的应用程序与一个单一的推命令。···问题位置10特别是，PaaS/CaaS客户可以轻松地部署应用程序的多个实例，以实现其高可用性。在应用程序执行期间，PaaS解决方案确实负责维护已部署应用程序实例的健康状况。为此，PaaS解决方案监控应用程序实例的状态，并自动修复失败的实例。监控机制取决于应用程序类型。Web应用程序通常通过发送周期性请求并期望在超时内响应来监视没有连接的应用程序通过检查其进程的运行状态来监视。PaaS客户可以配置修复策略（例如，重启）。PaaS/CaaS层的另一个常见功能是管理应用程序的扩展（虽然PaaS可以以自主方式管理可扩展性，但这对于CaaS层来说还不是真PaaS客户可以通过配置实例数量来横向扩展其应用程序当实例数量发生变化时，PaaS负责部署或删除实例。PaaS客户还可以垂直扩展所有实例的磁盘几种PaaS解决方案（例如，OpenShift、GAE）支持根据应用程序工作负载自动扩展缩放策略通常基于一组规则和一些应用程序度量（例如，CPU利用率、请求速率、响应延迟）。此外，PaaS层通常自动化应用程序的网络管理。PaaS客户可以配置一个或多个URL来访问应用程序。然后，PaaS解决方案负责将客户端的请求从这些URL路由到相应应用程序的运行实例。PaaS解决方案还可以提供跨多个应用实例的内置负载平衡。例如，Cloud Foundry以循环4的方式引导请求。为了支持更复杂的路由策略，PaaS客户可以使用外部路由服务。总而言之，尽管PaaS/CaaS解决方案使用不同的实现技术，但有几种常见的功能（例如，部署、复制、健康检查、扩展和网络管理）在大多数流行的PaaS/CaaS解决方案中提供。它们为管理微服务的每个方面（通常建模为微服务属性）提供基本操作由于微服务由PaaS/CaaS层管理，因此它们自然会从这些功能中受益。3根据具体情况，PaaS可能会迁移或重启应用程序实例4Round-robin是指路由器将给定路由的每个客户端请求依次转发到每个应用实例。问题位置112.3持续交付作为一个软件开发规程，持续交付指定了将每个应用程序更改发布到生产中的能力。在敏捷开发中，持续交付是一个关键的要求。如果没有向最终客户交付小而频繁的版本的能力，敏捷开发的好处就不能完全实现。这一要求导致了DevOps团队的概念，该团队由开发人员和管理员组成，或者至少是可以完成这两项工作的人，以实现持续交付。完整的交付过程包括构建可部署的包，在越来越类似于生产的环境中部署和测试它们，最后部署到生产环境中。为了提高时间效率并避免人为错误，DevOps团队需要自动化这个交付过程。当前的最佳实践是将交付过程建模为部署管道[43]。有几个流行的工具可用于设置部署管道，例如Jenkins [44]，Concourse [45]，GoCD [46]。管道工具通过定义步骤和这些步骤之间的连接，提供了构造可重复流程的实用程序每一步都是一个具有指定输入、输出和属性的基本作业。管道工具支持步骤之间的多种类型的连接这些步骤可以在成功完成前向依赖步骤后立即自动开始，或者在人工批准后手动图2.2展示了一个典型的部署管道。该管道自动检测应用程序的代码更改，当检测到更改时，它从Git服务器检索代码，构建镜像，执行自动测试，如果测试通过，则将镜像并行部署到两个PaaS站点，最后执行手动测试以验证部署。图2.2：部署管道的示例管道工具为DevOps团队提供了流程执行的可见性和管道通常提供图形界面来可视化流程执行的进度。此外，它还显示了过去的步骤是失败还是成功。DevOps团队可以在执行过程中启动、暂停和停止管道。DevOps团队还可以定义故障情况下的自动化行为（例如，停止5持续部署是一个更具约束性的建议，它要求每个应用程序更改都自动部署到生产环境中问题位置12流水线、重试当前失败的步骤和/或继续以下步骤）。问题位置132.4动机和目标为了突出这篇论文的动机，本节描述了DevOps团队必须完成的工作来更新微服务。然后阐述了本文的研究让如第2.2.3所述，每个PaaS/CaaS6解决方案都提供了基本的重新配置操作，用于播放微服务的直接就地更新因此，基于PaaS操作和管道工具，自动化此类更新需要以下工作：编写一个简单的脚本来调用正确的PaaS操作，在管道工具中指定脚本的执行环境，并将管道配置为在检测到代码更改时触发。到目前为止，这项工作非常简单，依赖于PaaS解决方案提供的基本在更新脚本的实现中，DevOps团队需要注意一个事实，即微服务的配置将随着时间的推移而演变。更新脚本不应对此类配置进行特定假设此外，如果可能的话，更新脚本可以用于更新各种微服务。因此，重要的是要遵循一个良好的实践，包括仔细地将所有微服务特定的配置与部署脚本分开，以便脚本可重用于各种微服务，并且更容易维护。在实现了一个脚本自动更新一个站点上的单个微服务之后，DevOps团队需要考虑多个站点的更新。一个原因是DevOps团队可能需要在多个类似生产环境的环境中部署和测试更改，然后再将其部署到生产环境中。此外，生产环境通常包含多个站点，以实现高可用性和更好的性能。重要的一点是，这些站点可能使用异构PaaS解决方案。在异构PaaS上部署微服务避免了供应商锁定，并允许每个微服务独立选择最合适的平台。因此，DevOps团队在更新微服务时需要能够应对不同的PaaS解决方案。同时，DevOps团队还需要考虑不同站点上多个微服务的更新。虽然微服务应该有一个独立的生命周期，但实际情况却截然不同。在应用程序的发展过程中，微服务之间的契约此外，多个微服务的自动化更新可以促进初始部署和拓扑更改。6本文档的其余部分使用术语PaaS来表示PaaS/CaaS，以简化表达式。问题位置14此外，在更新时需要考虑两个重要且具有挑战性的需求任何部署或更新都可能受到各种功能（例如，仅支持单个实例运行的微服务）和非功能性的（例如，最小停机时间、有限的资源成本）约束。如第2.2.3所述，PaaS解决方案提供的重新配置操作这具体意味着微服务更新将停止运行旧版本的微服务实例，安装新代码版本，并重新部署新版本实例。因此，微服务在更新期间无法满足任何客户请求。当由于QoS约束而不允许停机时，DevOps团队遵循复杂的部署模式来更新正在运行的微服务。这些模式称为更新策略，如本文前面所述。例如，为了以最小的停机时间进行更新，De-vOps团队可以选择BlueGreen策略[1]。BlueGreen策略通过在删除旧的微服务实例之前部署新的微服务实例，以零停机时间更新微服务。然而，蓝绿策略在更新期间消耗了近两倍的资源。为了降低资源成本，DevOps团队可以选择金丝雀策略[2]。金丝雀策 略不 需要 额外 的 资源 ，通 过 增 量 地 处 理 就 地 更 新 （ 例如 ，实 例（instance）。在这些策略中，通过操纵微服务的多个版本的生命周期、可访问性和实例数量DevOps团队在非功能性约束的这些维度在实践中，尽管DevOps团队不难理解更新策略的想法并选择合适的更新策略，但策略的实现通常很麻烦。实现需要正确控制和协调多个站点上的多个微服务此外，更新过程以及更新策略必须解决在更新时发生的故障的情况总的来说，上面描述的DevOps团队的工作表明，通过基于每个应用程序脚本的方法实现和维护自动更新是具有挑战性和容易出错的。这是- sis努力自动更新过程中的应用程序无关的方式。换句话说，为了实现微服务的持续交付，本文的目标是提出一个框架，用于有效和安全地更新部署在异构PaaS平台上的微服务该框架旨在支持各种PaaS平台、各种更新策略和各种故障修复操作。问题位置152.5挑战如第2.4节所述，本文旨在提出一个框架来自动更新部署在分布式PaaS站点上的微服务要解决的挑战主要来自四个维度的更新过程的多样性：更改类型，PaaS解决方案，更新策略和失败案例。第一个挑战是支持各种变化。在应用程序更新中可能会执行不同类型最常见的更改涉及微服务的代码和/或配置。DevOps团队通常每天都会对代码和/或配置进行多次更改。架构变更意味着更新微服务之间的契约（如访问接口）。架构更改的交付不常见，但更为复杂。这些更改通常涉及多个微服务的更新，需要更新操作之间的协调。拓扑变化与不同PaaS站点之间的微服务迁移有关。它们的处理涉及站点之间的协调。第二个挑战是处理异构PaaS解决方案。每个PaaS解决方案都提供其特定的微服务模型和管理操作。因此，如果更新过程的自动化直接基于PaaS操作，则需要为每个PaaS解决方案重新实现。使用统一的PaaS接口可以使自动化工作可重用于不同的PaaS解决方案。但是，此选项要求建议的接口与各种PaaS解决方案兼容。除了在异构PaaS站点上部署各种更改之外，另一个挑战是支持任意更新策略。原因是不同的更新可能会施加不同的非功能性约束。例如，安全补丁需要尽快交付，而实验性特征可能交付缓慢（例如，首先仅交付给小部分客户，然后传播给公众）。因此，除了提供现有的流行策略外，更新框架还需要允许DevOps团队自定义自己的策略。最后，框架需要适当地帮助DevOps团队管理（即，检测、修复）更新期间的故障。 当更新时发生故障时，失败的更新过程会让微服务进入任意状态。困难在于帮助DevOps团队修复故障源（例如，断开的网络，损坏的服务器或错误的微服务代码），并允许受影响的微服务快速恢复功能状态。虽然目前还无法实现自动修复所有故障的魔力，但常见修复操作的自动化可以大大加快修复速度，并减少进一步的人为错误。总之，框架需要自动更新多个