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

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

摘要

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

*通讯作者电子邮件地址: StefaničP@cardiff.ac.uk (Polona Štefanič*)

预印本提交至FGCS特刊 2019年3月1日

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

1. 引言

许多工业时间关键型应用，如灾害早期预警系统、视频会议、在线游戏或现场活动直播，对其性能具有极高的时间关键性要求，并为成功开发、部署和维护带来了特殊挑战。只有满足时间关键性要求（如高性能、可移植性、可用性、弹性和响应性），这些应用才能实现预期的商业价值和显著的社会影响。此外，它们还必须能够预测并应对（不可预见的）负载高峰，提供按需计算资源的快速弹性以及底层云基础设施的可重构性，以满足所需的服务质量 (QoS)（例如低响应时间和抖动）和用户体验质量 (QoE)（例如超高清电视信号的传输）约束。
时间关键型应用通常涉及分布式组件和密集的数据通信，并可能包含部署在不同地理位置的远程现场传感器。然而，由于对虚拟运行环境有较高要求，以及需要复杂的优化机制来集成系统组件并完成整个应用的资源供给，这类应用的设计、开发和部署通常困难且成本高昂。云生态系统提供了弹性、可控且按需的服务，能够支持复杂的时间关键型应用。然而，目前仍缺乏支持此类应用程序开发、部署和执行的软件工程工具与方法，这些工具和方法应能利用云计算平台所提供的可编程性和可控性。因此，时间关键型应用无法充分获得基于云技术的全部潜在优势。为此，有必要引入新型软件工具和方法，通过提供可控和可编程的功能（如应用逻辑和工作流的（图形化）建模、基础设施规划与配置等），全面支持时间关键型应用的整个生命周期，以实现增强和优化的服务质量。
因此，我们的研究旨在通过设计一种应用‐基础设施来自适应、可扩展性、服务可用性和弹性。

2. 相关工作

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

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

ARCADIA方法论[2]支持向多云的部署以及应用程序的自动实时重构。它依赖于软件组件的建模来组合应用程序。尽管该框架提供编排、多云部署和拖放式服务图管理器，但不允许将额外的服务质量属性附加到组件上（例如服务质量约束、硬件需求等）；也不提供 TOSCA操作。
目前存在两种用于创建云应用和服务的服务建模工具。Juju[3]是一种面向服务架构和应用部署的基于组件的图形化建模工具，提供了一系列预定义的软件资产及其关系，其中包含如何在云中正确部署和配置所选服务的知识。另一种工具是Fabric8¹，该平台分别使用Docker和 Kubernetes作为虚拟化和编排技术，支持微服务的创建、部署和持续集成。然而，这两种服务建模工具均未针对时间敏感型应用程序提供特定的配置功能，也不提供基础设施规划与配置。
另一方面，MODAClouds [4]方法论支持在云中开发时间关键型应用，但缺乏对软件定义网络的支持，无法通过编程和控制云基础设施来实现性能优化；此外，它也不提供TOSCA操作和映射功能。最后，CloudWave [5]和SSICLOPS[6]方法论专注于应用程序和服务的运行时监控工具，使云服务能够适应其需求和环境的变化，并满足预期的质量约束。CloudWave方法论提出了一种云基准测试Web服务的架构与实施，然而，它仅测量和比较亚马逊EC2中不同实例和存储类型的磁盘速度，未考虑部署在虚拟机或容器上的输入数据流的动态特性，而这一点正是 SWITCH项目的需求之一。
佩加苏斯 [7]包含一种架构和一系列技术，用于在各种环境中（如云计算平台和网格）自动将科学领域中预先创建的高级科学工作流映射到其执行环境，从而实现基于工作流的应用程序的执行。类似地，Apache Airavata[8]支持在分布式计算资源上进行大规模应用程序与工作流的组合、执行和监控。它支持在分布式计算环境中长时间运行的应用程序工作流。

¹ http://fabric8.io/guide/overview.html

然而，在灵活性方面，佩加苏斯和阿伊拉瓦塔既不提供对任何编排规范标准（例如 TOSCA）的修改，也不支持容器化。由于缺乏对应用组合及底层架构的可编程性和控制能力的支持，它们不适合用于时间关键型应用。
MiCADO[9]云编排框架研究了如何将自动编排应用于云应用。该框架采用TOSCA作为编排标准，但不支持将服务质量（QoS）描述映射到 TOSCA中，例如基于组件的硬件需求、环境变量（这是SWITCH的一个重要需求）。

2.2. 云基础设施相关配置方法

确保实时云系统的高服务质量（QoS）需要专用的基础设施[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。高效的配置对于提升运行中应用程序的服务质量至关重要。因此，各种优化方法被高度所需的，例如用于管理非功能性需求的多标准优化方法 [16]。

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的具体工具和框架，例如Chef²和Jenkins³。另一方面，软件定义网络（SDN）提供了网络领域的抽象，并实现了网络配置的可编程性。这意味着网络应更具灵活性，适应快速变更。然而，这两种方法均未在整个应用程序生命周期中提供对应用逻辑或工作流的可编程性。
然而，应用‐基础设施协同编程模型在整个时间关键型应用的生命周期中，为应用逻辑的设计与开发以及虚拟云基础设施的规划与配置提供了可编程性和可控性。由SWITCH架构支持的协同编程模型所采用的独特抽象，旨在提高应用设计的生产力。

² https://www.chef.io/
³ https://jenkins.io/

以及开发、改进的规划与配置和部署效率，以及提高的服务质量控制效率。协同编程使开发者能够控制应用程序工作流和基础设施，在开发过程中指定基于容器化微服务的组件或系统的约束条件，从而确保所开发的组件按照预期方式运行。这最大限度地减少了在创建、配置和部署过程中的出错机会。

4. SWITCH架构

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

4.1. SWITCH交互式开发环境（SIDE）

SIDE 是 SWITCH 工作台的交互式图形用户界面。它提供交互式服务建模图，用于基于容器化微服务的云原生应用的应用程序工作流设计，并支持以下任务：组件创建、应用组合、应用程序验证、基础设施规划、配置、部署和监控（见图3）。SIDE 通过为开发者提供描述系统的需求、约束和底层基础设施的选项，实现了应用‐基础设施协同编程的概念。
SIDE前端⁴是使用EmberJS技术实现的图形用户界面，包含多个视图，例如组件创建视图和应用组合视图。建模图的实际创建使用JointJS库，并在此基础上构建Ember模型。
SIDE后端⁵使用Django框架。它与Ember模型进行交互，这些模型提供了如何展示应用程序建模图的信息。应用程序的应用逻辑和工作流描述被映射为TOSCA YAML格式。基于Django的代码还会对应用程序进行验证，检查附加到组件上的服务质量参数是否正确组合，即是否能生成有效的YAML文件，以及特定组件的所有必需参数（例如硬件需求，如 CPU数量、内存容量等）是否已定义。后端通过调用DRIP和ASAP的 API接口与其它SWITCH子系统通信，并提供已将应用逻辑和工作流映射在内的生成的TOSCA。此外，SIDE后端接收用于规划与配置的返回 TOSCA，并将其呈现给软件开发者或DevOps工程师。
从软件开发者的角度来看，SIDE 支持通过将组件（例如从 DockerHub 拉取的镜像创建的容器化软件）拖放到画布上、设置属性值并将其链接到特定组件，从而利用依赖建模图创建系统的详细规格（参见 图3）。此外，通过使用建模图，所创建的组件可以适当地相互连接，以定义完整的应用逻辑和工作流，从而描述完整的云原生应用。还可以添加系统及底层基础设施的规范。在将应用逻辑映射到 TOSCA 之前，需对应用组合进行验证，以检查错误（例如缺失的服务质量参数或相互连接的不兼容组件）。

⁴ https://github.com/switch-project/SWITCH-version-2/tree/master/SIDE/side-ember
⁵ https://github.com/switch-project/SWITCH-version-2/tree/master/SIDE/side-api

超越项目目标的一项额外创新是定性元数据标记（QMM）的概念。该概念适用于对软件组件进行建模，并已作为概念验证集成到SIDE中。它能够揭示哪些时间关键性要求对服务质量（QoS）影响最大。QMM提供概率信息，显示哪些参数与特定软件组件的服务质量相关性最高[32]。根据这些信息，可以将时间关键性要求纳入进一步分析，因为它们对应用程序的服务质量至关重要。对整个云应用服务质量影响最大（正面或负面）的时间关键性要求可在中间件服务之间交换，并被发送至多准则决策模块。
时间关键性要求通常相互冲突：调整一个参数通常会对其他参数产生重大影响。例如，提高应用程序的可用性需要增加系统冗余，这可能导致高昂的运营成本。在多个应用程序运行时参数之间选择最优的权衡可能是一个耗时且容易出错的过程，尤其是在考虑复杂的多云环境时。我们提出的新方法可以帮助软件工程师在决策过程中，根据定义的相互冲突的目标（例如响应时间、货币成本等）[16]，将虚拟机实例的数量缩减至最优数量。然后可以将应用程序组件部署到这些实例上。

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

DRIP⁶是一套开源服务套件，用于自动规划和配置联网的虚拟机（ VMs），部署应用程序组件，并在运行时管理所生成的基础设施。
DRIP提供了一种整体化的方法，以优化资源并满足应用程序层面的约束条件，如截止时间或服务等级协议（SLAs）。DRIP能够在多个云服务提供商之间配置虚拟基础设施，并可根据需求启动、停止和恢复应用程序组件的执行。特别是，通过使用开放云计算接口（OCCI），DRIP支持在多个云计算平台上进行配置，并兼容多种编排系统，例如Docker Swarm和 Kubernetes。这些功能对于应用‐基础设施协同编程至关重要，使应用程序开发者能够构建满足其需求的系统。
DRIP 服务（如图2所示）包括：
• 基础设施规划器，• 知识库
• 基础设施配置器，• 部署代理，• DRIP管理器
• 基础设施控制代理，• 一个内部消息代理。
基础设施规划器采用改进的部分关键路径算法，通过选择高性价比虚拟机并定制虚拟机间的网络拓扑，根据应用程序工作流和约束生成高效的基础设施拓扑。该基础设施配置器能够将规划器生成的基础设施方案自动部署到底层基础设施上；它可以分解基础设施描述并进行资源配置。

⁶ https://github.com/switch-project/SWITCH-version-2/tree/master/DRIP

它跨多个数据中心（可能来自不同的提供商）进行部署，并实现透明的网络配置[19]。部署代理将应用程序组件安装到已供给的基础设施上。部署代理能够根据网络瓶颈情况调度部署顺序，并最大限度地满足部署截止时间[21]。基础设施控制代理是一组DRIP提供的API接口，供应用程序用于控制容器或虚拟机的扩展以及调整网络流。 DRIP管理器是一种Web服务，允许外部客户端调用DRIP功能。每个请求由管理器定向到适当的组件，管理者负责协调这些组件并在必要时对其进行扩展。资源信息、凭证、性能配置文件和应用程序工作流均通过内部的知识库进行内部管理。
供应器的默认配置接口是开放云计算接口；它目前支持 Amazon EC2⁷, EGI FedCloud⁸和 ExoGeni⁹云计算平台。部署代理可以在 Docker 集群（例如 Docker Swarm、Kubernetes）上进行部署，并且能够基于 Ansible 剧本¹⁰部署定制应用程序。
DRIP 需要软件开发者提供应用描述，以确定要部署的特定组件及其需求、依赖关系和约束。此外，还需补充来自云服务提供商的基础设施资源信息（例如虚拟机类型和网络带宽）。当规划请求从 SIDE（由软件开发者发起）到达时，基础设施规划器生成一个计划，该计划由 DRIP 发送至 SIDE 并呈现给软件开发者进行确认。确认后的计划可提交给供应器，并根据需要代表用户提供必要的云凭证（如果尚未存在于 DRIP 的知识库中）。DRIP 通过所选云服务提供商提供的接口来供给已规划的基础设施。
随后，部署代理从指定仓库将所有必要的应用程序组件部署到已供给的基础设施上，并建立用于应用程序和基础设施运行时控制所需的控制接口。

⁷ https://aws.amazon.com/cn/ec2
⁸ https://www.egi.eu/federation/egi-federated-cloud/
⁹ http://www.exogeni.net/
¹⁰ https://www.ansible.com/

4.3. 自主系统自适应平台（ASAP）

ASAP 提供运行时适应，因此需要一个稳定且可修改的监控系统，该系统可通过附加功能进行扩展，从而能够通过添加额外组件、可视化系统状态以及更改系统基础设施来动态改变系统特性。ASAP 专注于自动伸缩，并支持在多云环境中的地理编排，以及多实例和多租户操作。ASAP 子系统（见图2）包括：
• 监控探针,
• 监控代理，
• 监控服务器,
• 报警触发器,
• 时序数据库，
• 知识库，
• 信息服务，
• 性能诊断器，
• 自适应器，以及
• 控制代理。
图4展示了自适应序列，从探针和代理上采集监控数据到最终使用这些信息的过程。

第一步，监控探针和代理的目的是收集代表应用程序和基础设施当前状态的数据，然后将测量值聚合并传输到监控服务器和报警触发器。监控探针具有轻量性、可扩展性，并且本质上是去中心化的。它们能够从高级探针中收集非结构化数据，例如请求处理时间。
多个组件。监控服务器接收收集到的数据，并将其存储在时序数据库（ TSDB）中，以构建系统状态的全面表示。性能诊断器利用存储在TSDB中的信息构建用于评估性能的模型。该模型的设计旨在识别出需要纠正措施的任何问题。同时，报警触发器会检查被监控参数的测量值是否超过相应的阈值。当检测到问题时，将调用自适应器来提出合适的自适应策略。该组件为控制代理指定一组自适应操作，使整个系统能够从当前状态过渡到期望状态。控制代理完全掌控应用程序配置和基础设施资源（例如虚拟机/ 容器和网络带宽），最终执行自适应操作[33]。这些操作可以自动化地重启发生故障的单个组件或一组组件、添加一个新的组件实例，或将组件迁移至另一个（可能是全新的）虚拟机。
为了简化开发，创建了一个适配器，用于将 JCatascopia [34]消息传递给监控服务器，而无需使用本地监控代理。该适配器使用 StatsD¹¹从基础设施中收集指标，并将其提供给 JCatascopia 服务器。基础设施级指标由 ASAP 收集，并以与应用级指标相同的方式进行处理。诸如 CPU、磁盘和内存使用情况等信息由探针收集，并发布到指标组中（例如 ‘CPUProbe’、’DiskStatsProbe’ 和 ‘MemoryProbe’）。

¹¹ https://www.librato.com/docs/kb/collect/collection-agents/stastd/

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

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

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

与构建云原生应用程序的特定组件和软件组件之间的依赖关系被存储到关系类型中。
此外，拓扑模板中表示的不同节点模板之间的有向图以及为每个节点模板定义的属性和约束（例如截止时间），被用作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）后，会对其正确性进行验证，并通过RESTful API（6）传递给 DRIP。根据应用描述和设置的属性（例如约束），DRIP计算在多云环境中最优运行应用程序所需的虚拟机规模和数量，并将配置计划（7）映射回TOSCA，再（8）发送回SIDE进行确认。软件工程师在SIDE中批准所提议的计划（9）后，DRIP与云服务提供商协商服务等级协议，并开始在云环境中对整个应用程序进行（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架构之前，我们分析了三个工业领域的时间关键型应用：弹性灾害预警系统¹²（BEIA用例）；用于现场活动导播与直播的云演播室¹³（MOG用例）；以及协作式实时业务通信平台¹⁴（WT用例）。这三家公司都将使用SWITCH来实现其解决方案。基于此，我们创建了一个 SWITCH应满足的最低需求列表，如表1所示。该表列出了由开发者和研究人员在该领域内识别出的需求。并非所有功能都被所有用例使用，但所有用例的需求均可通过SWITCH得到满足。

¹² BEIA咨询公司，罗马尼亚，http://www.beiaro.eu/
¹³ MOG技术公司，葡萄牙。http://www.mog-technologies.com/
¹⁴ Wellness电信，西班牙，http://www.wtelecom.es/

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

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

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

统一通信（UC）平台（WT用例）是用于企业商业环境的实时、时间敏感的应用程序，支持两个或更多用户之间的通信。该平台提供状态检测、即时消息服务（聊天）、消息传递服务以及音视频通话。SWITCH与该用例的架构及交互关系如图8所示。为了实现所需系统，开发者不仅需要对运行中的代码进行控制，还需要对底层架构进行控制——这是协同编程的核心。

UC平台的行为取决于系统的负载需求。为了满足服务质量（QoS）要求，系统被设计为在需要时自动执行扩展。通过使用SWITCH，我们可以在各种工作负载下保证UC用例的流量需求，并维持系统的正常运行（图 8）。SIDE子系统允许开发者在容器级别定义系统及其服务质量（QoS）要求。DRIP在启动UC在不同虚拟机上的执行和部署之前，检查服务所需的资源。如果应用程序需要扩展，DRIP将在云环境中配置新资源，同时保持服务质量。ASAP负责在需要扩展时进行监控并发出告警。

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

组件	RTP引擎	Asterix PBX	Dubango WebRTC
延迟（毫秒）	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）在数据量增加时具备可扩展性。
图9中包含了一种更以数据流为导向的表示。数据收集器通过远程遥测站接收数据

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

组件	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通知器需要更高的带宽（400 Mbps），因为它需要与呼叫中心通信，而Graphite则需要较少（40 Mbps），因为它仅存储来自IP网关的数据。
将警报分发给最终代理（例如公民、主管部门）是本用例中时间敏感的关键组件。其弹性主要取决于通知系统处理大量呼叫事件的能力。每个通知工作器通过监控适配器向ASAP子系统发送多个应用级指标（包括外拨电话数量和内存使用率），以便DRIP通过增加或减少工作器数量来提供弹性供应级别。为了满足这些需求，必须以具体术语描述该系统，明确监控指标的数值以及为实现自适应所需采取的操作，从而在最终代理数量变化时能够进行相应的自适应调整。

5.4. 用于现场活动导播与直播的Switch云演播室

在SWITCH项目中，为支持IP视频传输，开发了一款用于直播电视节目制作的分布式云应用。通过网页应用，导演可以执行诸如切换摄像头、选择输入流数量以及选择输出流[37]等操作。由于云演播室预期为一种基于事件的服务，即在需要时启动、广播结束时停止，因此必须描述能够支持该系统的程序和架构，以便使用不同的启动参数快速完成系统的部署。这是协同编程概念的一个典型示例，因为它能够实现对系统的修改——支持更多摄像头——并在运行时对系统进行测试并保持性能。

组件	输入分发器	视频切换器	代理 转码器
延迟（毫秒）	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]。

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

6. 评估

尽管我们的评估简要涉及了生产力问题，但在本节中，我们仅旨在表明SWITCH IDE能够通过协同编程在整个生命周期内高效支持云原生应用的软件开发。另一方面，要证明使用SWITCH [38]能够提升生产力，还需针对实际任务并结合对照组进行更多评估。大多数生产力度量关注代码行数，而这种方法在我们的案例中无法使用，因为SIDE与图形化编程语言 [39]密切相关。
为了进行评估，我们从分布式云计算和DevOps工程领域的六名学术研究人员中进行了选择。我们向所有参与者提供了详细的指令，说明如何在使用和不使用SWITCH的情况下创建全部三个用例。参与者了解我们的工作，并且作为该领域的专家，他们熟悉基于Docker的云应用的构建。
实验过程中使用秒表以分钟为单位记录时间，我们在整个实验期间均在场。
参与者收到了有关如何使用SIDE以及创建TOSCA和Docker Compose文件的指令。测试对象还获得了创建应用程序的说明，以便他们只需关注如何描述用例，而无需在用例架构上花费时间。
使用了SWITCH的干净安装，以便组件无法被重复使用，但参与者被告知如果愿意，可以自由地重复使用他们创建的组件。在创建应用程序的过程中，记录了每个阶段所花费的时间（例如组件创建、组件修改（可选）、应用组合，以及创建TOSCA和Docker Compose文件）。
在实验的第一阶段，要求参与者描述应用程序中使用的所有容器（图 12）以及应用程序自身。他们获得了有关组件属性（端口、Docker镜像位置、卷、变量等）及其相互连接方式的全部信息。根据使用SWITCH描述软件组件与直接在TOSCA中编写这些组件描述所需的时间（以分钟为单位），我们计算了分布情况（见图12），结果显示使用SWITCH时更具一致性（许多用户所需时间相近），因为其应用逻辑和工作流能够快速且自动地映射到TOSCA中。

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

以及手动创建Docker Compose文件。通过比较使用SWITCH与不使用 SWITCH的创建时间，可以明显看出，使用SWITCH后各个阶段的创建时间均显著减少。此外，最显著的差异体现在TOSCA和Docker Compose文件的创建上，由于自动TOSCA映射和Docker Compose文件生成，这三个用例的平均创建速度大约提高了50倍以上。最关键的指标是整个工作流，因为它代表了创建应用程序所需的实际时间，平均而言，比手动创建工作流几乎快了一倍。

7. 结论

本文提出了一种用于工程化具有时间关键约束的复杂可适应云系统的新概念：应用‐基础设施协同编程模型。该模型提供了对应用逻辑组合、工作流以及虚拟环境的可编程性、可控性和重构能力，从而实现应用可扩展性、可用性、弹性和自适应。这些是QoE至关重要的核心服务质量属性，对于时间敏感型云应用而言尤其具有挑战性。
根据对三个时间关键型工业应用程序的功能性和非功能性需求的分析，我们发现通过独特的三部分SWITCH架构可以最好地支持可编程和可控特性。SWITCH交互式开发环境（SIDE）提供了一个带有Docker Compose文件服务建模工具的图形用户界面，用于创建软件组件以及组合应用程序的逻辑和工作流；动态实时基础设施规划器（DRIP）负责在虚拟云基础设施上进行应用程序的基础设施规划、配置、部署和执行；自主系统自适应平台（ASAP）提供监控服务，并处理应用扩展、报警触发器和自适应。为了在所有三个子系统之间交换数据，应用程序逻辑及其所有约束、服务质量参数和应用程序工作流都被映射到OASIS TOSCA中。
SWITCH系统的创新之处在于，可以通过图形化建模将服务质量参数（如非功能需求以及网络、基础设施和应用级指标）直观地呈现、管理和关联到组件（例如容器）。此外，这些服务质量参数等被映射到TOSCA中，并在三个子系统之间进行交换。
评估结果表明，通过使用SWITCH在云原生应用生命周期的各个阶段（例如组件和应用程序创建、Docker Compose文件创建以及TOSCA映射）中创建三个具有时间关键约束的工业应用程序，可显著缩短时间，这得益于SWITCH的协同编程特性。相反，手动创建组件和应用程序、生成并将整个应用逻辑映射到TOSCA已被证明非常耗时且流程复杂。在 TOSCA映射过程中，使用SWITCH与手动创建之间的差异最为显著。
以及为所有三个用例和SWITCH生成Docker Compose文件。
除了开发并验证SWITCH架构的有效性外，我们还超出了项目目标，开发了一种多目标优化方法，用于权衡相互冲突的非功能性需求，以确保更优的服务质量。然而，该后一方法的详细信息不在本文范围内，可在其他地方找到[16]。
仍然缺少的是在整个生命周期中对应用程序进行大规模试验，以迭代方式更改和更新软件。这只有在长期成功运行的应用程序基础上才有可能实现，而这样的条件可能要到未来几年内才能具备。在此期间， SWITCH不会被放弃。相反，由于软件组件的图形化建模已被证明在应用程序创建过程中节省时间且易于处理，我们计划构建以下两个系统：（1） 动态元数据文档生成系统，能够根据应用程序的服务质量属性生成各种类型的文档，例如.yaml、.xml、Docker Compose等；（2） 应用离线与运行时状态快照版本管理系统，能够在虚拟基础设施中创建并存储已创建应用程序逻辑及其运行状态的工作流快照，并可通过内部SWITCH仓库获取，可在其他云环境中重复使用。总体而言，我们将遵循前沿趋势，致力于实现创新理念。此外，扩展TOSCA以支持向雾计算和网络边缘发送大量（大数据）并运行的应用程序编排，也必将是一项挑战。