云原生仿真架构趋势

迈向云原生模拟——来自云计算一线的经验教训

摘要

云计算可能对仿真等计算密集型任务产生颠覆性影响。即使是单个研究人员，也能使用亚马逊、谷歌或微软提供的计算能力。然而，云计算的按需付费成本模型影响了云原生系统的构建方式。我们将这些见解迁移到仿真领域。本文的主要贡献有两个方面：（A）我们提出了一种云原生仿真栈；（B）推导出云原生仿真服务的可预期软件工程趋势。我们的见解基于对云原生应用的系统映射研究、对云计算标准的综述、与云工程从业者的行动研究活动以及相应的软件原型开发活动。在过去10年中，有两个主要趋势主导了云计算的发展：部署单元的规模被最小化，相应的架构风格更倾向于细粒度的服务分解，即由独立可部署且水平可扩展的服务构成。我们预测云原生仿真架构也将呈现类似趋势。这些趋势将使云原生仿真服务更加微服务式，具备可组合性，但专注于“把一件事模拟好”。然而，简单地将现有仿真模型迁移至云端可能导致显著增加的成本。我们（及其他）研究的一个关键见解是，云原生系统应遵循云原生架构原则，以最大限度地利用按需付费成本模型。

关键词 云计算、云原生、云成熟度、仿真、参考模型、成熟度模式

1. 引言

仿真被用于多种用途，例如培训、分析和决策支持。因此，建模与仿真（M&S）已成为许多工业领域（如物流和制造业）以及国防领域的一项关键技术。实现多个仿真系统之间的互操作性并确保结果可信度，通常需要在时间、人员和预算方面投入巨大努力。近年来，云计算技术和服务导向架构（SOA）领域的技术发展可能为更好地利用M&S能力以满足这些关键需求提供了机会。一种结合服务导向理念并通过云计算的即服务模式提供M&S应用程序的概念，可能实现更灵活组合的仿真环境，并可按需部署。这一新概念通常被称为仿真即服务（MSaaS）。

1.1 MSaaS仿真原则和验证结果

北约建模与仿真小组（NMSG）是北约科学技术组织（STO）的一部分。NMSG的任务是促进联盟机构、北约以及伙伴国家之间的合作，最大化建模与仿真的有效利用率。主要任务领域包括以下内容：
- 建模与仿真标准化；
- 教育；
- 相关的科学技术。

北约建模与仿真小组（NMSG）负责强制执行并监督《北约建模与仿真主计划》（NMSMP；v2.0 (AC/323/NMSG(2012)-015)）的实施。NMSMP 制定了若干目标，这些目标共同有助于在北约及其成员国范围内充分发挥建模与仿真的潜力，以提升作战效能和成本效益。这一愿景将通过遵循以下原则的协作努力来实现。
- 协同效应：利用并共享现有的北约和国家建模与仿真能力。
- 互操作性：指导仿真互操作性的通用建模与仿真标准和服务的开发，并促进指挥与控制（C2）与仿真的互操作性。
- 重用：提高建模与仿真资产的可见性、可访问性和认知度，以促进在所有北约建模与仿真应用领域的共享。

北约建模与仿真主计划定义了五个战略目标，其中两个直接由本文所述的仿真即服务工作来实现：
- 建立通用技术框架；
- 提供协调与共用服务。

北约MSG-136（作为服务的建模与仿真）1是北约建模与仿真小组下属的工作组之一。2014年至2017年，该工作组研究了仿真即服务的概念，旨在为北约及伙伴国家未来基于服务的“作为服务的建模与仿真的盟国框架”提供技术和组织基础。在此期间，MSG-136开展了开创性工作，界定了北约背景下的仿真即服务，并制定了用于永久建立“作为服务的建模与仿真的盟国框架”的运行、技术和治理概念。除了开发基础概念外，MSG-136还开展了广泛的实验活动，以测试和验证这些概念。2 2018年至2021年，MSG-164进一步扩展了初始概念，并通过专门的评估活动以及参与实际作战演习对其进行验证。

1.2 云原生经验教训

即使是小型公司，也可以通过提供基于云的服务来产生巨大的经济增长和商业价值。服务或应用程序：Instagram、优步、WhatsApp、奈飞、推特——以及许多令人瞩目的小型公司（如果我们将其创立初期的员工数量与其显著的经济影响相对比），这些公司的服务被频繁使用。然而，即使是快速增长的初创企业模式，也应考虑到长期的影响和依赖关系。这些公司中的许多都依赖于公有云基础设施——通常由亚马逊网络服务（AWS）、微软（Azure）、谷歌（云服务）等提供商提供。与此同时，云服务提供商正在为大量不再运营自有数据中心的企业运行关键业务软件。此外，当工作负载具有较高的峰值与平均值比率时，通常采用云方案在经济上是合算的。3然而，也存在弊端。尽管云服务本可以成为标准化的商品，但目前大多并非如此。

一旦基于云的应用程序或服务部署到特定的云基础设施上，往往由于不易察觉的技术绑定而被牢牢锁定在该基础设施上。迁移到另一个云基础设施通常是一项耗时且昂贵的一次性工作。一个很好的现实案例是Instagram。在被Facebook收购后，Instagram工程团队花费了一年多的时间才找到并实施将其所有服务从亚马逊网络服务迁移到Facebook数据中心的解决方案。尽管未计划任何停机时间，但在迁移期间仍发生了显著的服务中断。

美国国家标准与技术研究院（NIST）对云计算的定义提出了三个基本且广为接受的服务类别4：基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。IaaS为消费者自行创建的软件提供了最大程度的灵活性，但几乎不隐藏应用程序的操作复杂性（仅隐藏了基础设施的操作复杂性）。而SaaS几乎完全隐藏了操作复杂性，但对于涉及消费者自创软件的许多用例来说则过于受限。PaaS是一种折中方案，能够在方便地管理消费者自创软件的同时降低操作复杂性，但代价是在一定程度上接受因平台导致的锁定情况。

在名为CloudTRANSIT的项目过程中，我们积极寻找解决方案以克服“云锁定”问题——使云计算真正成为一种商品。我们开发并评估了一种具备原型状态的云应用可迁移性概念，该概念目前已适用于约70%的云市场，并可扩展至覆盖其余市场份额。然而，对本论文而言重要的是，我们在与从业者的行动研究中获得了一些核心见解：
- 从业者希望能够在平台之间进行选择；
- 从业者更喜欢声明式和控制论的（自动调整的）方法，而不是基于工作流的（命令式）部署和编排方法；
- 从业者被迫高效利用云资源，因为越来越多的系统被迁移到云基础设施上，导致费用持续增加；
- 从业者对解决方案的实用性评价远高于云平台和基础设施的完整功能覆盖。

1.3 研究问题

所有这些因素影响着从业者如何构建专为云环境而设的云应用架构。我们学到的一点是，云原生应用——尽管各不相同——但遵循一些共同的架构模式，我们可以利用这些模式来实现可迁移性。本论文探讨了如何将这些从云原生计算中获得的经验教训迁移到仿真与建模领域这一研究问题。

1.4 概述

因此，本文其余部分的结构如下。我们在第2节中提出一个云计算应用参考模型，该模型指导了我们在云计算领域的研究。根据我们过去10年中的经验与行动研究活动，云计算主要由两个长期趋势主导，这两个趋势将在第3节中进行探讨。特别是，我们将在第3.1节中研究资源利用率的提升，在第3.2节中探讨云计算应用程序的架构演进。第4节将分析这两个趋势在建模与仿真社区中可能引发的未来发展趋势。第5节将呈现来自云计算及建模与仿真即服务领域相关的相关工作，为读者提供有价值的后续内容。我们将在第6节总结全文，并对云计算和建模与仿真即服务领域未来更加去中心化以及更细粒度的服务组合方法进行展望。

2. 参考模型

我们的问题意识主要源于所开展的研究项目CloudTRANSIT。该项目探讨了如何在不停机的情况下，在不同公有云和私有云服务提供商的云基础设施之间，在运行时迁移云应用程序和服务，以应对云计算中现存且日益严重的供应商锁定问题。在该项目期间，我们发表了20多篇研究论文。然而，本文的目的不是总结这些论文。感兴趣的读者可参考相应的技术报告5，该报告对这些成果提供了综合性的概述。

几乎所有的云系统工程师都关注一个共同的问题。他们基于分布式和云的系统的核心组件，例如虚拟化服务器实例以及基本的网络和存储，可以使用通用服务进行部署。然而，进一步用于以弹性、可扩展且实用的方式集成这些虚拟化资源的服务，却常常未被纳入标准范畴。在几乎所有云服务基础设施上设计弹性且可扩展的云原生系统时，都需要负载均衡、自动伸缩或消息队列系统等服务。尽管存在一些标准，例如用于消息传递的AMQP6（其起源几乎可追溯到云时代之前），但这些对于处于较高云成熟度级别的几乎所有云应用都至关重要的集成与“粘合”类服务，往往并未由云提供商以标准化的方式提供7。似乎所有公有云服务提供商都在试图促使云客户使用其非通用的便利性服务“解释版本”，以将客户绑定到它们的基础设施及更高级别的服务组合中。

此外，根据我们在2016,8中进行的分析，诸如CIMI、9OCCI、10,11 CDMI、12OVF、13 OCI、14和TOSCA等标准所涵盖的这些通用服务类别的比例多年来甚至有所下降。这主要是因为新的云服务类别推出的速度超过了标准化机构对现有服务类别进行标准化的速度。图1以亚马逊网络服务多年的发展为例展示了这一现象。因此，供应商

在云计算中出现了锁定问题。有关更详细的讨论，我们参考Opala-Martins等人16、Kratzke等人8以及Kratzke和Peinel17。

因此，所有审查的云计算标准都聚焦于一组最小但必要的主流云服务子集：计算节点（虚拟机）、存储（文件、块、对象）以及（虚拟私有）网络。诸如TOSCA之类的标准化部署方法，主要基于这种商品化基础设施抽象层来定义。这类服务通常被归为基础设施即服务（IaaS），构成了云服务乃至云原生应用的基础。其他所有服务类别则可能导致供应商锁定情况。

这听起来可能令人失望。因此，许多云工程团队遵循一个基本理念：云原生应用栈应仅使用经过良好标准化的IaaS服务中的最小子集作为基础构建模块。由于现有的云计算标准仅覆盖特定的云服务类别（主要是IaaS级别），并未提供一个集成的视角，因此建立一个吸收从业者最佳实践的集成参考模型将大有帮助。

云计算通常从服务模型视角（IaaS、PaaS、SaaS）或部署视角（私有云、公有云、混合云、社区云）进行研究。4或者，也可以从参与者视角（提供商、消费者、审计员、代理、运营商）或功能视角（服务部署、服务编排、服务管理、安全、隐私）进行分析，正如Bohnenberger等人18所做的那样。采用不同的视角有助于将问题划分为清晰的组成部分。然而，上述观点在云计算中可能是常见的，从服务提供商的角度来看是有用的，但从云原生应用工程的角度来看则不然。从工程角度来看，对云原生应用工程中涉及和应用的技术层次进行观察似乎更为有用。

通过利用我们的系统映射研究19以及对云计算标准的回顾17，我们编制了一个云原生应用的参考模型。该分层参考模型在图2中展示并进行了解释。此参考模型的基本思想是仅使用一小部分高度标准化的IaaS服务作为基础构建模块（第1层）。该模型的整体结构由四个主要视角构成。
- 基础设施供应 ：这是在基础设施级别工作的工程师们所熟悉的视角，也是理解基础设施即服务（IaaS）的方式。IaaS 涉及为云消费者部署独立的计算节点。云消费者必须管理这些（数百个）已请求且相互隔离的节点。
- 集群弹性平台 ：对于处理跨节点横向扩展性的工程师来说，这是一个熟悉的观点。集群是一种将多个第1层节点作为单个逻辑计算节点（即集群）来管理的概念。这类技术通常是可移植云运行时环境的技术支柱，因为它们隐藏了复杂性（成百上千个单个节点的复杂性）。

适当地。此外，该层实现了在不依赖特定云服务、云平台或云基础设施的情况下定义服务和应用程序的基础。因此，它为避免供应商锁定提供了基础。
- 服务组合 ：这是应用工程师在面向服务的架构（SOA）中处理Web服务时熟悉的观点。这些（微）服务运行在第二层云运行时平台（如Kubernetes、Mesos、Swarm、Nomad等）上。因此，这些服务的复杂编排和扩展被抽象并委托给第二层的集群（云运行时环境）。
- 应用 ：这是云服务（或云原生应用）的最终用户所熟悉的观点。这些云服务由在由单个计算和存储节点组成的集群上运行的更小的云第3层服务构成。

有关更多细节，我们参考Kratzke和Peinel17以及Kratzke和Quintrup5。然而，本文其余部分遵循此模型。

3. 云计算中的可观察长期趋势

云计算大约在10年前出现。在最初的采用阶段，现有的IT系统只是被转移到云环境中，而没有改变这些应用程序的原始设计和架构。分层应用程序仅仅是从业务专用硬件迁移到了云中的虚拟化硬件上。多年来，云系统工程师在平台（PaaS）和基础设施（IaaS）方面实现了显著改进，并建立了多项工程趋势。

所有这些趋势都试图优化云服务的特定质量因素，例如功能稳定性、性能效率、兼容性、可用性、可靠性、可维护性、可移植性和安全，以提高整体服务质量（QoS）。最受关注的质量因素是功能稳定性、性能效率和可靠性（包括可用性）。因此，表1中列出的这些工程趋势似乎在某种程度上是孤立的。我们希望从两个不同的角度来审视这些趋势。

趋势	原理
微服务	微服务可以被视为面向服务的架构的一种“务实”解释。除了面向服务的架构之外，微服务架构有意地聚焦并组合小型且可独立替换的水平可扩展组件，专注做好一件事的服务。
DevOps	DevOps 是一种强调软件开发者与IT运维人员协作的实践。其目标是使用自动化流程更快、更频繁、更可靠地构建、测试和发布软件。DevOps 促进了对独立可替换的标准化部署单元的需求，因此推动了微服务架构和容器技术的发展。
云建模语言	基础设施和网络的软件化使得人们能够自动化软件交付过程，且基础设施变化更加迅速。云建模语言可以表达应用程序和服务及其应部署到此类基础设施或平台的弹性行为。
标准化部署单元	部署单元将软件封装在包含运行所需一切内容的完整文件系统中：代码、运行时、系统工具、系统库。因此，可确保软件始终运行相同，无论其环境如何。这种部署方法通常使用容器技术实现。（OCI标准）。每个部署单元应根据一组设计和互连面向云的模式，例如十二要素应用集合、断路器模式和云计算模式。
弹性平台	弹性平台，例如Kubernetes、Mesos或Swarm，可被视为弹性的统一中间件基础设施。弹性平台扩展了资源共享，并提高了底层基础设施的利用率，用于定制但标准化的部署单元的计算、网络和存储资源。
无服务器	“无服务器”这一术语用于描述一种架构风格，该风格应用于云应用架构中，严重依赖外部第三方服务（后端即服务，BaaS），并通过小型组件集成这些服务，基于事件触发的函数（函数即服务，FaaS）。FaaS 扩展了弹性的资源共享，通过简单应用分时概念实现的平台。
状态隔离	无状态组件比有状态组件更容易水平扩展/缩减。当然，有状态组件无法完全避免，但应将其减少到最小程度，并通过有意设计的水平可扩展存储系统（通常是最终一致的NoSQL数据库）来实现。
版本化REST API	基于REST的API提供可扩展且实用的通信，这意味着主要依赖于已有的互联网基础设施和定义明确且广泛应用的标准。
松耦合	服务组合通过事件或数据实现。事件耦合依赖于消息解决方案（例如，AMQP标准）。数据耦合通常依赖于可扩展但（主要是）最终一致性存储解决方案（这些通常被归为NoSQL数据库）。

表1. 伴随云原生应用出现的一些可观测的软件工程趋势。

云原生应用：云原生应用程序；SOA：面向服务的架构；API：应用程序编程接口。

3.1 资源利用

云基础设施（IaaS）和平台（PaaS）被设计为具有弹性。弹性是指系统通过自动配置和释放资源以适应工作负载变化的程度。如果没有弹性，云计算往往在经济上是不合理的。随着时间的推移，系统工程师逐渐更好地理解了现代云环境中的弹性选项。最终，系统被针对这种弹性云基础设施进行设计，从而通过容器、微服务或无服务器架构等新的部署和设计方法，提高了底层计算基础设施的利用率。这种设计理念通常用“云原生”一词来表达。

图3显示了过去十年中的一个显著趋势。机器虚拟化被引入以整合许多裸机，从而更高效地利用物理资源。这种机器虚拟化构成了IaaS云计算的技术支柱。虚拟机可能比裸机服务器更轻量，但仍然较为笨重，尤其是在镜像大小方面。由于具有更高的细粒度，容器改进了标准化部署的方式，同时也提高了虚拟机的资源利用率。

然而，尽管容器可以快速扩展，但它们仍然是常驻组件。这就是函数即服务（FaaS）方法出现并应用于底层容器平台上的容器时间共享的原因。由于在同一硬件上对容器进行时间共享执行，FaaS甚至实现了零扩展能力。这种提升的资源效率甚至可以通过货币形式来衡量。22因此，随着时间推移，管理云中资源的技术栈变得越来越复杂且难以理解，但始终遵循一个趋势——在相同数量的物理机器上运行更大的工作负载。

3.1.1 面向服务的部署单体

面向服务的计算是一种用于分布式计算和电子商务处理的范式，旨在管理分布式系统的复杂性并集成不同的软件应用。服务主要通过消息传递向其他服务提供功能。服务将其接口与实现解耦。此类应用程序对应的架构称为面向服务的架构（SOA）。近几十年来，许多商业应用都是遵循这一架构范式开发的。此外，由于其底层的服务概念，这些应用程序可以毫无问题地部署在云环境中。然而，对于云系统工程师而言，主要问题在于：尽管这类应用程序由分布式服务组成，但它们的部署却并非分布式的。这类

从部署角度来看，分布式应用在概念上是单体式应用程序。换句话说，在进行更新或新服务发布时，必须一次性部署完整的分布式应用程序。这种单体式风格甚至导致整个应用程序被简单地打包成一个大型虚拟机镜像。这与图3（专用服务器与虚拟化）所示的情况完全吻合。然而，根据应用程序的规模，这通常会导致最终用户面临显著的停机时间，并且限制了在工作负载增加或减少时对应用程序进行扩展的能力。

显然，尤其是云原生应用伴随着此类24×7要求，即需要在运行时独立地部署、更新或扩展单个组件，且不能有任何停机时间。因此，面向服务的架构（SOA）演变为所谓的微服务架构风格。有人可能会提到，微服务主要是面向服务的架构（SOA）的一种更务实的版本。此外，微服务被有意设计为独立可部署、可更新和水平可扩展的。因此，微服务具有一些将在第3.2.1节中探讨的架构影响。然而，微服务的部署单元应是标准化和自包含的。这一方面将在第3.1.2节中进行探讨。

3.1.2 标准化和自包含的部署单元

虽然部署单体主要使用基础设施即服务以虚拟机形式提供的资源通常部署和更新频率较低，而微服务架构则将单体拆分为独立可部署的单元，这些单元的部署和终止更加频繁。此外，这种部署通常以水平可扩展的方式进行，并且经常由请求触发。当某个服务接收到大量请求时，会启动更多的服务实例，以便将请求分发到更多实例上；当请求减少时，则会关闭部分服务实例以释放资源（并节省成本）。因此，与传统部署单体和SOA方法相比，微服务架构的固有弹性能力受到更多关注。近年来微服务架构之所以获得广泛关注，其中一个关键成功因素可能是服务实例的部署可以被标准化为自包含部署单元——即所谓的容器。23容器利用操作系统虚拟化而非机器虚拟化（见图4），因而更加轻量。容器使扩展变得更加务实和快速，并且由于容器比虚拟机消耗更少的资源，实例密度得以降低。

然而，即使在微服务架构中，服务概念也是一种常驻运行概念。因此，每个微服务必须始终至少有一个服务实例（容器）处于活动和运行状态。因此，根据温曼的说法，常驻运行组件是最昂贵且可避免的云工作负载之一。3问题就出现了

![图4](图4. 比较容器和虚拟机（改编自Docker网站：https://www.docker.com/resources/what-container）

在实际请求的情况下，是否可以仅执行服务实例？这个问题的答案引出了函数即服务（FaaS）的概念以及相应的平台，相关内容将在第3.1.3节中讨论。

3.1.3 函数即服务

微服务架构提出了一种高效扩展计算资源的解决方案，而这种扩展在单体架构下难以实现。24由于可以通过标准化部署单元对每个微服务进行独立扩展（如第3.1.2节所述），所分配的基础设施能够更好地匹配微服务的需求。然而，微服务架构也带来了额外的开销，例如需要在云基础设施中逐一部署、扩展和运维每一个微服务。为应对这些问题，出现了诸如Kubernetes25和Mesos/Marathon26之类的容器编排平台。但这也把问题转移到了这些平台的运维上，而且这些平台本身仍是常驻运行组件。因此，在云服务生态系统中，所谓的无服务器架构和FaaS平台应运而生。其中AWS Lambda服务可能是最知名的一个，此外还有Google Cloud Functions、Azure Functions、OpenWhisk和Spring Cloud Functions等。然而，所有（商业）平台都遵循相同的原则：提供最小化且细粒度的服务（仅暴露一个无状态函数），并采用按运行时消耗计费模式（毫秒级）。

FaaS 比微服务更细粒度，并有助于函数的创建。因此，这些细粒度的函数有时被称为纳米服务。这些函数可以快速部署并自动扩展，并具有降低基础设施和运营成本的潜力。与部署单元不同

第3.1.2节中所述的方法——仍然是始终在线的软件组件——而函数仅在有活跃请求时才被处理。因此，与单纯的容器化部署方法相比，FaaS 可以更加成本高效。根据Bilgin et al.在一项案例研究中对单体式、微服务和FaaS架构进行的成本比较研究，22最多可实现75%的成本降低。

另一方面，仍然存在一些未解决的问题，例如无服务器三难困境。无服务器三难困境“描述了无服务器函数在经济性、性能和同步组合之间的内在矛盾”。Baldini等人强调的一个明显问题是图5所示的“双重支付问题”。当一个无服务器函数f同步调用另一个无服务器函数g时，就会出现此问题。消费者需要为f和g的执行付费——尽管只有g在消耗资源，因为f正在等待g的结果。为了避免这种双重支付问题，许多无服务器应用程序将细粒度无服务器函数的组合任务委托给FaaS平台范围之外的客户端应用和边缘设备。这一组合问题导致了第3.2.2节中所研究的新形式的云原生架构——更加分布式和去中心化的架构。

3.2 架构演进

读者已在第3.1节中了解到，云原生应用程序主要通过采用更细粒度的部署单元（如轻量级容器而非虚拟机，或FaaS方法中的函数）来提高资源利用率。此外，这些资源利用率的提升对云架构的设计方式产生了影响。应用程序不断发展。在过去十年中，云应用架构中出现了两种主要的架构趋势：微服务和无服务器架构。我们将在第3.2.1节中研究微服务架构，在第3.2.2节中研究无服务器架构。

3.2.1 微服务架构

微服务构成一种基于成熟模块化概念但强调技术边界的软件和系统架构方法。每个模块——即每个微服务——都被实现并作为小型但独立的系统来运行，通过明确定义的网络接口提供对其内部逻辑和数据的访问。这种架构风格提升了软件敏捷性，因为每个微服务都成为开发、部署、运维、版本控制和扩展的独立单元。28

微服务架构常被提及的优势包括更快的交付、改进的可扩展性以及更高的自主性。28,29在微服务架构中，不同的服务可以根据其特定需求和实际的请求触发条件相互独立地进行扩展。

此外，每个服务可以由不同的团队进行开发和运维。因此，微服务不仅具有技术影响，还具有组织影响。这些团队可以针对每项服务在编程语言、库、框架等方面做出局部决策。这种组织影响一方面使得各个责任领域内能够采用最佳的方法；但另一方面，也可能增加整个系统的技术异构性。此外，关于此类系统可维护性的长期影响，可能至今尚未被观察到。30

第一代微服务由使用容器技术打包的单个服务构成。这些服务随后通过容器编排工具（如Mesos）在运行时进行部署和管理。每个服务负责跟踪其他服务，并通过特定的通信协议调用它们。故障处理直接在服务源代码中实现。随着每个应用程序中服务数量的增加，可靠且容错的定位和调用适当的服务实例本身成为一个问题。如果新服务使用不同的编程语言实现，复用现有的发现机制和故障处理代码将变得越来越困难。因此，虽然选择自由和“多语言编程”常被视为微服务的优点，但它们也存在需要管理的缺点。

因此，第二代微服务架构采用了发现服务和可重用的容错通信库。常用的发现服务（如Consul，见表2）被用于注册提供的功能。在服务调用期间，所有协议特定功能和故障处理功能都被委托给适当的通信库，例如Finagle（见表2）。这简化了服务实现以及样板通信代码在各服务之间的重用。

第三代引入了作为透明服务中间件的服务代理，旨在提高软件的可重用性。所谓的边车将可重用的服务发现和通信功能封装为自包含服务，可通过当今几乎所有编程语言都提供的容错通信库进行访问。由于其网络中介的定位，边车非常适合监控微服务应用中所有服务交互的行为。这种中介正是服务网格技术（如Linkerd，见表2）背后的核心理念。这些工具扩展了自包含边车的概念，以提供更集成的服务通信解决方案。通过使用服务网格，运维人员能够对服务间通信实现更细粒度的控制，包括服务发现、负载均衡、容错、消息路由，甚至安全。

因此，除了纯粹的架构视角外，以下工具、框架、服务和平台（见表2）构成了我们当前对微服务这一术语的理解。
- 服务发现技术使服务能够相互通信，而无需明确引用其网络位置。
- 容器编排技术自动化了容器的分配和管理任务，将底层的物理或虚拟基础设施从服务开发者中抽象出来。这正是我们将该技术视为任何云原生应用栈必不可少的一部分的原因（参见图2）。
- 监控技术通常基于时序数据库，以实现对微服务资源在不同级别细节上的运行时监控和行为分析。
- 延迟和容错通信库使服务能够在系统配置持续变化的情况下更高效、更可靠地进行通信，其中大量服务实例会根据变化的请求触发不断加入和离开系统。
- 持续交付技术将解决方案集成到第三方服务中，这些服务通常会自动执行在大规模微服务生产环境中使用的DevOps实践。31
- 服务代理技术主要封装了与通信相关的功能，例如服务发现和容错通信，并通过HTTP暴露这些功能。

最后，最新的服务网格技术基于边车技术，提供了一个完全集成的服务间通信监控与管理环境。

生态系统组件	示例工具、框架、服务和平台（最后访问于2019年12月18日）
服务发现	Zookeeper (https://zookeeper.apache.org)，Eureka (https://github.com/Netflix/eureka)，Consul (https://www.consul.io)，etcd (https://github.com/coreos/etcd)，Synapse (https://github.com/airbnb/synapse)
容器编排	Kubernetes (https://kubernetes.io), Mesos (http://mesos.apache.org), Swarm (https://docs.docker.com/engine/swarm)，Nomad (https://www.nomadproject.io)
监控	Graphite (https://graphiteapp.org)，InfluxDB (https://github.com/influxdata/influxdb)，Sensu (https://sensuapp.org)，cAdvisor (https://github.com/google/cadvisor)，Prometheus (https://prometheus.io)，Elastic Stack (https://elastic.io/products)
容错通信	Finagle（https://twitter.github.io/finagle）、Hystrix（https://github.com/Netflix/Hystrix）、Proxygen（https://github.com/facebook/proxygen），Resilience4j（https://github.com/resilience4j）
持续交付服务	Ansible (https://ansible.com)，Circle CI (https://circleci.com/)，Codeship (https://codeship.com/)，Drone (https://drone.io)，Spinnaker (https://spinnaker.io)，Travis CI (https://travis-ci.org/)
服务代理	Envoy (https://www.envoyproxy.io)
服务网格	Linkerd（https://linkerd.io），Istio（https://istio.io）

表2. 一些可观测的微服务工程生态系统组件。

3.2.2 无服务器架构

无服务器计算是一种云计算执行模型，其中机器资源的分配是动态管理的，并且有意不在服务客户的控制范围内。与以容器为中心的PaaS或以虚拟机为中心的基础设施即服务相比，零伸缩能力是无服务器平台的关键区别之一。根据温曼的说法，零伸缩能够避免常驻运行组件，从而排除了最昂贵的云使用模式。这可能是自2014年以来“无服务器”这一术语变得越来越普遍的原因之一。然而，“无服务器”确切指的是什么？服务器肯定仍然存在于某个地方。

所谓的无服务器架构主要通过使用FaaS概念32并集成第三方后端服务来替代服务器的管理和运维。图3展示了过去十年中资源利用率优化的演进过程，最终形成了当前利用FaaS平台的最新趋势。FaaS平台应用分时原则，提高了计算基础设施的资源利用率，从而避免了昂贵的常驻运行组件。如前所述，至少有一项研究表明，由于这种分时共享，无服务器架构可将成本降低70%22。无服务器平台本质上仅是一个事件处理系统（见图6）。根据Baldini等人33的观点，无服务器平台接收一个事件（通过HTTP发送或来自其他事件），在云端进行源处理时，这些平台会确定哪些函数已注册用于处理事件，查找该函数的现有实例（或创建一个新实例），将事件发送到函数实例，等待响应，收集执行日志，使响应可供用户使用，并在不再需要时停止函数。除了通过应用程序编程接口（API）组合与聚合来减少API调用外，基于事件的应用程序非常适用于这种方法。

无服务器平台提供模型可以分为以下几类。
- 公有云服务提供商的公共（商业）无服务器服务提供计算运行环境，也称为FaaS平台。一些知名的典型代表包括AWS Lambda、Google Cloud Functions和Microsoft Azure Functions。所有上述商业无服务器计算模型都容易在一定程度上产生供应商锁定。
- 开源无服务器平台（如Apache的OpenWhisk和OpenLambda）可能是一种替代方案，但缺点是这些平台需要基础设施。
- 与提供商无关的无服务器框架提供了一种与提供商和平台无关的方式来定义和部署在各种无服务器平台或商业无服务器服务上的无服务器代码。因此，这些框架是一种避免（或减少）供应商锁定的选项，而无需自行运维基础设施。

因此，一方面，无服务器计算提供了一些固有的优势，例如资源和成本效率、操作简单性，以及可能提高开发速度和缩短上市时间。32然而，无服务器计算也带来了一些值得注意的缺点，包括运行时约束、状态约束，以及尚未得到满意解决的函数组合问题（例如双重支付问题，参见图5）。

此外，由此产生的无服务器架构会带来安全影响，增加了攻击面，并将部分应用逻辑（服务组合）转移到客户端（而客户端并不完全受服务提供商控制）。此外，函数即服务还会加剧供应商锁定问题、客户端复杂性，以及集成和测试复杂性。

此外，图7显示，与传统的电子商务应用程序相比，无服务器架构（以及微服务架构）需要进行云应用架构重构。与微服务架构相比，无服务器架构有意集成了更多的第三方后端服务，例如认证或数据库服务。FaaS平台上的函数仅提供非常具体的服务、与安全相关的功能或计算密集型功能。所有在传统上由中心化系统提供的功能

4. 对建模与仿真即服务领域的影响

从不同角度阐述了对仿真即服务（MSaaS）的影响。第4.1节将通过若干示例应用场景，推导出云原生仿真（CNSs；见第4.2节）的一些启示。第4.3节将解释这些启示在云原生系统（CNS）中是如何被考虑的参考模型（见图8）。此外，第4.4节将讨论一些应予以考虑的局限性，以提高云原生仿真（CNSs）的整体成熟度（第4.5节）。

4.1 云仿真示例应用场景

已有多个成功部署到公共云计算基础设施的仿真模型实例和研究。35
- 名为Megaffic的基于云的分布式基于代理的交通模拟器。
- 可扩展的电动交通模拟云服务被用于研究大规模电动交通对城市基础设施的影响。37
- D-Mason框架是Mason库的一个并行版本，用于编写和运行分布式基于代理的模拟。38
- GridSpice 是一个用于分布式智能电网仿真的基于云的模拟平台。39

英国陆军正在研究虚拟现实（VR）、机器学习和云计算在陆军集体训练转型计划（CTTP； https://bit.ly/2r6oL51）中的潜力。一系列训练活动旨在展示虚拟现实（VR）和混合现实（MR）的能力。为了展现数据采集和基于机器学习的分析在军事训练中的潜在优势，分包商还将展示在此背景下云计算的应用。

Guzzetti等人40研究了不同高性能计算（HPC）平台对使用LiFEV（有限元库）进行计算性血流动力学数值仿真的影响。他们比较了内部计算集群、大规模基于大学的HPC集群和区域超级计算机与公共云的性能。根据他们的结果，云计算可用于科学计算流体动力学（CFD）模拟，且可能比使用更昂贵的本地计算集群具有更低的成本/性能。Ledyaev和Richter41通过在交通建模（网络优化）、高能物理（蒙特卡洛）和材料模拟（CFD）中的三个案例研究评估了私有云解决方案OpenStack。他们得出结论：云计算适用于多次运行非并发代码，但需要专用硬件来支持并行处理。

4.2 对云原生模拟的影响

如果我们分析这些示例，就会发现基于云的仿真是可行的，即使大规模问题也是如此。然而，规模经济在很大程度上依赖于仿真类型及其并行化处理方法。总结第3节的核心见解，我们得出以下从云原生领域获得的经验教训，并可将其应用于仿真场景中。首先，如果云原生应用是由服务组成的应用，那么相应地，CNS 就是由小型、独立、可部署和可替换的仿真服务构成的仿真系统，这些仿真服务以（类UNIX的）“专注做好一件事”方式运行，并能水平扩展以实现并行处理。

因此，现有的（单体式）仿真必须迁移到微服务架构中，并以某种方式从云就绪逐步演进到云原生成熟度级别（见表3）。云原生应用程序工程表明，在不进行重构的情况下，几乎不可能将现有应用程序一对一地转移到云环境中。

正如读者所注意到的，我们将提出一种基于已介绍的云原生堆栈（图2）的CNS架构（图8）。因此，相应的云原生仿真工程趋势（表4）源自通用的云原生工程趋势（表1）。云原生仿真栈及其对应的工程趋势是通过将通用的云原生概念系统地“替换”为更具体的CNS概念而整理得出的。这是因为我们假设云原生系统是一种具有某些特定需求的特殊云原生应用。然而，这一过程排除了一些已经讨论过的功能和软件趋势，例如可观测的DevOps趋势是一种通用的软件工程趋势。在此我们并未发现其对仿真服务工程的影响超出标准软件工程的范畴。但这并不意味着该趋势不应应用于仿真服务中。

级别	成熟度	标准
3	云原生	- 仿真可在运行时在不同基础设施提供商之间转移，且无需服务中断 - 仿真服务根据触发条件自动进行扩缩容。
2	云弹性	- 仿真服务状态在最少数量的服务中是隔离的。 - 仿真不受依赖服务故障的影响。 - 仿真是基础设施无关的。
1	云友好	- 仿真由松散耦合的仿真服务组成。 - 仿真服务可通过名称发现。 - 仿真服务按照云模式设计。 - 计算与存储分离。
0	云就绪	- 仿真可以在虚拟化基础设施上运行。 - 仿真可以从镜像或脚本实例化。

表3. 云仿真成熟度模型（改编自开放数据中心联盟）。

工程。这仅意味着我们在此看不到仿真特有的问题。云建模和云仿真工具（如CloudSim）在表示和分析云架构方面也是如此。乍一看，似乎显然也应该涵盖这些工具。然而，我们并不认为这些工具通常与云原生系统（CNSs）的研究相关，除非云仿真本身需要作为云原生系统来运行。但对云基础设施进行仿真的情况仅仅是一个特定的研究对象。本论文有意不过分关注特定于仿真的具体研究对象。

我们目前还没有一个通用定义来解释云原生系统（CNS）究竟是什么。然而，我们可以结合在云原生应用方面的经验，提出一个针对云原生仿真（CNSs）的定义建议。如果我们假设云原生系统是一种特殊类型的云原生应用，则应考虑以下方面。

Fehling 等人42提出，几乎所有的云原生系统都应该是 IDEAL：它们[i]隔离其状态，本质上是[d]分布式的，在横向扩展方面具有[e]弹性，运行在[a]自动化管理系统上，且其组件是[l]松散耦合的。根据 Stine 的观点，43云原生架构的共同动机包括更快速地交付基于软件的解决方案（速度），以更具故障隔离性、容错性和自动恢复能力的方式实现（安全性），支持水平（而非垂直）应用扩展（扩展），以及最终应对各种消费者平台和遗留系统（客户端多样性）。

几种应用架构和基础设施方法解决了这些常见的动机。
- 微服务代表将单体系统分解为可独立部署的服务，这些服务专注于做好一件事。44,45
- 在云原生应用架构中，服务之间交互的主要方式是通过已发布且带版本控制的API（基于API的协作）。这些API通常基于HTTP，并采用REST风格和JSON序列化，但也可以使用其他协议和序列化格式。
- 该架构的单一部署单元根据一系列面向云的模式（如十二要素）进行设计并相互连接。

云原生应用趋势	对仿真即服务的影响
微服务	仿真架构应由小型且可独立替换的水平组件构成可扩展的仿真服务，专注于做好一件事。
建模语言	现有的仿真建模语言应扩展以定义组合仿真服务及其弹性行为。
标准化部署单元	仿真部署单元应将仿真软件封装在完整文件系统中包含运行所需的一切：代码、运行时、系统工具、系统库。因此，它是确保软件无论在何种环境中运行都保持一致。这使用标准化容器技术（OCI标准）可以实现部署方法。
弹性平台	仿真平台应演变为云基础设施的统一中间件。此类平台扩展资源共享，提高底层计算和网络的利用率。以及用于定制但标准化的仿真部署单元的存储资源。
无服务器	无服务器仿真将用于一种用于基于云的架构风格严重依赖外部第三方仿真服务并集成这些服务的仿真通过小型基于事件触发的函数（函数即服务，FaaS）。
状态隔离	无状态仿真服务比有状态仿真更易于水平扩展/缩减服务。当然，有状态组件无法避免，但应尽量减少有状态组件的使用减少到最低限度，并通过有意设计的水平可扩展存储系统（通常最终一致的NoSQL数据库）。
版本化REST API	如果仿真服务提供版本化REST API，这本身就提供了可扩展的实用通信。这种仿真服务通信主要依赖于已有的互联网基础设施和定义明确且广泛应用的标准。甚至实现非“云原生”但仅具备仿真服务的无缝集成可互联网访问
松耦合	仿真服务组合可以通过事件或数据来实现。仿真中的事件耦合在“正常”情况下“云原生应用”依赖于消息解决方案（例如，AMQP标准）。数据耦合依赖在可扩展但（主要是）最终一致性存储解决方案上（这些通常被归为）NoSQL数据库

表4. 云原生仿真服务的可预期的软件工程趋势。

CNA：云原生架构；MSaaS：建模与仿真即服务；API：应用程序编程接口；AMQP：高级消息队列协议。

4.3 云原生仿真参考模型

这些方面使我们能够得出关于CNS系统及相应CNS架构的理解（图8）。

大量云原生应用架构的核心设计理念启发了所衍生的CNS架构（图8）的主导概念方法。第4层（或服务层）上的每个仿真都应由无状态的第3层仿真服务组成，这些服务依赖于管理和封装仿真状态的服务。这种关注点分离（仿真逻辑与仿真状态）使得分布式仿真能够为仿真状态选择最终一致性或强一致性模型。

尽管这使得功能性的仿真服务能够无缝实现横向扩展性，但根据我们的经验，这在云原生应用架构中是一种广泛采用且经过验证的模式。

另一个通用的云应用架构最佳实践是第3层仿真服务的部署标准化。通过第二层弹性仿真平台实现的这种部署标准化，使得人们能够在相同的物理或虚拟第1层硬件上运行大量服务。在通用云计算环境中，这通常通过基于容器的技术来实现。容器不过是一个自包含的部署单元，封装了其所有运行时依赖项。它通常通过基于REST的接口暴露其功能。此类容器可以在相应的容器平台（如Kubernetes、Mesos、Docker Swarm等）上运行。这类平台与应用程序无关，可用于任意类型的应用程序。因此，它们也可用于仿真服务也是如此。因此，我们建议在弹性仿真平台（第二层）中使用此类构建模块。

此外，所提出的CNS架构符合已成功标准化的分布式和联邦仿真的一般设计原则，例如通过高层体系结构（HLA）。HLA是分布式仿真的标准，用于通过组合（联邦）多个仿真来构建具有更大目标的仿真。HLA要求一个运行时基础设施（RTI），该设施提供一组标准化的服务，如HLA联邦成员接口规范中所规定。此RTI与所提出参考模型的第二层高度一致。接口规范中的其他HLA服务也可以映射到我们的模型中：
- 联邦管理服务 → 仿真部署单元编排器；
- 对象和所有权管理服务 → 有状态仿真服务；
- 时间管理服务 → 有状态仿真服务;
- 声明和数据分发服务 → 现有的消息解决方案（例如，所有高级消息队列协议（AQMP）消息代理）可由仿真部署单元协调器与其它仿真专用服务一起部署在第3层。

4.4 局限性讨论

我们必须承认，这种映射在当前抽象层次上仍然较为模糊。因此，在未来的MSaaS工作中，可以在第3层定义更多常见的、详细的跨功能仿真服务（如定时或消息传递服务）。然而，CNS架构并未要求特定的定时或消息传递仿真服务（或其他服务）。但它建议以语言无关的方式提供此类服务，正如微服务方法通过HTTP和基于REST的版本化API所实现的那样。采用此类通用的互联网通信标准，将有效解决当前基于HLA的方法的一个缺点。

由于高层体系结构（HLA）是一种面向消息的中间件，定义了一组服务，这些服务大多由C++或Java API提供，因此没有标准化的线上传输协议。因此，联邦中的参与者通常必须使用来自同一提供商的RTI库，并且应用程序要实现互操作，通常还必须使用相同版本的库。由此产生的仿真大多是所谓的部署单体。

相反，云原生应用栈不会请求一组特定的服务，而是通过互联网标准方式与每个仿真服务进行交互。ACNS 是一种分布式、弹性且水平可扩展的仿真系统，由仿真（微）服务组成，将状态隔离在最少数量的有状态组件中。该仿真的自包含部署单元根据面向云的设计模式进行设计，并在自助式弹性仿真平台上运行。

我们还必须考虑到，云计算传统上并非面向高性能计算（HPC）或仿真。人们经常提到，因此当前的物联网（IoT）方法正通过雾计算或边缘计算的方法来实现。然而，这更多是由于通信延迟问题，超大规模企业的区域数据中心之外的通信延迟超出了其控制范围。尽管如此，仿真通常基于消息传递或数据分析，而当前的云方法或仿真即服务（MSaaS）可能并不是合适的选择。美国国家航空航天局（NASA）最近的研究表明：“在所有情况下，在NASA本地资源上运行的总成本都低于在亚马逊网络服务（AWS）上运行的最低可能的仅计算成本。”49 这项NASA研究显示，基于云的仿真成本往往是本地仿真设施运行成本的两到十二倍。

这听起来令人失望。然而，该研究并未考虑到基于云的仿真应遵循一种不同的架构风格，以充分利用其经济效益。传统的仿真通常被称为部署单体，这类架构几乎不可扩展，且不符合云计算普遍采用的按需付费商业模式。对云原生应用领域的研究表明，云原生部署应采用更细粒度且水平可扩展的单元，以优化资源使用。如果能够实现这一点（这可能取决于具体仿真类型），那么Bilgin et al.22的其他研究显示成本可降低至25%。因此，如果我们综合考虑这两类研究结果，根据美国国家航空航天局的成本比较方法论，对于那些仍然贵出两到四倍的仿真任务而言，仿真即服务是一种合理的选择。这正是Taylor等人所指出的35 。然而，并非所有仿真都能从仿真即服务中获得同等程度的收益。

此外，读者应考虑到，许多小型公司、组织或独立研究人员无法获得与美国国家航空航天局（NASA）的高性能计算能力（HECC）项目相媲美的仿真设施。对于那些无法使用此类超级计算设施的人来说，成本和性能的比较意义不大。

4.5 如何提升仿真的云原生成熟度

应考虑以下设置以达到这样的云原生级别。
- 我们需要用于仿真组件（服务）的标准化部署单元以及一个用于运行业务的标准化平台。此外，这些部署单元应比虚拟机提供更高的运行密度。
- 基于事件触发的函数即服务仿真服务可用于避免昂贵的常驻运行组件。
- 基于函数即服务的仿真服务可能会改变仿真的架构，以避免双重支付问题（见图5）。此外，还需考虑函数即服务功能的运行时局限性、启动延迟以及状态保持，这些因素可能会限制特定类型仿真的适用性。
- 对时间敏感的仿真。
- 云原生应用中的横向扩展性主要通过松散耦合（基于事件）的微服务方法实现。这些可扩展性要求也应被纳入CNS架构的考虑范围。
- 这提出了对仿真服务网格的需求，即通过连接、保护、控制和监控仿真服务来实现仿真服务的松耦合。
- 基于FaaS的仿真服务组合问题可能会引发对特定领域特定语言（DSLs）的需求，以无缝组合各种类型的（有状态、无状态、无服务器）仿真服务。
- 为了便于操作，基于云的仿真平台的操作以及在这些平台上运行仿真的操作应被视为两个独立但互补的工程问题。为方便读者，相关的仿真专用工程趋势已列于表4中。

5. 相关工作

据作者所知，目前尚无调查从“宏观”和演化的角度专门关注过去十年云计算中可观察到的趋势。本文将这一演化分为以下几个方面：
- 资源利用率优化方法，例如容器化和函数即服务方法；
- 通过微服务和无服务器架构实现云应用程序的架构演进。

关于这四个方面（容器化、函数即服务、微服务、无服务器架构），均存在相关综述，读者应予以参考。研究和综述论文23,50–52主要涉及容器化及其伴随的资源效率。尽管函数即服务（FaaS）相对较新，目前在研究中尚未得到广泛反映，但已出现首批综述论文33,53–56，探讨了关于工具支持、性能、无服务器解决方案的模式、企业适用性以及无服务器架构是否会扩展到传统云平台和架构之外的一些开放性研究问题。

服务组合通过组合可由各种组织普遍提供的基础服务，来提供增值和高阶服务。57,58此外，服务计算已相当成熟，且已有大量关于面向服务的架构相关方面的综述。59–63然而，较新的研究主要集中在微服务上。Dragoni等人24、Jamshidi等人28以及Cerny等人64重点关注了架构视角以及面向服务的架构与微服务之间的关系。这些论文都非常有助于更好地理解当前微服务的“热潮”，强烈建议阅读这些论文。但这些论文局限于微服务，未考虑通用云应用程序和仿真架构演化的“全局”。通常，无服务器架构在某种程度上被视为微服务的一部分。作者并不完全确定无服务器架构是否并未从一方面的“零伸缩”能力以及另一方面尚未解决的函数组合问题（如双重支付问题）引入了对云仿真架构的根本性新影响。

建模与仿真产品对北约和军事领域具有极高价值，必须尽可能方便地让大量用户频繁访问建模与仿真产品、数据和流程。因此，需要建立一种新的建模与仿真生态系统，使大量用户能够同时、自发地根据各自需求访问建模与仿真产品。这种“即服务”模式必须支持独立使用，以及在需要时将多个仿真系统和真实系统集成到统一仿真环境中。已有多种方法朝此方向发展。65–67“作为服务的建模与仿真的盟国框架”是北约及其成员国实施仿真即服务的共同方法，由以下文件定义。1
- 作战概念文件（OCD）：该文件从用户的角度描述了作为服务的建模与仿真的盟国框架的预期用途、关键能力和期望效果。
- 技术参考架构：技术参考架构描述了实现仿真即服务功能的架构块和模式。
- 治理政策：治理政策确定仿真即服务的利益相关者及其关系，并为实施和维护作为服务的建模与仿真的盟国框架提供指导。

在本文的背景下，MSaaS技术参考架构68最为重要。MSaaS技术参考架构提供了在实现MSaaS能力时应考虑的技术指南、推荐标准、架构构建模块和架构模式。与CNS成熟度模型相比，MSaaS参考模型在更高层次上提供指导（如构建模块、模式等），但并未明确界定如何实现这些构建模块（例如，作为微服务或FaaS）。

6. 结论

由于云计算的内在成本结构对仿真服务保持不变，我们预测云原生系统（CNS）架构将遵循与云原生应用类似的趋势。这些相似趋势应使CNS服务更加趋向微服务式，甚至纳米服务式（类似于函数即服务）。为了充分利用云计算的机遇，它们应由更小、更细粒度且领域专用的仿真服务组成，仅“把一件事模拟好”。仿真服务应努力成为无状态的，或将状态隔离在最少数量的有状态组件中。由于仿真的本质深度依赖于状态（数据），这种对状态的关注甚至可能引发一些在“普通”云原生应用设计中并不常见的问题，需要开发新的解决方案。“经典”的云原生应用伴随着24×7要求。这些24×7要求对于仿真而言往往并非必需。这可能为仿真服务的云成熟度模型提供捷径机会。进一步详细分析云原生应用中的趋势和方法如何应用于云原生仿真（CNSs），以及可能产生的新挑战，将是一项有价值的未来研究。

美国国家航空航天局（NASA）最近的研究表明，基于云的仿真成本往往比在本地仿真设施上运行的仿真高出两倍甚至十二倍。然而，该研究并未考虑到基于云的仿真应采用不同的架构风格，以充分利用云基础设施的经济效益。如果能够实现仿真的这种云原生重构（这可能与具体仿真相关），那么其他研究表明成本可降低至25%。因此，如果我们综合考虑这两类研究结果，仿真即服务（MSaaS）或许虽不能适用于所有仿真，但对相当一部分仿真而言是一个合理的选择。

此外，许多小型公司、组织或独立研究人员无法使用与美国国家航空航天局的高性能计算与通信项目相媲美的模拟设施。对于所有无法访问超级计算设施的用户而言，此类成本与性能比较几乎没有意义。在此情况下，云计算可能是唯一可行的选择。