SWITCH工作台：一种用于开发和部署基于微服务的时效性云原生应用的新方法

波洛娜·斯特凡尼奇*a，马泰伊·齐加莱a，安德鲁·C·琼斯a，路易丝·奈特a，伊恩·泰勒 a，克里斯蒂安娜·伊斯特定b，乔治·苏奇乌b，亚历山大·乌利塞斯c，弗拉多·斯坦科夫 斯基d，萨尔曼·塔赫里扎德d，瓜达卢佩·弗洛雷斯·萨拉多e，斯皮罗斯·库卢齐斯f，保 罗·马丁f，赵志明f
a卡迪夫大学，计算机科学与信息学院，英国 bBEIA咨询公司国际部，罗马尼亚 cMOG技术公司，葡萄牙 d卢布尔雅那大学，斯洛文尼亚 e健康 电信公司，西班牙 f阿姆斯特丹大学，荷兰

摘要

时间关键型应用（如预警系统或现场活动直播）面临着特殊挑战。尽管存在网络波动和负载变化峰值，这类应用对服务质量约束有着严格的限制要求，必须持续满足。因此，此类应用必须能够按需弹性适应，并具备自我重构能力，同时对其底层云基础设施进行重构以满足其约束条件。当前的软件工程工具和方法论尚不支持这种范式。本文介绍了作为欧盟 SWITCH项目一部分而设计的一个框架。SWITCH提供了一种灵活协同编程架构，包含一个抽象层和底层基础设施环境，有助于定义并支持时间关键型云原生应用的生命周期。我们描述了SWITCH组件的架构、设计与实现，并阐述了这些工具如何应用于三个时效性真实世界用例。

∗通讯作者电子邮件地址：StefanicP@cardiff.ac.uk(Polonaˇ Stefaniˇc*)

关键词：

时间关键型应用,协同编程模型,基于组件的软件工程,服务质量,用户体验质量,图形化服务建模

1.引言

许多工业实时关键应用，如灾害早期预警系统、视频会议、在线游戏 或现场活动直播，对其性能具有极高的时间关键性要求，并为成功开发、 部署和维护带来了特殊挑战。只有在满足时间关键性要求（如高性能、可 移植性、可用性、弹性和响应性）的情况下，这些应用才能实现预期的商 业价值和显著的社会影响。此外，它们还必须能够预测并应对（不可预见 的）负载高峰，并提供按需计算资源的快速弹性以及底层云基础设施的可 重构性，以满足期望的服务质量（QoS）（如低响应时间和抖动）和用户 体验质量（QoE）（如超高清电视信号传输）的约束。

时间关键型应用通常涉及分布式组件和密集的数据通信，并可能包含 部署在不同地理位置的远程现场传感器。然而，由于对虚拟运行环境有较 高的需求，以及需要复杂的优化机制来集成系统组件并实现整个应用的资 源供给，这类应用的设计、开发和部署通常困难且成本高昂。云生态系统 提供了弹性、可控且按需的服务，能够支持复杂的时间关键型应用。但目 前仍缺乏支持此类应用开发、部署和执行的软件工程工具与方法，这些工 具和方法应能利用云所提供的可编程性和可控性。因此，时间关键型应用 无法充分获得基于云技术的全部潜在优势。为此，有必要引入新型软件工 具和方法，以全面支持时间关键型应用的整个生命周期，通过提供可控和 可编程的功能（如（图形化）应用逻辑与工作流建模、基础设施规划与配 置等），实现服务质量的增强与优化。

因此，我们的研究目标是通过设计一种应用程序‐基础设施自适应机制来 确保自适应性、可扩展性、服务可用性和弹性

2.相关工作

SWITCH并不是一个孤立的项目；还有其他一些团队正在研究相关 问题，涉及应用程序组合、系统和工作流的编排、部署与自适应。然而， SWITCH具有独特性，因为它专注于时间关键型应用，而这类应用在当 前的云生态系统中arguably是最难支持的。

2.1.基于云的框架和方法论

ARCADIA方法论[2]支持向多云的部署以及应用程序的自动实时重构。它依赖于软件组件的建模，以组合应用程序。尽管该框架提供编排、多云部署和拖放式服务图管理器，但不允许将额外的服务质量属性附加到组件上（例如服务质量约束、硬件需求等）；也不提供 TOSCA操作。

存在两种用于创建云应用和服务的服务建模工具。Juju[3]是一种面向服务架构和应用部署的基于组件的图形化建模工具，提供预定义的软件资产集合及其之间的关系，包含如何在云中正确部署和配置所选服务的知识。另一种工具是Fabric81,平台，该平台分别使用Docker和 Kubernetes作为虚拟化和编排技术，支持微服务的创建、部署和持续集成。然而，这两种服务建模工具均未针对时间敏感型应用程序提供特定的资源供给功能，也不提供基础设施规划与配置。

另一方面，MODAClouds[4]方法论支持在云中开发时间关键型应 用，但缺乏对软件定义网络的支持，无法通过编程和控制云基础设施来实 现性能优化；此外，它也不提供TOSCA操作和映射功能。最后， CloudWave[5]和SSICLOPS[6]方法论专注于应用程序和服务的运行时监控工具，使云服务能够适应其需求和环境的变化，并满足预期的质量约束。CloudWave方法论提出了一种云基准测试Web服务的架构与实施，然而，它仅测量并比较亚马逊EC2中不同实例和存储类型的磁盘速度，未考虑输入数据流对已部署的虚拟机或容器的动态特性，而这一点正是 SWITCH项目的需求之一。

Pegasus[7]包含一种架构和一系列技术，用于在各种环境（如云和 网格）中执行基于工作流的应用程序，方法是将科学领域预先创建的高级 科学工作流自动映射到其执行环境。类似地，ApacheAiravata[8]支持 在分布式计算资源上进行大规模应用程序和工作流的组合、执行和监控。

然而，在灵活性方面，Pegasus和阿伊拉瓦塔既不提供对任何编排规范 标准（例如TOSCA）的修改，也不支持容器化。由于缺乏对应用程序组合及底层架构的可编程性和控制能力的支持，它们不适合用于时间关键型应用。

MiCADO[9]云编排框架研究了如何将自动编排应用于云应用。该框架采用TOSCA作为编排标准，但不支持将服务质量（QoS）表示映射到 TOSCA中，例如基于组件的硬件需求、环境变量（这是SWITCH的一个 重要需求）。

2.2.云基础设施相关的资源供给方法

确保实时云系统的高服务质量需要专门的基础设施[10]。基础设施可编程性和先进的虚拟化技术，如软件定义网络（SDN）[11]和网络功能虚拟化（NFV）[12], ，在基础设施管理和功能部署方面提供了良好的灵活性[13]。时间关键型需求可能仅涉及速度，例如最小化延迟，或抖动，例如确保延迟保持一致[14]。对于定制化的基础设施规划和优化，多目标优化等技术[15, 16]可以更有效地将应用程序需求映射到基础设施资源。随后可用于识别服务等级协议（SLA）[17]的违规情况。例如，可通过媒体应用程序工作流中关键路径上的截止时间来选择虚拟机[18],，并跨多个站点自动进行资源供给[19]。然后可以高效地将应用程序数据传输调度至最佳站点[20, 21]。

Toosi等[22]提供了一种（联邦式）云计算环境的分类法。为了实现更智能的基础设施规划与监控，可能需要对基础设施和网络进行语义建模。

例如，MADL[23]使用本体来描述用于高清媒体存储、传输和显示的基础设施；INDL为可编程网络和基础设施提供了本体[24]。此类模型可用于扩展云系统规范标准，例如TOSCA[25]。NDL‐OWL[26]为网络化云编排提供了语义网模型，用于建模网络拓扑、层次、功能和技术；它在 INDL所基于的网络描述语言基础上进行扩展，并使用OWL。高效的资源供给对于提升运行应用程序的服务质量至关重要。因此，各种优化方法具有高度

2.3.自适应与监控相关方法

大多数自适应研究集中在为使用异构基础设施但同构组件的系统寻找解决方案。例如，A.亚尼斯et al.[27]开发了一个系统，用于在异构基础设施上平衡蚁群优化任务。P.贾姆希迪et al.[28]提出了一个基于模糊逻辑的系统，而vPerfGuard[29]团队开发了一个能够基于低层指标预测性能的系统。

云应用不仅受基础设施性能的影响，子系统之间的网络特性也起着关键作用，正如D.克里亚佐维奇et al.[30]在其CA‐DAG模型中所指出的。在该研究中，作者提出了通信感知有向无环图（CA‐DAG），用于建模组件的性能以及组件之间的通信。

2.4.差距分析

SWITCH专注于使用建模图进行应用组合以及底层云基础设施的重新配置——通过描述功能性和非功能性需求。应用‐基础设施协同编程的概念基于根据网络和云环境情况实现快速基础设施供应、部署和可重构性。

除了应用组合外，还必须对应用程序进行监控，并根据软件开发者指定的标准对其进行调整。尽管SWITCH方法的一些元素在先前的研究和系统中已有体现，但SWITCH将这些元素整合在一起，为具有时间关键约束的应用程序提供了集成架构和应用‐基础设施协同编程环境。

3.应用‐基础设施协同编程的概念

在开发现代复杂系统时，有多位参与者参与其中。组件开发者是指创建或修改应用程序组件（例如数据库）的人员。他/她可以以预制探针或特殊的应用级指标的形式为这些组件添加监控。一旦组件创建完成，便可将其添加到仓库中，并在SIDE中描述其需求和功能。请注意，一个

组件开发者可以使用现有组件，并通过在SIDE中描述它，将其变为SWITCH组件。

应用开发者将这些预制组件绑定在一起形成一个应用程序，同时确定不同的属性，例如它们所属的网络或使用的端口，并设置其他参数，如警报触发器等。应用用户使用最终的应用程序。(他/她)可以监控该应用程序，并在系统以这种方式设置的情况下触发自适应。

应用‐基础设施协同编程模型（见图1）通过应用程序逻辑的可编程性和可控性以及底层基础设施的可重构性，提供抽象和机制，以支持整个时间关键型云应用程序生命周期中的服务质量。

可编程性是指系统使用指令（例如来自软件开发者的指令）改变其行为的能力。可控性是一种系统属性，表示测量系统的状态、操纵其输出节点以及监控/控制其行为。

在SWITCH工作台中，可编程性支持如下方式：（1）可以使用图形化建模图并结合应用程序的服务质量参数来编程应用逻辑；（2）可以使用DRIP中间件服务对虚拟运行时环境进行编程，以实现应用程序执行过程中的操控和可重构性

底层基础设施（例如软件定义网络）和按需资源；(3)提供可编程机制以实现时效性关键云应用的部署和自适应；(4)可服务质量属性也可通过编程方式创建并附加到组件上。相比之下，可控性是通过以下方式实现的： (1)在运行时监控时效性关键云应用及其底层基础设施的行为（例如，在运行时监控与应用程序及其当前状态相关的各种指标，并提供在服务质量受影响时影响/重新配置基础设施属性的可能性），以及(2)控制组件创建和应用逻辑的工作流（例如，通过应用验证机制来验证应用逻辑的正确性，以及验证应用逻辑映射所使用的TOSCA的正确性）。SWITCH会检查组件所需的所有约束是否已满足，并确保YAML描述有效。

3.1.协同编程与DevOps及软件定义网络的比较

DevOps[31]是文化理念、实践和工具的结合，可加快应用程序交付速度。它通过自动化软件开发与IT团队之间的流程，实现更快的构建、测试和软件发布。在DevOps流程中，应用程序的典型生命周期包括规划、构建、持续集成、部署与运维。有许多具体的工具和框架支持DevOps，例如Chef2和Jenkins3。另一方面，软件定义网络（SDN）提供了网络领域的抽象，并实现了网络配置的可编程性。这意味着网络应更具灵活性，能够适应快速变化。然而，这两种方法均未在整个应用程序生命周期中提供对应用逻辑或工作流的可编程性。

然而，应用‐基础设施协同编程模型在时间关键型应用的整个生命周期中，为应用逻辑的设计与开发以及虚拟云基础设施的规划与配置提供了可编程性和可控性。由SWITCH架构支持的协同编程模型具有独特的抽象性，旨在提高应用设计的生产力。

以及开发，改进了规划与配置和部署效率，并提高了服务质量控制效率。

协同编程将应用程序工作流和基础设施的控制权交给开发者，使其能够在开发过程中指定基于容器化微服务的组件或系统的约束条件，从而确保所开发的组件按照预期方式运行。这最大限度地减少了在创建、资源供给和部署过程中的错误发生几率。

4.SWITCH架构

本节介绍了SWITCH的架构及其三个子系统（SIDE、DRIP、 ASAP）（见图2）。SWITCH的设计理念是将SWITCH子系统部署在共享环境中，用于多个应用程序的开发。

4.1.SWITCH交互式开发环境(SIDE)

SIDE是SWITCH工作台的交互式图形用户界面。它提供交互式服务建模图，用于设计基于容器化微服务的云原生应用的应用程序工作流，并支持包括组件创建、应用组合、应用程序验证、基础设施规划、资源供给、部署和监控在内的各项任务（参见图3）。SIDE通过为开发者提供描述系统需求、约束和底层基础设施的选项，实现了应用程序与基础设施协同编程的概念。

SIDE前端4是使用EmberJS技术实现的图形用户界面，包含多个视图，例如组件创建视图和应用组合视图。建模图的实际创建使用JointJS库，并在其基础上构建Ember模型。

SIDE后端5使用Django框架。它与Ember模型进行交互，这些模型提供了如何呈现应用程序建模图的信息。应用程序的逻辑和工作流描述被映射为TOSCAYAML格式。基于Django的代码也会对应用程序进行验证，检查附加到组件上的服务质量参数是否正确组合，即是否能生成有效的 YAML文件，以及特定组件的所有必需参数（例如硬件需求，如CPU数量、内存容量等）是否已定义。后端通过调用DRIP和ASAP的API与其它 SWITCH子系统通信，并提供生成的TOSCA，其中包含了应用程序逻辑和工作流的映射。此外，SIDE后端接收用于规划与配置的返回TOSCA，并将其呈现给软件开发者或DevOps工程师。

从软件开发者的角度来看，SIDE支持通过在画布上拖放组件（例如，从DockerHub拉取的镜像创建的容器化软件），设置属性值，并将它们连接到特定组件，从而创建带有依赖建模图的系统详细规格说明（参见图 3）。此外，通过使用建模图，已创建的组件可以适当地相互连接，以定义完整的应用逻辑和工作流，从而描述整个

完整的云原生应用。可以添加系统及底层基础设施的规范。在将应用逻辑映射到TOSCA之前，需对应用组合进行验证和确认，以检查错误（例如缺失的QoS参数或相互连接的不兼容组件）。

超出项目目标的一项额外创新是定性元数据标记（QMM）的概念。这些标记适用于对软件组件进行建模，并已作为概念验证集成到SIDE中。它们能够揭示哪些时间关键性要求对服务质量（QoS）具有最大影响。一个QMM提供概率信息，显示哪些参数与特定软件组件的服务质量具有最强的相关性[32]。根据该信息，可以将时间关键性要求纳入进一步分析，因为它们对应用程序的服务质量至关重要。对整个云应用程序服务质量影响最大（正面或负面）的时间关键性要求可在中间件服务之间交换，并被发送至多准则决策模块。时间关键性要求通常相互冲突：调整一个参数通常会对其他参数产生重大影响。例如

例如，提高应用程序的可用性需要增加系统冗余，这可能导致较高的运营成本。在多个应用程序运行时参数之间选择最优的权衡可能是一个耗时且容易出错的过程，尤其是在考虑复杂的多云环境时。我们提出的新方法可以帮助软件工程师在决策过程中，根据定义的相互冲突的目标（如响应时间、货币成本等）[16]，将虚拟机实例的数量缩减至最优数量。然后可将应用程序组件部署到这些实例上。

4.2.动态实时基础设施规划器（DRIP）

DRIP6是一个开源服务套件，用于自动规划和配置联网的虚拟机（ VM），部署应用程序组件，并在运行时管理所生成的基础设施。DRIP提供了一种整体性方法，以实现资源优化并满足应用级约束，例如截止时间和服务等级协议（SLA）。DRIP可在多个云服务提供商之间配置虚拟基础设施，并可用于按需启动、停止和恢复应用程序组件的执行。特别是，通过使用开放云计算接口（OCCI），DRIP能够在多个云上进行资源配置，并支持多种编排系统，如DockerSwarm和Kubernetes。这些功能对于应用‐基础设施协同编程至关重要，使应用开发者能够构建满足其需求的系统。

DRIP服务（如图2所示）包括： 一个基础设施规划器，一个知识库
•基础设施配置器，•部署代理，• DRIP管理器
•基础设施控制代理，•内部消息代理。

基础设施规划器采用改进的部分关键路径算法，通过选择高性价比的虚拟机并定制虚拟机之间的网络拓扑，根据应用程序工作流和约束生成高效的基础设施拓扑。基础设施配置器能够将规划器生成的基础设施方案自动部署到底层基础设施上；它可分解基础设施描述并进行资源配置。

它跨越多个数据中心（可能来自不同的提供商）进行部署，并实现透明的网络配置[19]。部署代理将应用程序组件安装到已供给的基础设施上。部署代理能够根据网络瓶颈情况调度部署顺序，并最大程度地满足部署截止时间[21]。基础设施控制代理是一组DRIP提供的API，供应用程序用于控制容器或虚拟机（VMs）的扩展以及调整网络流量。DRIP管理器是一种 Web服务，允许外部客户端调用DRIP功能。每个请求均由管理器定向到相应的组件，管理器负责协调这些组件并在必要时对其进行扩展。资源信息、凭据、性能配置文件和应用程序工作流均通过内部的知识库进行内部管理。

供应器的默认资源供给接口是OCCI；目前支持AmazonEC27, EGIFedCloud8和 ExoGeni9云。部署代理可以在Docker集群（例如DockerSwarm、Kubernetes）上进行部署，并能基于Ansible剧本10部署定制的应用程序。

DRIP需要软件开发者提供应用描述，以确定要部署的特定组件及其要求、依赖关系和约束。这必须辅以来自云服务提供商的基础设施资源信息（例如虚拟机类型和网络带宽）。当规划请求从SIDE（由软件开发者发起）到达时，基础设施规划器生成一个计划，该计划由DRIP发送给 SIDE并提交给软件开发者确认。经确认的计划随后可交给供应器，并在必要时由用户提供的云凭证（如果尚未存在于DRIP的知识库中）一同使用。DRIP通过所选云服务提供商提供的接口来供给已规划的基础设施。

然后，部署代理从指定的仓库将所有必要的应用程序组件部署到已供给的基础设施上，并建立对应用程序和基础设施进行运行时控制所需的控制接口。

4.3.自主系统自适应平台(ASAP)

ASAP提供运行时自适应，因此需要一个稳定且可修改的监控系统，该系统可通过添加额外功能进行扩展，从而能够通过增加额外组件、可视化系统状态以及更改系统基础设施来动态改变系统特性。ASAP专注于自动伸缩，并支持在多云环境中的地理编排，以及多实例和多租户操作。

ASAP子系统（见图2）包括：
•监控探针,
•监控代理,
•监控服务器,
•告警触发器,
•时序数据库,
•知识库，
•信息服务，
•性能诊断器，
•自适应器，以及
•控制代理。

第一步，监控探针和代理的目的是收集代表应用程序和基础设施当前状态的数据，然后将测量值聚合并传输到监控服务器和告警触发器。监控探针具有轻量性、可扩展性，并且本质上是去中心化的。它们能够从高级探针中收集非结构化数据，例如请求处理时间。

多个组件。监控服务器接收收集的数据，并将其存储在时序数据库（ TSDB）中，以构建系统状态的全面表示。性能诊断器利用存储在TSDB中的信息构建用于评估性能的模型。该模型的设计目标是能够识别出需要纠正措施的问题。同时，告警触发器会检查被监控参数的测量值是否超过相应的阈值。当检测到问题时，自适应器将被调用，以提出合适的自适应策略。该组件为控制代理指定一组自适应操作，使整个系统能够从当前状态过渡到期望状态。控制代理拥有对应用程序配置和基础设施资源（例如虚拟机/容器和网络带宽）的完全控制权，最终执行自适应操作[33]。这些操作可以自动化地重启发生故障的单个组件或一组组件、添加一个新的组件实例，或将组件迁移至另一个（可能是全新的）虚拟机。

为了简化开发，创建了一个适配器，用于将JCatascopia[34] 消息发送到监控服务器，而无需使用原生的监控代理。该适配器使用StatsD11从基础设施中收集指标，并将其传输给JCatascopia服务器。基础设施级指标由ASAP收集，并以与应用级指标相同的方式进行处理。CPU、磁盘和内存使用情况等信息由探针收集，并发布到指标组中（例如 ‘CPUProbe’、’DiskStatsProbe’和’MemoryProbe’）。

4.4.TOSCA作为SWITCH协同编程语言

三种SWITCH子系统（SIDE、DRIP和ASAP）之间需要交换一系列数据，例如用户需求、应用逻辑、应用程序在部署、执行和运行时的时间关键约束等。因此，SWITCH需要一种合适的语言来定义和序列化此类信息概念。TOSCA编排规范标准在SWITCH中作为应用‐基础设施协同编程语言，其作用是提供一种格式，用于存储可编程逻辑（如依赖建模图）以及相关元数据（如应用程序质量约束的信息），并要求

容器化软件组件之间的组件和依赖关系。

TOSCA中应用逻辑描述和工作流的核心是服务模板，它由拓扑模板和管理计划组成，如图5所示。拓扑模板定义了应用程序的结构，而管理计划则定义了用于存储应用程序在运行时创建和终止信息的流程。拓扑模板是一个有向图，包含节点模板（顶点）和关系模板（边）。节点模板包含属于该应用程序的所有（容器化）软件组件的描述。节点模板之间的链接、依赖关系和关联由关系模板定义。节点模板和关系模板分别由节点类型和关系类型进行类型化。类型定义了模板的语义、属性、可用的管理操作等。由于TOSCA基于YAML，其类型可以轻松地进行细化或扩展。在 SIDE中，数据以类似方式编辑，数据映射到TOSCA（图6(B,C)）。可在图6(A)中看到可被监控并设置告警的服务质量约束示例。

在将建模图中的应用逻辑和工作流映射到TOSCA时，带有服务质量参数信息的容器化软件组件（如硬件需求（中央处理器、内存等）、服务质量约束（响应时间）、端口映射、环境变量等）被映射为节点类型。可编程和所需的服务质量参数

与构建云原生应用程序的软件组件之间的特定组件和依赖关系相关联的信息被存储到关系类型中。

此外，拓扑模板中不同节点模板之间的有向图，以及为每个节点模板定义的属性和约束（例如截止时间），被用作DRIP规划器和供应器的输入，以获得部署应用程序所需的底层虚拟基础设施。应用程序在整个生命周期中的规范规划与配置信息、运行时特性及其管理通过管理计划来定义。

4.5.SWITCH工作台中的工作流

图7中的序列图展示了SWITCH中的工作流。用户（例如软件工程师）成功（1）注册并登录SWITCH工作台后，将被重定向到仪表板，在此处可以选择两项主要功能，即组件创建和应用组合。

创建组件时，首先(2)从DockerHub拉取一个Docker镜像并存储到内部的SIDE仓库（例如数据库）中。在

为了访问高级SWITCH功能，必须通过监控适配器或包含JCatascopia探针来实现一定程度的监控。此外，（3）使用动态建模图创建应用描述。首先，在组件创建阶段，从SIDE内部仓库中取出一个容器化组件并拖放到画布上。SIDE工作台的一个独特创新之处在于，可以通过组件创建建模图将附加属性（例如服务质量约束、硬件需求、环境变量、卷等）附加到这些容器化组件上并进行操作。如图3的放大部分所示，组件（深蓝色矩形）和各种属性（圆形和菱形）可以一并拖放到画布上，并与组件相连。通过右键点击特定属性，可以手动设置该属性的属性值，这些属性值将被映射到TOSCA中。可以附加到组件上的属性种类包括：（i）服务质量约束（例如响应时间、抖动），（ii）硬件需求（中央处理器频率、内存等），（iii）卷（使容器能够将磁盘的部分挂载到持久存储），（iv）端口映射，（v）环境变量，（vi）监控（包括监控代理的监控组件）[35]。

具有关联属性的容器化组件将被存储到SIDE内部仓库中，并可通过应用组合视图[36]在构建更大的多层云原生应用时（重新）使用和修改。在完成应用组合后（即组件及其属性相互链接，形成一个功能完整的多层基于微服务的云原生应用）(4)，需验证所有组件是否正确链接且属性已设置。整个应用逻辑描述随后被映射到TOSCA编排标准中，可在SIDE中进行编辑和操作。直接修改TOSCA也会对建模图产生影响。创建TOSCA （5）后，会对其正确性进行验证，并通过RESTfulAPI（6）传递给 DRIP。根据应用描述和设定的属性（例如约束），DRIP计算在多云环境中应用程序最优运行所需的虚拟机（VMs）的规模和数量，并（7）将配置计划映射回TOSCA，再（8）发送回SIDE进行确认。软件工程师在 SIDE中批准所提议的计划（9）后，DRIP与云服务提供商协商服务等级协议（SLA），并开始（10）在云环境中部署和执行整个应用程序。当应用程序运行时，（11）监控指标

正在从ASAP收集数据，并（12）将数据存储到TSDB中，供自适应适配器分析数据以及监控服务器用于监控指标。在应用程序运行时，（13）告警触发器将应用程序的状态返回给SIDE。当设定的约束条件阈值被违反时，（14）自适应适配器会提出扩展建议，并将新计划发送给DRIP，DRIP （15）计算并部署新的配置计划。

5.在SWITCH用例中的应用

SWITCH项目在三个工业级时间敏感的云应用上进行了设计和测试。每个应用都通过以下四种方式由SWITCH工作台提供支持：（1）定义平台的基本服务组件，例如设置代理边缘、管理服务器、VoIP服务器、 MCU媒体混合器；（2）描述应用逻辑——传感器数据采集、数据存储、处理、预警服务激活以及流媒体服务的属性（输入分发器和代理转码器）；（3）描述系统、网络、基础设施和应用层级的质量要求，例如允许的丢包率或最大延迟，或定义所需机器类型等；（4）监控运行时基础设施，并在发生故障（自适应）或需要额外资源以支持更多用户时采取相应措施。这四项需求与协同编程范式高度对应。

5.1.SWITCH需求

在定义SWITCH架构之前，我们分析了三个工业时间关键型应用：弹性灾害早期预警系统12（BEIA用例）；用于指挥和直播活动的云工作室13（MOG用例）；以及协作式实时业务通信平台14（WT用例）。这三家公司都将使用SWITCH来实现其解决方案。基于此，我们创建了一个 SWITCH应满足的最低需求列表，如表1所示。该表列出了由开发人员和研究人员在该领域内收集到的需求。并非所有功能都被所有用例使用，但所有用例的需求均可通过SWITCH得到满足。

表1：SWITCH在WT、MOG和BEIA用例的组件创建和应用组合阶段提供的关键需求。

需求	WT	MOG	BEIA
组件定义	√	√	√
组件组合	√	√	√
组件配置	√	√	√
可扩展性设置	√	√
网络特性	√	√	√
组播定义		√
监控	√	√	√
对系统状态的响应	√	√
手动重新配置	√	√
设置代理	√	√
VoIP服务器管理	√

前三个需求（组件定义、组合和配置）是所有应用程序所必需的。它们是实现应用程序描述的基础要素。可扩展性设置使系统能够定义每个组件的扩展方式及其相关需求。例如，其中一个需求可能是组件所运行的虚拟机上必须提供一定数量的端口。网络特性的描述对所有用例应用程序同样重要，因为时间关键型应用高度依赖于用户与应用程序之间以及各组件之间的网络状况。为了满足应用程序不断变化的需求和环境变化，所有应用程序都需要具备监控能力。大多数应用程序需要根据监控的系统状态进行某种自适应，或者在某些服务无法动态调整时进行手动重新配置，以避免干扰应用程序的正常运行。除了这些通用需求外，还有一些特殊情况也需要满足。MOG由于其系统的特殊性，要求其组件具备多播数据的能力。BEIA要求具备重新配置代理的能力。WT则需要更细粒度地管理其 VoIP服务器，针对每个组件和部署决定应使用哪些特定服务器。

5.2.Switch协作式实时业务通信平台

统一通信（UC）平台（WT用例）是企业商业环境中的一种实时、时间关键型应用程序，支持两个或更多用户之间的通信。该平台提供状态检测、即时消息服务（聊天）、消息传递服务以及音视频通话。

SWITCH与该用例的架构及交互关系如图8所示。为了实现所需系统，开发者不仅需要对运行中的代码进行控制，还需要对底层架构进行控制——这是协同编程的核心。

UC平台的行为取决于系统的负载需求。为了满足服务质量（QoS）要求，系统设计为在需要时自动执行扩展。通过使用SWITCH，我们可以在各种工作负载下保证UC用例的流量需求，并维持系统的正常运行（图8）。

SIDE子系统允许开发人员在容器级别定义系统及其服务质量（QoS）要求。DRIP在启动UC在不同虚拟机（VMs）上的执行和部署之前，会检查服务所需的资源。如果应用程序需要扩展，DRIP将在云环境中配置新资源，同时保持服务质量（QoS）。ASAP负责监控并在需要扩展时发出告警。

在表2中列出了WT用例的时间关键性要求。对于实时协议（RTP）引擎的正常运行，必须满足的最关键时间关键约束是延迟和抖动，分别为 130毫秒和100毫秒。同样，对于AsterixPBX和DubangoWebRTC，最关键的是满足抖动，阈值为150毫秒。

表2：统一通信平台中的服务质量时间关键性要求。

组件	RTP引擎	AsterixPBX	DubangoWebRTC
延迟（毫秒）	130	10	500
抖动（毫秒）	100	150	150
带宽（Mbps）	2	2	2
丢包率（%）	1	1	2
误码率（%）	1	>1	>1

5.3.弹性灾害早期预警系统

弹性灾害早期预警系统可帮助民众和当局在灾害发生时挽救生命和财产。例如，在洪水发生前及时发布预警，将使水库运营人员能够逐步降低水位，民众能够加固房屋，医院能够做好接收更多患者的准备，而当局也能够提前组织并提供援助。该系统采用先进的扩展技术，结合虚拟机配置和自动SDN定义，在高需求期间无缝提升操作吞吐量，并在云服务中断期间迁移基础设施位置以维持系统功能。为此，必须对组件和应用性能进行监控和维护。为此，必须明确指定服务质量（QoS）和系统需求。

预警系统从实时传感器收集数据，使用预测仿真工具处理信息，并为公众提供预警服务以获取更多信息。该系统的实施面临若干挑战，因为系统必须：（1）近乎实时地收集和处理传感器数据；（2）快速响应紧急事件；（3）预测网络中负载峰值的增长；（4）稳健且可靠地运行；（5）在数据量增加时具备可扩展性。

表3包含预警系统的相关指标。由于系统特性，SIP通知器需要更高的带宽（400Mbps），因为它需要与呼叫中心通信，而Graphite则需要较少（40Mbps），因为它仅存储来自IP网关的数据。

将警报分发给最终代理（例如公民、当局）是此用例中的时间关键组件。其弹性主要取决于通知系统处理大量呼叫事件的能力。每个通知工作器通过监控适配器向ASAP子系统发送多个应用级指标（包括外拨电话数量和内存使用率），以便DRIP通过增加或减少工作器数量来提供弹性供给级别。为了满足这些需求，必须以具体术语描述该系统，明确监控指标的数值以及为实现自适应所需采取的操作，从而在最终代理数量发生变化时能够进行自适应调整。
正在从ASAP收集数据，并（12）将数据存储到TSDB中，供自适应适配器分析数据以及监控服务器用于监控指标。在应用程序运行时，（13）告警触发器将应用程序的状态返回给SIDE。当设定的约束条件阈值被违反时，（14）自适应适配器会提出扩展建议，并将新计划发送给DRIP，DRIP （15）计算并部署新的配置计划。

5.在SWITCH用例中的应用

SWITCH项目在三个工业级时间敏感的云应用上进行了设计和测试。每个应用都通过以下四种方式由SWITCH工作台提供支持：（1）定义平台的基本服务组件，例如设置代理边缘、管理服务器、VoIP服务器、 MCU媒体混合器；（2）描述应用逻辑——传感器数据采集、数据存储、处理、预警服务激活以及流媒体服务的属性（输入分发器和代理转码器）；（3）描述系统、网络、基础设施和应用层级的质量要求，例如允许的丢包率或最大延迟，或定义所需机器类型等；（4）监控运行时基础设施，并在发生故障（自适应）或需要额外资源以支持更多用户时采取相应措施。这四项需求与协同编程范式高度对应。

5.1.SWITCH需求

在定义SWITCH架构之前，我们分析了三个工业时间关键型应用：弹性灾害早期预警系统12（BEIA用例）；用于指挥和直播活动的云工作室13（MOG用例）；以及协作式实时业务通信平台14（WT用例）。这三家公司都将使用SWITCH来实现其解决方案。基于此，我们创建了一个 SWITCH应满足的最低需求列表，如表1所示。该表列出了由开发人员和研究人员在该领域内收集到的需求。并非所有功能都被所有用例使用，但所有用例的需求均可通过SWITCH得到满足。

表1：SWITCH在WT、MOG和BEIA用例的组件创建和应用组合阶段提供的关键需求。

需求	WT	MOG	BEIA
组件定义	√	√	√
组件组合	√	√	√
组件配置	√	√	√
可扩展性设置	√	√
网络特性	√	√	√
组播定义		√
监控	√	√	√
对系统状态的响应	√	√
手动重新配置	√	√
设置代理	√	√
VoIP服务器管理	√

前三个需求（组件定义、组合和配置）是所有应用程序所必需的。它们是实现应用程序描述的基础要素。可扩展性设置使系统能够定义每个组件的扩展方式及其相关需求。例如，其中一个需求可能是组件所运行的虚拟机上必须提供一定数量的端口。网络特性的描述对所有用例应用程序同样重要，因为时间关键型应用高度依赖于用户与应用程序之间以及各组件之间的网络状况。为了满足应用程序不断变化的需求和环境变化，所有应用程序都需要具备监控能力。大多数应用程序需要根据监控的系统状态进行某种自适应，或者在某些服务无法动态调整时进行手动重新配置，以避免干扰应用程序的正常运行。除了这些通用需求外，还有一些特殊情况也需要满足。MOG由于其系统的特殊性，要求其组件具备多播数据的能力。BEIA要求具备重新配置代理的能力。WT则需要更细粒度地管理其 VoIP服务器，针对每个组件和部署决定应使用哪些特定服务器。

5.2.Switch协作式实时业务通信平台

统一通信（UC）平台（WT用例）是企业商业环境中的一种实时、时间关键型应用程序，支持两个或更多用户之间的通信。该平台提供状态检测、即时消息服务（聊天）、消息传递服务以及音视频通话。

SWITCH与该用例的架构及交互关系如图8所示。为了实现所需系统，开发者不仅需要对运行中的代码进行控制，还需要对底层架构进行控制——这是协同编程的核心。

UC平台的行为取决于系统的负载需求。为了满足服务质量（QoS）要求，系统设计为在需要时自动执行扩展。通过使用SWITCH，我们可以在各种工作负载下保证UC用例的流量需求，并维持系统的正常运行（图8）。

SIDE子系统允许开发人员在容器级别定义系统及其服务质量（QoS）要求。DRIP在启动UC在不同虚拟机（VMs）上的执行和部署之前，会检查服务所需的资源。如果应用程序需要扩展，DRIP将在云环境中配置新资源，同时保持服务质量（QoS）。ASAP负责监控并在需要扩展时发出告警。

在表2中列出了WT用例的时间关键性要求。对于实时协议（RTP）引擎的正常运行，必须满足的最关键时间关键约束是延迟和抖动，分别为 130毫秒和100毫秒。同样，对于AsterixPBX和DubangoWebRTC，最关键的是满足抖动，阈值为150毫秒。

表2：统一通信平台中的服务质量时间关键性要求。

组件	RTP引擎	AsterixPBX	DubangoWebRTC
延迟（毫秒）	130	10	500
抖动（毫秒）	100	150	150
带宽（Mbps）	2	2	2
丢包率（%）	1	1	2
误码率（%）	1	>1	>1

5.3.弹性灾害早期预警系统

弹性灾害早期预警系统可帮助民众和当局在灾害发生时挽救生命和财产。例如，在洪水发生前及时发布预警，将使水库运营人员能够逐步降低水位，民众能够加固房屋，医院能够做好接收更多患者的准备，而当局也能够提前组织并提供援助。该系统采用先进的扩展技术，结合虚拟机配置和自动SDN定义，在高需求期间无缝提升操作吞吐量，并在云服务中断期间迁移基础设施位置以维持系统功能。为此，必须对组件和应用性能进行监控和维护。为此，必须明确指定服务质量（QoS）和系统需求。

预警系统从实时传感器收集数据，使用预测仿真工具处理信息，并为公众提供预警服务以获取更多信息。该系统的实施面临若干挑战，因为系统必须：（1）近乎实时地收集和处理传感器数据；（2）快速响应紧急事件；（3）预测网络中负载峰值的增长；（4）稳健且可靠地运行；（5）在数据量增加时具备可扩展性。

数据收集器通过远程遥测站接收数据IP网关收集的数据存储在Graphite数据库中。数据通过监控适配器发送到 Graphite数据库。这种方式发送数据更高效，因为它使用了简单的协议和更可扩展的采样。存储在Graphite中的数据可以轻松地在Graf ana仪表盘中显示。当发生异常情况时，数据收集器会向告警器发送HTTP请求以通知最终用户。当会话发起协议（SIP）通知器收到来自告警器的请求时，它会将请求发送到负责处理请求并通过Asterisk软件经由专用自动交换分机发送通知。

表3：弹性灾害早期预警系统中的服务质量。

组件	Graphite	SIP通知器	IP网关
延迟（毫秒）	10	10	500
抖动（毫秒）	1	1	N/A
带宽（Mbps）	40	400	>1
丢包率（%）	0.5	0.5	1.5
误码率（%）	0.1	0.1	0.5

表3包含预警系统的相关指标。由于系统特性，SIP通知器需要更高的带宽（400Mbps），因为它需要与呼叫中心通信，而Graphite则需要较少（40Mbps），因为它仅存储来自IP网关的数据。

将警报分发给最终代理（例如公民、当局）是此用例中的时间关键组件。其弹性主要取决于通知系统处理大量呼叫事件的能力。每个通知工作器通过监控适配器向ASAP子系统发送多个应用级指标（包括外拨电话数量和内存使用率），以便DRIP通过增加或减少工作器数量来提供弹性供给级别。为了满足这些需求，必须以具体术语描述该系统，明确监控指标的数值以及为实现自适应所需采取的操作，从而在最终代理数量发生变化时能够进行自适应调整。

5.4.用于导播和广播直播活动的Switch云工作室

在SWITCH项目中，为支持基于IP的视频传输，开发了一款用于制作直播电视节目的分布式云应用。通过网页应用，导演可执行更换摄像机、选择输入流数量以及选择输出流[37]等操作。由于云工作室预计将作为一种基于事件的服务，即在需要时启动、广播结束时停止，因此需要描述能够支持该系统的程序和架构，以便使用不同的启动参数快速完成系统的部署。

这是协同编程概念的一个典型示例，因为它能够实现系统修改——支持更多摄像机——并在运行时对系统进行测试并保持性能。

表4：Switch云工作室中的QoS指标。

组件	输入分发器	视频切换器	代理 转码器
延迟（毫秒）	30	30	30
抖动（毫秒）	0.5	0.5	0.5
带宽（Mbps）	130	130	130
丢包率（%）	>0.1	>0.1	>0.1
误码率（%）	>0.1	>0.1	>0.1

表4展示了与MOG用例相关的QoS指标。抖动，延迟的重要性较低，因为视频可以稍晚到达，只要以相同的速率到达即可，而损失和错误率则最为重要。

每个输入分发器节点负责接收输入流，解压缩并通过多播方式传输，生成相应的媒体流。在这种情况下，相关节点为视频切换器和代理转码器。每个代理转码器负责对其订阅的一对媒体流进行转码，生成代理版本，并对外提供，例如供Web应用使用。视频切换器必须订阅输入分发器提供的多播地址，存储接收到的数据，并通过多播方式发送业务逻辑确定的流[37]。

每个输出节点通过多播接收来自 VideoSwitcher的视频流，并将其以单个流的形式广泛传输。这意味着可以存在多个输出，例如，其中一个输出可传输具有相同输入特性的流。每个组件都有可配置的特定属性。可根据需要添加必要的连接和复杂性，以构建所需的场景。如果至少有一个组件表明其附带了监控代理，则系统将自动添加监控系统（监控适配器和服务器）。

6.评估

尽管我们的评估简要涉及了生产力，但在本节中，我们仅旨在表明 SWITCHIDE能够在整个生命周期中高效支持云原生应用的协同编程开发。另一方面，要证明使用SWITCH[38]能够提升生产力，还需针对实际任务并结合对照组进行更深入的评估。大多数生产力度量方法聚焦于代码行数，而这种方法在我们的案例中无法适用，因为SIDE与图形化编程语言[39]密切相关。

为了进行评估，我们从分布式云计算和DevOps工程领域的六名学术研究人员中进行了选择。我们向所有参与者提供了详细的指令，说明如何在使用和不使用SWITCH的情况下创建全部三个用例。参与者了解我们的工作，并且作为该领域的专家，他们熟悉基于Docker的云应用的构建。

实验过程中使用秒表以分钟为单位记录时间，我们全程在场。参与者获得了有关如何使用SIDE以及创建TOSCA和Docker Compose文件的指令。实验对象还收到了有关如何创建应用程序的说明，以便他们只需关注如何描述用例，而无需在用例架构上花费时间。

使用了SWITCH的干净安装，因此无法复用组件，但参与者被告知如果愿意，可以自由复用他们创建的组件。在应用程序创建过程中，记录了每个阶段所花费的时间（例如组件创建、组件修改（可选）、应用组合，以及生成TOSCA和DockerCompose文件）。

在实验的第一阶段，要求参与者描述应用程序中使用的所有容器（图 12）以及应用程序自身。他们获得了有关组件属性（端口、Docker镜像位置、卷、变量等）及其相互连接方式的全部信息。根据使用SWITCH描述软件组件所需的时间（以分钟为单位）以及直接在TOSCA中编写这些组件描述所需的时间，我们计算了分布情况（见图12），结果显示使用 SWITCH时具有更高的一致性（许多用户所用时间相近），因为其应用逻辑和工作流能够快速且自动地映射到TOSCA中。

在第二阶段，参与者被要求通过在VisualStudioCode中为所有三个应用程序创建TOSCA和DockerCompose文件来描述相同的应用程序。他们再次获得描述示例，并被期望尽可能快地使用代码补全和复制粘贴来完成目标。最后，检查这些描述以确认其是否符合TOSCA标准以及所有引用是否正确，但这些描述并未用于部署实际应用程序。图11展示了完成所有三个应用程序生命周期各个阶段所需的时间。y轴上的数值表示所有参与者在每个阶段以及全部三个用例中的平均值。

根据结果，与手动创建组件、TOSCA和DockerCompose文件相比， SWITCHIDE显著加快了应用程序生命周期中所有阶段（以及所有三个用例）的实施速度。

SWITCH 无SWITCH（手动创建TOSCA）
0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5
Ti m e [m in ]
使用/不使用SWITCHIDE描述一个容器化组件所需的时间

和手动创建DockerCompose文件相比，通过比较使用/不使用 SWITCH的创建过程，可以明显看出使用SWITCH后各个阶段所需的创建时间显著减少。此外，TOSCA和DockerCompose文件创建的差异最为显著，由于自动化的TOSCA映射和DockerCompose文件生成，平均而言，三个用例的创建速度大约快了50多倍。最关键的指标是完整工作流，因为它代表了创建应用程序所需的实际时间，平均而言，比手动创建工作流快近两倍。

7.结论

本文提出了一种用于构建具有时间关键约束的复杂可适应云系统的新概念：应用程序‐基础设施协同编程模型。该模型提供了对应用逻辑组合、工作流以及虚拟环境的可编程性、可控性和重新配置能力，从而实现应用可扩展性、可用性、弹性和自适应。这些是用户体验质量的关键服务质量属性，对于时效性关键云应用而言尤其具有挑战性。

根据对三个时间关键型工业应用程序的功能性和非功能性需求的分析，我们发现通过独特的三部分SWITCH架构可以最好地支持可编程和可控特性。SWITCH交互式开发环境（SIDE）提供了一个带有Docker Compose文件服务建模工具的图形用户界面，用于创建软件组件以及组合应用程序的逻辑和工作流；动态实时基础设施规划器（DRIP）负责在虚拟云基础设施上进行基础设施规划、资源供给、部署和应用程序执行；自主系统自适应平台（ASAP）提供监控服务，并处理应用扩展、告警触发器和自适应。为了在所有三个子系统之间交换数据，应用程序逻辑及其所有约束、服务质量参数和应用程序工作流都被映射到OASISTOSCA中。

SWITCH系统的创新之处在于，它能够通过图形化建模将服务质量参数（如NFR以及网络、基础设施和应用级指标）直观地呈现、管理和关联到组件（例如容器）。此外，服务质量参数等被映射到TOSCA中，并在三个子系统之间进行交换。

评估结果表明，利用SWITCH在云原生应用生命周期的各个阶段（例如组件和应用程序创建、DockerCompose文件创建以及TOSCA映射）中创建三个具有时间关键约束的工业应用程序，由于SWITCH的协同编程特性，显著减少了所需时间。相反，手动创建组件和应用程序、生成并将整个应用逻辑映射到TOSCA已被证明相当耗时且流程复杂。使用 SWITCH与手动创建之间最显著的差异体现在TOSCA映射过程中。

以及为所有三个用例和SWITCH生成DockerCompose文件。

除了开发并验证SWITCH架构的有效性之外，我们还超出了项目目标，开发了一种多目标优化方法，用于权衡相互冲突的非功能性需求，以确保提升服务质量。然而，该后一种方法的详细信息不在本文范围内，可在其他地方找到[16]。

仍然缺少的是在整个生命周期中对应用程序进行更大规模的试验，以迭代方式变更和更新软件。这只有在长期成功运行的应用程序基础上才可能实现，而这样的条件可能要到未来几年内才能具备。在此期间， SWITCH不会被放弃。相反，由于软件组件的图形化建模已被证明在应用程序创建过程中节省时间且易于处理，我们计划构建以下两个系统：（1）动态元数据文档生成系统，能够根据应用程序的服务质量属性生成各种类型的文档，例如.yaml、.xml、DockerCompose等；（2）应用离线与运行时状态快照版本管理系统，能够在虚拟基础设施中创建并存储已创建应用程序逻辑及其运行状态的工作流快照，并可通过内部SWITCH仓库获取，可在其他云环境中重复使用。总体而言，我们将紧跟前沿技术趋势，努力追求创新理念。此外，扩展TOSCA以支持那些产生大量（大）数据并面向网络的雾端和边缘运行的应用程序的编排，也必将是一项重大挑战。