英语原文共 30 页，剩余内容已隐藏，支付完成后下载完整资料
使用运行时放置适配来改进基于微服务的应用程序
1.介绍
随着业务逻辑进入云，开发人员不仅需要协调部署云资源代码，还需要在云平台上分配代码。云提供商提供即用即付的资源弹性，以及几乎无限的资源，如CPU，内存，磁盘和网络带宽。然而，对这些云资源的管理是一项重大挑战，从而带来了DevOps工程师等新角色。 在这种情况下，微服务已成为提供必要的部署灵活性并同时利用丰富资源的重要机制。
微服务是一种解耦的自主软件，在有界的环境中具有特定的功能。 解耦和明确定义的接口提供
基于微服务的应用程序（mu;Apps）能够无缝扩展/扩展，并允许开发人员通过部署新服务版本来执行升级，所有这些都不会停止mu;APP。去耦还允许使用不同的编程语言开发微服务器。
尽管服务和微服务之间存在许多相似之处[2]，但存在一些根本差异，主要与执行有关。 像WS-BPEL1这样的语言描述了服务组合的工作流程。 相比之下，mu;App工作流程未正式指定。 必须监视mu;App通信以推断基础工作流。
使用微服务的缺点是它们的管理复杂性。 微服务在执行时可能会有不同的行为，这反映在资源使用的波动性和工作流程的变化中。 因此，初始的mu;App部署选择，如微服务的放置，日后可能会失败。
mu;Apps的管理由工程师协助执行，这些工具提供有关应用程序（例如，资源使用）和微服务生命周期管理（例如，按需复制微服务）的及时数据。 但是，这些管理工具无法提供关键的运行时数据，例如两个微服务之间交换的数据量或给定微服务的资源使用历史。 因此，现有工具无法根据实际执行数据执行管理操作，如更换微服务。
在运行时，组成应用程序的微服务可以交互并交换大量数据，从而创建通信亲和力[3]。 我们将亲缘关系定义为两个微服务之间的关系，这些微服务由随时间交换的消息的数量和大小给出。 这些服务间亲和力可能对mu;App的性能产生重大影响，具体取决于微服务的位置，例如，由于较高的通信延迟，在不同主机上具有高亲和力的微服务将具有较差的性能。 使这种更复杂的事实是亲和力在运行时发生变化。
除了亲和力，开发人员还必须考虑微服务的资源使用历史，以优化mu;App位置。 例如，具有高资源使用历史的微服务不应共存于同一主机上。此外，mu;App执行中的服务升级和不同工作流程会改变资源消耗和亲和力。
现有的管理工具，如Kubernetes2和Docker Swarm3允许DevOps工程师通过在微服务器上设置资源阈值来控制mu;Apps。管理工具使用此信息来决定何时扩展/缩小每个微服务以及放置微服务副本的位置。在运行时，管理工具不断将微服务的即时资源使用情况与其资源阈值进行比较。当资源使用率达到限制时，管理工具将启动扩展操作。在横向扩展期间，现有管理工具会根据设置的阈值而不是资源使用历史选择放置微服务副本的主机。正如我们的实验所示，在大多数情况下，资源阈值是不现实的，导致mu;App浪费集群资源或由于资源争用而失去性能。
管理工具应该了解运行时和mu;Apps的历史数据，以避免错误的微服务。虽然这些工具可以使用即时数据来执行放大/缩小活动，但在需要重新安排微服务的情况下，这还不够。因此，我们提出了一种新工具，它使用历史记录和运行时数据来更好地管理微服务。
我们的工作重点是通过使用运行时数据作为自动管理任务（如布局优化）的基础来改进mu;Apps的管理。
接下来，我们将概述实现mu;Apps自适应的三个挑战：
- 挑战1：统一监控mu;Apps。现有管理工具可以从执行mu;Apps收集和公开许多资源指标。但是，每个mu;App都使用自己的监控堆栈。监控选项的多样性产生了语义挑战，需要单一的统一数据模型。
- 挑战2：寻找高效的展示位置。通常使用诸如可用主机资源之类的静态信息来放置微服务。但是，此策略可能会通过在不同主机上放置高亲和力微服务或通过将资源使用率高的微服务共同定位来降低mu;App性能。因此，有必要找到将微服务映射到服务器的最佳性能配置。这种需求导致两个子问题：（1）大量配置：有n个服务器和m个微服务，有mn可能的配置; （2）a的表现mu;App配置动态变化。
- 挑战3：迁移微服务。现有的微服务管理工具不提供在主机之间执行微服务的实时迁移的替代方案。此迁移对于提供无缝的运行时调整是必要的。
我们的提议是一个名为REMaP（RuntimE微服务放置）的适应机制，它解决了上述三个挑战，并使用它们的亲和力和资源使用历史自动改变微服务的位置，以优化mu;App配置。 在我们之前的工作[4]中，我们通过定义支持mu;Apps演变的模型来考虑挑战1。 在这项工作中，我们改进了所提出的想法[4]解决挑战2和挑战3.这项工作的核心是解决挑战2.我们提出了关于mu;Apps的运行时适应性和最佳安排微服务的挑战的观点。 最后，在这项工作中，我们部分地解决了挑战3。
REMaP方法概述。我们的解决方案使用基于MAPE-K的[5]自适应管理器来自动改变mu;Apps在运行时的位置。REMaP使用Models@run.time概念并抽象监控堆栈和管理工具的多样性。通过这种方式，我们的解决方案提供了集群和在适配管理器下运行的mu;Apps的统一视图。
REMaP在同一物理服务器上对具有高亲和力的微服务进行分组和放置。这种策略与现有的静态方法形成对比，后者依赖于工程师在mu;App部署之前提供的信息。例如，Kubernetes根据资源限制（最大和最小）以及工程师设置的标签在集群中安排微服务。 Kubernetes没有考虑有关微服务之间关系的信息，通过减少要使用的主机和微服务之间的通信延迟来改进mu;App的部署。因此，我们的适应管理器可以根据实际的微服务资源利用率来提供资源，避免mu;App执行期间的资源争用/浪费。此外，微服务的协同定位降低了网络延迟对mu;App工作流程的影响，从而提高了整体应用程序的性能。在调整结束时，mu;App具有优化配置，与未优化部署相比，可减少执行mu;App所需的主机数量并提高其性能。
之前的工作重点是调整mu;Apps，以便在运行时更改mu;App部署以提供运行时扩展[6]或将正在运行的部署更新到新版本[7]。在制定适应性时，这些方法不会改善组成微服务的位置，也不会考虑资源使用历史。这些工具使用从mu;App收集的即时指标，这些指标无法在较长时间段内反映其实际资源需求。
我们在两种情况下评估了REMaP，并且我们比较了基于SMT（可满足模理论）[8]的优化算法的结果以及First-Fit算法的简单变化[9]。考虑到问题的复杂性，我们进行了这种比较以评估找到最佳放置而不是近似的可行性。在第一个场景中，我们使用所提出的机制来计算合成应用图的适应性，具有不同数量的微服务和亲和度。在这种情况下，我们实现了适应性，节省了mu;App最初使用的大约80％的主机。此评估表明，我们的方法在具有密集拓扑的mu;App上产生更好的结果。此外，当使用SMT时，适应机制无法在大于20个微服务的mu;App上工作。因此，尽管我们的启发式算法无法保证最佳结果，但它可以计算任何大小的mu;Apps的位置。
在第二种情况下，我们使用REMaP来调整在Azure上运行的参考mu;App4。在这种情况下，我们实现了高达62％的性能提升
最多可保存初始部署中使用的主机的40％。此外，我们发现使用相同数量主机的不良放置可能会使mu;App的整体性能降低150％，表明放置需要工程师特别注意;关心我们的方法自动化。
本文的其余部分安排如下。第2节介绍了理解本文其余部分所必需的概念。第3节讨论了微服务的通用运行时适配的挑战。在第4节中，我们通过在运行时重新配置微服务放置来讨论适应mu;Apps的具体挑战。第5节和第6节分别介绍了我们解决方案的设计和实现。第7节介绍了对拟议方法的评估。我们将与第8节中的相关工作进行对比。最后，第9节总结并指出了未来研究的一些途径。
2.背景
2.1微服务
微服务模式是面向服务的计算的架构风格，其基石是高度的解耦[10]。微服务是一种自动且松散耦合的软件，在有限的上下文中具有特定的功能。如图1所示，属于基于微服务的应用程序（mu;App）的微服务（六边形）使用轻量级通信协议（如HTTP）进行通信。这些微服务通常部署在容器中，是传统虚拟机的轻量级替代品[1]。容器的使用有助于mu;App的弹性：只有一些部件，而不是整个应用程序，需要扩展和收缩以响应不断变化的工作量。例如，假设与订单相关的微服务比圣诞销售期间与注册相关的微服务具有更高的负载。在这种情况下，只需要扩展第一组元素以避免瓶颈，而其他元素可以收缩并释放资源以供其他组件使用。单行应用程序中不提供此行为。
图1显示了Sock-shop的设计，这是一种基于微服务的参考应用[11]。 Sock-shop采用mu;Apps中的良好实践，例如由微服务和容器包装的数据存储和通信中间件（例如，RabbitMQ），其为mu;App提供灵活性。袜店由六个微服务（前端，订单，用户，推车，目录和运输），它们各自的数据存储和辅助微服务组成。
微服务提供的解耦通过降低升级和复制等管理任务的复杂性，有助于mu;Apps的可维护性。 微服务的使用通常会增加构成应用程序的组件数量并使应用程序管理变得复杂。 更糟糕的是，mu;Apps的一个基本特征是它们可以根据需要通过删除/创建副本来扩展/缩小。 这个事实导致微服务实例的生命周期很短并且增加了 部署的进一步活力和复杂性。
Fig. 1 Architecture of Sock-Shop a reference mu;App
尽管服务和微服务之间存在许多相似之处[2]，但存在一些根本的差异。开发人员使用WS-BPEL [12]等语言来定义基于服务的应用程序的工作流程，并使用引擎来执行工作流程。相比之下，组成mu;App的微服务交换的消息流定义了工作流。因此，有必要改变至少一个微服务以修改mu;App的工作流程，例如通过替换它。因此，需要更加谨慎地发展mu;App。
mu;App工程师使用管理工具（如Kuber- netes）自动控制mu;App。与自主应用程序不同，自治应用程序的管理需要最小化或无人为干预，微服务管理工具需要工程师来指导管理任务。这些工具可以按照工程师的指示自动更新和升级mu;App，例如，扩展输入/输出或推出/返回微服务器。通常，工程师设置mu;App应具有的最大和最小副本数，以及触发扩展过程的资源阈值。此外，管理工具通过考虑工程师在部署时设置的属性，自动将微服务部署到集群上。但是，此放置不是最佳的，并且在某些情况下可能会危及mu;App的执行。
2.2自主计算
自主计算是指自我管理计算系统[13]。自我管理意味着系统可以自我控制，并且人工干预对于优化，修复，保护和配置等活动不是必需的。
自我管理系统必须监控自身和环境，分析监控产生的信号，并应对措施，可能通过修改自身。这些步骤无限重复作为控制循环。 IBM通过提出一个名为MAPE-K的自动控制回路的参考模型来系统化这个循环[5]（图2）。
在MAPE-K中，监视器从受管系统收集数据并将其分派给分析器，分析器对其进行推理或推断出新信息。接下来，分析器将分析结果转发给计算适应或管理计划的计划员。执行程序接收计划并将其应用于受管系统。最后，MAPE-K的组件共享知识库，该知识库维护规则，属性，模型和其他类型的数据，用于指导如何为下层系统提供自治。
Szvetits和Zdun [14]和Krupitzer等人。 [15]调查了几种适应复杂，异质和动态系统的策略，这些系统没有将适应计划直接应用于管理系统。在这种情况下，适应计划适用于在运行时维护的模型（model@run.time）[16]。 model@run.time抽象系统，简化了适应过程，有助于处理底层技术的多样性。该模型与受管系统存在因果关系，因此应用程序的更改会反映在模型中，反之亦然[17]。因果关系由元对象协议（MOP）执行，该协议将模型的元素映射到应用程序中的表示。
Fig. 2 MAPE-K reference model
3.微服务运行时调整的挑战
运行时调整是mu;Apps固有的，它可以在执行期间发展。微服务架构风格提升的解耦允许在运行时进行更新和升级，而无需暂停或终止应用程序。扩展/输出操作通常会更新mu;Apps，而推出/返回操作会升级微服务版本。
在我们的上下文中，适应包括（1）将一个微服务实例替换为另一个，通常在不同的主机上，或（2）创建新的微服务复制。管理工具执行这样的调整。然而，工程师使用这些工具并手动指导适应。例如，工具可以自动触发自动缩放，但工程师必须同时修复最大数量的副本和触发扩展的资源使用情况。在自主方法中，自适应机制将自动决定这些参数。
尽管需要额外的机制来安全地更改mu;App，但mu;App的高度去耦有助于自适应。例如，在更换微服务时，新实例可能会在短时间内变得不可用。在此期间，其他微服务可能会尝试建立通信，并在新实例未准备就绪时失败。
除了适应期间的故障，在正常的mu;App执行期间也会出现故障。今天的开发人员使用设计模式，如断路器5和重复指数后退[18]，以最大限度地减少故障对mu;App的负面影响。
在运行时，另一个缺陷来源是微服务的有状态性质。当新的微服务必须替换旧的微服务时，管理工具无法自动同步其数据。通常，替换微服务的关键步骤是（i）实例化新实例和（ii）删除旧实例。因此，当更新有状态微服务时，需要一种机制来处理状态同步。
最后，mu;App可能是多语言和多技术，这使监控变得复杂。尽管监视工具可以从mu;App执行（例如，瞬时资源使用）收集信息，但是现有工具不收集行为方面（例如，资源使用历史和mu;App工作流）。
3.1监控mu;Apps
有必要跟踪mu;App的行为来控制它。 拥有
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[441547]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
