云原生仿真架构趋势
迈向云原生模拟——来自云计算一线的经验教训
摘要
云计算可能彻底改变仿真等计算密集型任务。即使是单个研究人员，也可以使用亚马逊、谷歌或微软提供的计算能力。然而，云计算的按使用付费成本模型影响了云原生系统的构建方式。我们将这些见解迁移到仿真领域。本文的主要贡献有两方面：（A）我们提出了一种云原生仿真栈；（B）推导出云原生仿真服务可预期的软件工程趋势。我们的见解基于对云原生应用的系统映射研究、对云标准的综述、与云计算从业者开展的行动研究活动以及相应的软件原型设计活动。在过去十年中，有两个主要趋势主导了云计算的发展：部署单元的规模被最小化，相应的架构风格更倾向于细粒度的服务分解，形成独立可部署且水平可扩展的服务。我们预测云原生仿真架构也将呈现类似趋势。这些趋势将使云原生仿真服务更加微服务式，具有可组合性，但仅专注于“把一件事模拟好”。然而，简单地将现有的仿真模型迁移至云端可能导致显著增加的成本。我们（及其他）研究的一个关键见解是，云原生系统应遵循云原生架构原则，以最大程度地利用按使用付费成本模型的优势。
关键词 云计算，云原生，云成熟度，仿真，参考模型，成熟度模式
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、Uber、WhatsApp、Netflix、Twitter——以及许多令人瞩目的小型公司（如果我们将其成立初期的员工数量与其显著的经济影响力相对比），这些公司的服务被频繁使用。然而，即使是快速增长的初创企业模式，也应考虑到长期的影响和依赖关系。这些公司中的许多都依赖公共云基础设施——通常由亚马逊网络服务（AWS）、微软（Azure）、谷歌（云服务）等提供商提供。与此同时，云服务提供商正在为大量不再运营自有数据中心的企业运行关键业务软件。此外，当工作负载的峰值与平均值之比较高时，使用云通常具有经济效益。3然而，也存在缺点。尽管云服务本可以成为标准化的商品，但实际上大多并非如此。一旦基于云的应用程序或服务部署到特定的云基础设施上，由于一些不易察觉的技术绑定，往往就会天然地受限于该基础设施。迁移到另一个云基础设施通常是一项耗时且昂贵的一次性工作。一个很好的现实案例是 Instagram。在被Facebook收购后，Instagram工程团队花了超过一年时间才找到并实施了解决方案，将其所有服务从亚马逊网络服务（AWS）迁移至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中进行的分析，诸如 CIMI9、OCCI10,11 、CDMI12、OVF13 、OCI14和 TOSCA15等标准所涵盖的此类通用服务类别的占比多年来甚至有所下降。这主要是由于新的云服务类别推出的速度超过了标准化机构对现有服务类别进行标准化的速度。图1以亚马逊网络服务（AWS）为例展示了这一趋势。因此，厂商
在云计算中出现了供应商锁定问题。有关更详细的讨论，我们参考奥帕拉-马丁斯等人16、克拉茨克等人8以及克拉茨克和佩因尔17的研究。
因此，所有经过审查的云标准都聚焦于一组最小但必要的主流云服务子集：计算节点（虚拟机）、存储（文件、块、对象）以及（虚拟私有）网络。诸如 TOSCA之类的标准化部署方法，主要是基于这种商品化基础设施抽象层来定义的。这类服务通常被归为基础设施即服务（IaaS），构成了云服务乃至云原生应用的基础。其他所有服务类别则可能导致供应商锁定情况。这听起来可能令人感到失望。因此，许多云工程团队遵循一个基本理念：云原生应用栈应仅使用一小部分良好标准化的IaaS服务作为基础构建模块。由于现有的云标准仅涵盖特定的云服务类别（主要是 IaaS级别），并未呈现一个集成的视角，因此，一个能够吸纳从业者最佳实践的更集成化的参考模型将大有帮助。
云计算通常从服务模型视角（IaaS、PaaS、 SaaS）或部署视角（私有、公共、混合、社区云）进行研究。4另一种方法是从参与者视角（提供商、消费者、审计员、代理、运营商）或功能视角（服务部署、服务编排、服务管理、安全、隐私）进行分析，正如博恩等人所采用的那样。18不同的视角有助于将问题划分为明确的部分。然而，上述提到的视角在云计算中可能是常见的，并且从服务提供商的角度来看是有用的，但从云原生应用工程的角度来看则不然。从工程的角度来看，对云原生应用工程中涉及和应用的技术层次进行观察似乎更有意义。
通过利用我们的系统映射研究19以及对云标准的回顾17，我们编制了一个云原生应用的参考模型。该分层参考模型在图2中展示并加以说明。此参考模型的基本思想是仅使用一小部分经过良好标准化的基础设施即服务作为基础构建模块（第1层）。四个主要视角构成了该模型的整体结构。
- 基础设施供应：这是在基础设施级别上工作的工程师们所熟悉的视角，也是理解基础设施即服务（IaaS）的方式。IaaS 涉及为云消费者部署独立的计算节点。云消费者必须管理这些（数百个）已请求且隔离的节点。
- 集群弹性平台：这对于处理跨节点横向可扩展性的工程师来说是一个熟悉的观点。集群是一种将多个第1层节点作为单个逻辑计算节点（一个集群）来管理的概念。这类技术通常是可移植云运行时环境的技术支柱，因为它们隐藏了复杂性（成百上千个单一节点的复杂性）。
适当地。此外，该层实现了在不依赖特定云服务、云平台或云基础设施的情况下定义服务和应用程序的基础。因此，它为避免供应商锁定提供了基础。
- 服务组合：这是应用工程师在面向服务的架构（SOA）中处理Web服务时熟悉的观点。这些（微）服务运行在第2层云运行时平台（如Kubernetes、 Mesos、Swarm、Nomad等）上。因此，这些服务的复杂编排和扩展被抽象化并委托给第2层的集群（云运行时环境）。
- 应用：这是云服务（或云原生应用）的终端用户所熟悉的一种观点。这些云服务由在由单个计算和存储节点组成的集群上运行的更小的云第3层服务构成。
有关更多细节，我们参考克拉茨克和佩因尔17以及克拉茨克和昆特5。然而，本文的其余部分遵循此模型。
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数据库。 |
CNAs：云原生应用；SOA：面向服务的架构；API：应用程序编程接口。
3.1 资源利用率
云基础设施（IaaS）和平台（PaaS）被设计为具有弹性的特性。弹性是指系统通过自动配置和释放资源以适应工作负载变化的程度。如果没有弹性，云计算在经济上往往是不合理的。随着时间的推移，系统工程师逐渐更好地理解了现代云环境的弹性选项。最终，系统被设计用于此类弹性云基础设施，通过容器、微服务或无服务器架构等新的部署和设计方法，提高了底层计算基础设施的利用率。这种设计意图通常用 “云原生”一词来表达。
图3显示了过去十年中一个显著的趋势。机器虚拟化被引入以整合许多裸机，从而更高效地利用物理资源。这种机器虚拟化构成了IaaS云计算的技术支柱。虚拟机可能比裸机服务器更轻量，但仍然较为笨重，尤其是在镜像大小方面。由于具有更高的细粒度，容器改善了标准化部署的方式，同时也提高了虚拟机的资源利用率。
然而，尽管容器可以快速扩展，但它们仍然是始终运行的组件。这就是函数即服务（FaaS）方法出现并应用于底层容器平台上的容器时间共享的原因。由于在同一硬件上对容器进行时间共享执行，FaaS甚至实现了零扩展能力。这种提升的资源效率甚至可以用货币来衡量。22 因此，随着时间推移，管理云中资源的技术栈变得越来越复杂且难以理解，但始终遵循一个趋势——在相同数量的物理机器上运行更大的工作负载。
3.1.1 面向服务的部署单体
面向服务的计算是一种用于分布式计算和电子商务处理的范式，旨在管理分布式系统的复杂性并集成不同的软件应用。服务主要通过消息传递向其他服务提供功能。服务将其接口与实现解耦。此类应用程序对应的架构称为面向服务的架构（SOA）。近几十年来，许多业务应用都是遵循这一架构范式开发的。此外，由于其底层的服务概念，这些应用程序可以毫无问题地部署在云环境中。然而，对云系统工程师而言，主要问题在于：尽管这类应用程序由分布式服务组成，但其部署却不是分布式的。这类
这一组合问题导致了第3.2.2节中研究的新一代更分布式、去中心化的云原生架构形式。
3.2 架构演进
读者已在第3.1节中了解到，云原生应用程序主要通过采用更细粒度的部署单元（如轻量级容器而非虚拟机，或FaaS方法中的函数）来实现更高的资源利用率。此外，这些资源利用率的提升对云架构的设计方式产生了影响
应用程序不断发展。在过去十年中，云应用架构中出现了两种主要的架构趋势（微服务和无服务器架构）。我们将在第3.2.1节中研究微服务架构，在第3.2.2节中研究无服务器架构。
3.2.1 微服务架构
微服务形成。一种基于成熟模块化概念但强调技术边界的软件与系统架构方法。每个模块——即每个微服务——都被实现并作为一个小型但独立的系统来运维，通过明确定义的网络接口提供对其内部逻辑和数据的访问。这种架构风格提升了软件敏捷性，因为每个微服务都成为开发、部署、运维、版本控制和扩展的独立单元。28
微服务架构常被提及的优势包括更快的交付、更好的可扩展性以及更高的自主性。在微服务架构中，不同的服务可以根据各自的具体需求和实际的请求触发条件相互独立地进行扩展。
此外，每个服务可以由不同的团队进行开发和运维。因此，微服务不仅具有技术层面的影响，还具有组织层面的影响。这些团队可以针对每项服务在编程语言、库、框架等方面做出局部决策。这种组织层面的影响一方面使得各个责任领域内能够采用最佳的方法；但另一方面，也可能增加整个系统的技术异构性。此外，关于此类系统可维护性的长期影响，可能至今尚未被观察到。30
第一代微服务由使用容器技术打包的单个服务组成。这些服务随后通过容器编排工具（如Mesos）在运行时进行部署和管理。每个服务负责跟踪其他服务，并通过特定的通信协议调用它们。故障处理直接在服务源代码中实施。随着每个应用程序中服务数量的增加，可靠且容错地定位和调用适当的服务实例本身成为一个问题。如果新服务使用不同的编程语言实现，复用现有的发现机制和故障处理代码将变得越来越困难。因此，尽管自由选择和“多语言编程”常被视为微服务的优点，但它们也带来了需要管理的缺点。
因此，第二代微服务架构采用了发现服务和可重用的容错通信库。常用的发现服务（如Consul，参见表2）被用于注册提供的功能。在服务调用期间，所有协议特定的功能和故障处理功能都被委托给适当的通信库，例如 Finagle（参见表2）。这简化了服务实施，并实现了通用通信代码在服务之间的重用。
第三代引入了作为透明服务中间件的服务代理，旨在提高软件的可重用性。所谓的边车将可重用的服务发现和通信功能封装为自包含的服务，可通过当今几乎所有编程语言提供的容错通信库进行访问。由于其网络中介的定位，边车非常适合监控微服务应用中所有服务交互的行为。这种中介正是服务网格技术（如Linkerd，参见表2）背后的核心理念。这些工具扩展了自包含边车的概念，以提供更加集成的服务通信解决方案。通过使用服务网格，运维人员能够对服务间通信实现更细粒度的控制，包括服务发现、负载均衡、容错、消息路由，甚至安全。
因此，除了纯粹的架构视角外，以下工具、框架、服务和平台（见表2）构成了我们当前对微服务这一术语的理解。
- 服务发现技术使服务能够相互通信，而无需明确引用其网络位置。
- 容器编排技术自动化了容器的分配和管理任务，将底层的物理或虚拟基础设施从服务开发者中抽象出来。这正是我们将该技术视为任何云原生应用栈必不可少的一部分的原因（见图2）。
- 监控技术通常基于时序数据库，以实现对微服务资源在不同级别上的运行时监控和行为分析。
- 延迟和容错通信库使服务能够在持续变化的系统配置中更高效、更可靠地进行通信，其中大量服务实例根据变化的请求触发条件不断加入和离开系统。
- 持续交付技术将解决方案集成到第三方服务中，这些服务通常会自动执行在Web规模的微服务生产环境中常用的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) |
4. 对建模与仿真即服务领域的影响
从不同的角度阐述了对建模与仿真即服务（MSaaS）的影响。第4.1节将介绍几个示例用例，以推导出云原生仿真（CNSs；见第4.2节）的一些启示。第4.3节将解释这些启示如何在云原生仿真中被考虑。参考模型（见图8）。此外，第4.4节将讨论一些应予以考虑的局限性，以提高云原生仿真的整体成熟度（第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）模拟，且可能比使用更昂贵的本地计算集群具有更低的成本/性能。Ledyayev和Richter41通过交通建模（网络优化）、高能物理（蒙特卡洛）和材料模拟（CFD）三个案例研究评估了私有云解决方案 OpenStack。他们得出结论：云计算适用于多次运行非并发代码，但需要专用硬件来支持并行处理。
4.2 对云原生模拟的影响
如果我们分析这些示例，就会发现基于云的仿真是可行的，即使对于大规模问题也是如此。然而，规模经济在很大程度上依赖于这类仿真和并行化处理方法。总结第3节的核心见解，我们可以从云原生领域得出以下可应用于仿真场景的经验教训：首先，如果云原生应用是由服务组成的应用，那么相应地，云原生仿真（CNS）应是由小型、独立、可部署和可替换的仿真服务组成的仿真，这些仿真服务以类似UNIX的方式“把一件事做好”，并且能够水平扩展以实现并行处理。
因此，现有的（单体的）仿真必须迁移到微服务架构，并以某种方式从云就绪演进到云原生成熟度级别（见表3）。云原生应用程序工程表明，在不进行重构的情况下，几乎不可能将现有应用程序一对一地转移到云环境中。正如读者所注意到的，我们将提出一个CNS栈（图8），它深度基于前文介绍的云原生堆栈（图2）。因此，相应的CNS工程趋势（表4）源自通用的云原生工程趋势（表1）。云原生仿真栈以及相应的工程趋势是通过系统地将通用的云原生概念“替换”为更具体的CNS概念而汇编而成的。这是因为我们认为云原生仿真是一种具有某些特定需求的特殊云原生应用。然而，这也排除了一些已经讨论过的功能和软件趋势，例如可观测的DevOps趋势是一种通用的软件工程趋势。我们在此并未发现其对仿真服务工程的影响超出标准软件工程的范畴。但这并不意味着该趋势不应应用于仿真服务中。
| 级别 | 成熟度 | 标准 |
|---|---|---|
| 3 | 云原生 |
- 仿真可在运行时在不同基础设施提供商之间迁移，且无需服务中断
- 仿真服务根据触发条件自动进行扩缩容。 |
| 2 | 云弹性 |
- 仿真服务状态在最少数量的服务中是隔离的。
- 仿真不受依赖服务故障的影响。 - 仿真是基础设施无关的。 |
| 1 | 云友好 |
- 仿真由松散耦合的仿真服务组成。
- 仿真服务可通过名称发现。 - 仿真服务是按照云模式设计的。 - 计算与存储分离。 |
| 0 | 云就绪 |
- 仿真可以在虚拟化基础设施上运行。
- 仿真可以从镜像或脚本实例化。 |
云建模和云仿真工具（例如 CloudSim）在表示和分析云架构方面也是如此。乍一看，似乎显然也应该涵盖这些工具。然而，我们并不认为这些工具在一般情况下与云原生仿真的研究相关，除非云仿真本身需要作为云原生仿真来运行。然而，对云基础设施进行仿真的情况仅仅是一个特定的研究对象。本文有意不过分关注特定于仿真的具体研究对象。
我们目前没有一个共同的定义来准确解释什么是云原生仿真（CNS）。然而，我们可以利用在云原生应用方面的经验，提出一个针对CNSs的定义建议。如果我们假设云原生仿真是云原生应用的一种特殊类型，则应考虑以下方面。Fehling 等人42提出，几乎所有的云原生系统都应该是 IDEAL 的：它们 [i]隔离其状态，本质上是 [d]分布式的，在水平扩展意义上具有 [e]弹性，运行在 [a]自动化管理系统之上，且其组件是 [l]松散耦合的耦合。根据Stine的说法，43云原生架构的共同动机包括更快地交付基于软件的解决方案（速度），以更有效地实现故障隔离、容错和自动恢复（安全性），支持应用程序的横向（而非纵向）扩展（扩展），以及最终应对消费者平台和遗留系统的多样性（客户端多样性）。
多种应用架构和基础设施方法解决了这些共同的动机。
- 微服务代表将单体系统分解为可独立部署的服务，每个服务都“把一件事做好”。44,45
在云原生应用架构中，服务之间的主要交互方式是通过已发布且带版本的API（基于API的协作）。这些 API通常基于HTTP，并采用REST风格和JSON序列化，但也可以使用其他协议和序列化格式。
- 该架构的单一部署单元根据一系列面向云的模式（如十二-）进行设计和互连
| 云原生应用趋势 | 对MSaaS的影响 |
|---|---|
| 微服务 | 仿真架构应由小型且可独立替换的水平组件构成 可扩展的仿真服务，专注于“把一件事做好”。 |
| 建模语言 | 现有的仿真建模语言应被扩展以定义组合 仿真服务及其弹性行为。 |
| 标准化的 部署单元 | 仿真部署单元应将仿真软件封装在完整文件系统中 包含运行所需的一切：代码、运行时、系统工具、系统库。因此，它是 确保软件无论在何种环境中运行都保持一致。这 使用标准化的容器技术（OCI标准）可以实现部署方法。 |
| 弹性平台 | 仿真平台应演变为云基础设施的统一中间件。此类 平台扩展资源共享，提高底层计算、网络 和存储资源对于定制但标准化的仿真部署单元的利用率。 |
| 无服务器 | 无服务器仿真将用于一种架构风格，该风格应用于严重依赖外部第三方仿真服务的基于云的仿真，并通过小型基于事件触发的函数（函数即服务，FaaS）集成这些服务 通过小型基于事件触发的函数（函数即服务，FaaS）。 |
| 状态隔离 | 无状态仿真服务比有状态仿真更易于水平扩展/缩减 服务。当然，有状态组件无法避免，但应尽量减少有状态组件的使用 减少到最低限度，并通过有意的水平可扩展存储系统（通常 最终一致的NoSQL数据库）。 |
| 版本化REST API | 如果仿真服务提供版本化REST API，这本身就提供了可扩展的 实用通信。这种仿真服务通信主要依赖于 已有的互联网基础设施和明确定义且广泛使用的标准。甚至 实现非“云原生”但仅提供仿真服务的无缝集成 可互联网访问 |
| 松耦合 | 仿真服务组合可以通过事件或数据来实现。在“正常”情况下的事件耦合 “云原生应用”依赖于消息解决方案（例如，AMQP标准）。数据耦合依赖 在可扩展但（主要是）最终一致性存储解决方案上（这些通常被归为） NoSQL数据库 |
CNA：云原生架构；MSaaS：建模与仿真即服务；API：应用程序编程接口；AMQP：高级消息队列协议。
4.3 云原生仿真参考模型
这些方面使我们能够得出关于CNS系统及相应CNS栈的以下理解（图8）。
大量云原生应用架构的核心设计理念启发了所推导出的CNS栈（图8）的主要概念方法。第4层（或服务层）上的每个仿真都应由无状态的第3层仿真服务组成，这些服务依赖于管理和封装仿真状态的服务。这种关注点分离（仿真逻辑与仿真状态）使得分布式仿真空能够为仿真状态选择最终一致性或强一致性模型。尽管这使得功能仿真服务能够无缝实现横向可扩展性，但根据我们的经验，这也是云原生应用架构中广泛采用且经过验证的模式。
另一个通用的云计算应用架构最佳实践是第3层仿真服务的部署标准化。通过第2层弹性仿真平台实现的这种部署标准化，使得能够在相同的物理或虚拟第1层硬件上运行大量服务。在通用的云计算环境中，这通常通过基于容器的技术来实现。容器只不过是封装了其所有运行时依赖项的自包含部署单元。它通常通过基于REST的接口暴露其功能。此类容器可以在相应的容器平台（如Kubernetes、Mesos、Docker Swarm等）上运行。这类平台与应用程序无关，可用于任意类型的应用程序。因此，它们也可用于仿真服务。因此，我们建议将此类构建模块用于弹性仿真平台（第2层）。
此外，所提出的CNS栈符合已成功标准化的分布式和联邦仿真的一般设计原则，例如通过高层体系结构（HLA）。HLA是分布式仿真的标准，用于通过组合（联邦）多个仿真来构建具有更大目的的仿真。HLA要求一个运行时基础设施（RTI），该基础设施提供一组标准化的服务，如HLA联邦成员接口规范中所规定。此RTI与所提出参考模型的第2层高度一致。接口规范中的其他HLA服务也可以映射到我们的模型中：
- 联邦管理服务 →仿真部署单元编排器；
- 对象和所有权管理服务 →有状态的仿真服务；
- 时间管理服务 →有状态仿真服务;
- 声明和数据分发服务 →现有的消息解决方案 （例如，所有高级消息队列协议（AQMP）消息代理）可由仿真部署单元协调器在第3层与其他仿真专用服务一同部署。
4.4 局限性讨论
我们必须承认，这种映射在当前抽象级别上仍然较为模糊。因此，在未来的MSaaS工作中，可以在第3层定义更多常见的、详细的跨功能仿真服务（如定时或消息传递服务）。然而，CNS栈并不强制要求特定的时间或消息传递仿真服务（或其他服务）。但它建议以与编程语言无关的方式提供此类服务，就像微服务通过HTTP和基于REST的版本化API所实现的那样。采用此类通用的互联网通信标准，将能有效解决当前基于HLA的方法的一个缺点。
由于高层体系结构（HLA）是一种面向消息的中间件，定义了一组服务，这些服务大多由C++或Java API提供，因此没有标准化的线上传输协议。因此，联邦中的参与者通常必须使用同一提供商的RTI库，并且应用程序要实现互操作，通常还必须使用相同版本。由此产生的仿真大多是所谓的部署单体。
相反，云原生应用栈不会请求一组特定的服务，而是通过互联网标准来对接每个仿真服务的方式以符合规范的方式。每个仿真服务都是一个自包含的部署单元，封装了其所有运行时依赖项。第3层及更高层上的每个仿真服务都应使用标准化的互联网协议（如HTTP和基于REST的方法）进行集成。
我们还必须考虑到，云计算传统上并非面向高性能计算（HPC）或仿真。人们经常提到，当前的物联网（IoT）方法因此正通过雾计算或边缘计算方法来实施。然而，这更多是由于通信延迟问题，超大规模企业的区域数据中心之外的通信延迟超出了其控制范围。尽管如此，仿真通常基于消息传递或数据分析，而当前的云方法或建模与仿真即服务（MSaaS）可能并不是合适的选择。美国国家航空航天局（NASA）最近的一项研究表明，“在所有情况下，使用 NASA本地资源运行的总成本都低于在亚马逊网络服务（AWS）上运行的最低可能的仅计算成本。”49该 NASA研究显示，基于云的仿真成本往往比在本地仿真设施上运行的仿真高出两到十二倍。
这听起来令人失望。然而，该研究并未考虑到基于云的仿真应遵循一种不同的架构风格，以利用其经济效益。传统的仿真通常被称为部署单体，这类架构几乎不可扩展，且不符合云计算通用的按需付费商业模式。对云原生应用领域的研究表明，云原生部署应采用更细粒度和水平可扩展的单元，以优化资源使用。如果能够实现这一点（这可能与具体仿真相关），Villamizar等人22的其他研究显示成本可降低至25%。因此，如果我们综合考虑这两类研究结果，根据 NASA的成本比较方法，对于仍然贵出两到四倍的仿真任务而言，建模与仿真即服务是一种合理的选择。这正是Taylor等人所指出的35 。然而，并非所有仿真都能从MSaaS中获得同等程度的收益。
此外，读者应考虑到，许多小型公司、组织或独立研究人员无法获得与美国国家航空航天局（ NASA）的高端计算能力（HECC）项目相媲美的仿真设施。对于那些无法使用此类超级计算设施的人来说，成本和性能的比较几乎没有意义。
4.5 如何提高仿真的云原生成熟度
应考虑以下设置以达到这样的云原生级别。
- 我们需要用于仿真组件（服务）的标准化部署单元以及一个用于运行它们的标准化平台。此外，这些部署单元应比虚拟机提供更高的运行密度。
- 基于事件触发的函数即服务仿真服务可被考虑用于避免昂贵的常驻组件。基于函数即服务（FaaS）的仿真服务可能会改变仿真的架构，以避免双重消费问题（见图5）。此外，还需考虑函数即服务（FaaS）函数的运行时局限性、启动延迟以及状态保持，这些因素可能会限制特定类型仿真的适用性 f对时间敏感的仿真。
- 云原生应用中的横向可扩展性主要通过松散耦合（基于事件）的微服务方法实现。这些可扩展性要求也应被纳入云原生仿真架构的考虑范围。这提出了对仿真服务网格的需求，以连接、保护、控制和监控仿真服务，从而实现仿真服务之间的松耦合。
- 基于FaaS的仿真服务组合问题可能会引发对特定领域特定语言（DSLs）的需求，以无缝组合各类（有状态、无状态、无服务器）仿真服务。
- 为了便于操作，基于云的仿真平台的操作以及在这些平台上运行仿真的操作应被视为两个独立但互补的工程问题。相关的仿真专用工程趋势列于表4中，以方便读者查阅。
5. 相关工作
据作者所知，目前尚无调查从“宏观”和演化的角度专门关注过去十年云计算中可观察到的趋势。本文将这一演化过程归纳为以下几个方面：
- 资源利用率优化方法，例如容器化和函数即服务方法；
- 通过微服务和无服务器架构实现云应用程序的架构演进。
关于这四个特定方面（容器化、函数即服务、微服务、无服务器架构），存在一些调查，读者应予以考虑。研究和调查23,50–52主要涉及容器化及其伴随的资源效率。尽管函数即服务（FaaS）相对较新，目前在研究中尚未得到广泛反映，但已出现首批综述论文33,53–56，探讨了FaaS方法，并提出了关于工具支持、性能、无服务器解决方案的模式、企业适用性以及无服务器架构是否会扩展到传统云平台和架构之外的一些开放性研究问题。
服务组合通过组合可由各种组织普遍提供的基础服务，来提供增值和高阶服务。57,58此外，服务计算已相当成熟，并且已有许多关于面向服务的架构相关方面的调查。59–63然而，最近的研究主要集中在微服务上。德拉戈尼等人24、贾姆希迪等人28以及切尔尼等人64关注的是架构视角以及面向服务的架构与微服务之间的关系。这些论文都非常有助于更好地理解当前微服务热潮。强烈建议阅读这些论文。然而，这些论文局限于微服务，未考虑通用云应用程序和仿真架构演化的 “全局图景”。很多时候，无服务器架构在某种程度上被视为微服务的一部分。作者并不完全确定无服务器架构是否没有引入一些根本性的新方面到云仿真架构中，这些新方面一方面源于“零扩展”能力，另一方面则源于尚未解决的函数组合问题（例如双重消费问题）。
建模与仿真产品对北约和军事领域具有极高价值，必须尽可能方便地让大量用户频繁访问建模与仿真产品、数据和流程。因此，需要建立一种新的建模与仿真生态系统，使大量用户能够根据各自需求同时、即时地访问建模与仿真产品。这种“即服务”范式必须支持独立使用，以及在需要时将多个模拟与真实系统集成到统一仿真环境中。已有多种方法朝此方向发展。65–67“仿真即服务盟军框架”是北约及其成员国实施建模与仿真即服务的共同方法，由以下文件定义。1
- 作战概念文件（OCD）：该文件从用户的角度描述了仿真即服务盟军框架的预期用途、关键能力和期望效果。
- 技术参考架构：技术参考架构描述了实现建模与仿真即服务功能的架构构建块和模式。
- 治理政策：治理政策识别建模与仿真即服务的利益相关者及其关系，并为实施和维护仿真即服务盟军框架提供指导。
建模与仿真即服务技术参考架构68在本文中最为重要。建模与仿真即服务技术参考架构提供了在实现建模与仿真即服务功能时应考虑的技术指南、推荐标准、架构构建模块和架构模式。与CNS成熟度模型相比，建模与仿真即服务技术参考模型在更高层次上提供指导（如构建模块、模式等），但并未明确说明如何实施这些构建模块（例如，作为微服务或函数即服务）。
6. 结论
由于云计算的固有成本结构对仿真服务保持不变，我们预测云原生仿真（CNS）架构将遵循与云原生应用类似的趋势。这些相似趋势应使CNS服务更加趋向于微服务式，甚至纳米服务式（类似于函数即服务）。为了充分利用云计算的优势，它们应由更小、更细粒度且领域专用的仿真服务组成，仅“把一件事模拟好”。仿真服务应努力变为无状态，或将在最少的有状态组件中隔离状态。由于仿真的本质深度依赖于状态（数据），这种对状态的关注可能会引发一些在“普通”云原生应用设计中并不常见的问题，需要开发新的解决方案。“经典”的云原生应用伴随着 24× 7要求，而这些 24× 7要求对于仿真而言往往并非必要。这可能为仿真服务的云成熟度模型提供捷径机会。深入分析云原生应用中的趋势和方法如何应用于云原生仿真（CNSs），以及可能出现的新挑战，将是一项有价值的未来研究。
美国国家航空航天局（NASA）最近的研究表明，基于云的仿真成本往往比在本地仿真设施上运行的仿真高出两倍甚至十二倍。然而，这项研究并未考虑到基于云的仿真应采用不同的架构风格，以充分利用云基础设施的经济效益。如果能够实现仿真的这种云原生重构（这可能因仿真而异），那么其他研究表明成本可降低至25%。因此，如果我们综合考虑这两类研究结果，建模与仿真即服务（MSaaS）或许并非适用于所有仿真，但对于相当一部分仿真而言将是一个合理的选择。
此外，许多小型公司、组织或独立研究人员无法使用与美国国家航空航天局的高性能计算与通信项目相媲美的模拟设施。对于所有无法访问超级计算设施的用户而言，此类成本和性能比较几乎没有意义。在此情况下，云计算可能是唯一可行的选择。
码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践
更多推荐
24
0- 0
已为社区贡献2条内容
所有评论(0)