PDF仿真：分布式系统中未被充分利用的工具
并非易事但也并非不可能，并且为了它能提供的洞察力而值得
David R. Morrison
2010 年代后半叶，在 Kubernetes 等技术以及轻松访问云计算资源的推动下，大规模转向基于云的基础设施，为传统软件开发领域内外的组织带来了巨大的好处。云将使部署应用程序变得廉价；Kubernetes 将使部署应用程序变得容易；而 DevOps 运动将使操作这些应用程序变得简单。事实上，许多这些预测已经成真：现在，各行各业（如农业和建筑业）、州、联邦和地方政府、非营利组织等等，硅谷内外的组织都在云端和 Kubernetes 之上运行和部署软件。
这些技术的爆炸性增长为基础设施工程师构建和部署极其多样化的工具和应用程序提供了一种通用语言；然而，令人难以置信的灵活性的另一面是几乎难以理解的复杂性。历史上非软件行业的工程师，他们可能甚至从未听说过 CAP 定理，现在也被要求应对分布式计算带来的所有难题。
当这些系统出现故障时（这是不可避免的），工程师们很难回答基本问题：哪里出了问题，为什么？ 现有的可观测性工具种类繁多——用于监控指标、抓取日志和分析追踪——但通常，当出现问题时，这些工具不足以理解根本问题。标准的软件开发技术，例如单元测试和集成测试、在暂存环境中的验证以及自动金丝雀分析，也不足以在问题发生之前将其捕获。
原因之一是生产系统中的错误通常是十亿分之一的事件，只有当您的系统每天处理十亿个事件时才会发生。换句话说，它们只在规模化时发生，并且不容易提前推理。
本文着眼于计算机科学家和基础设施工程师可以用来在问题发生之前推理其系统规模化的一个未被充分利用的工具。该工具就是仿真。本文描述了工程师可以用来仿真其集群的一些不同方法和工具，以及他们可以从中获得的知识，并介绍了一个使用 SimKube 的案例研究，SimKube 是应用计算研究实验室在 2024 年开发的 Kubernetes 仿真器。
为什么（不）仿真？
几十年来，仿真已在各种工程学科中使用。土木工程师使用仿真来确保桥梁安全；航空航天工程师使用它来确保他们的火箭发动机正常工作；气候科学家使用它来了解天气模式。为什么仿真不是 DevOps 工程师在其基础设施中使用的工具？
这有几个原因：首先，它很难做到。维护仿真器需要并行实现（部分）被测系统，并且随着被测系统的变化，仿真环境也必须随之变化。根据研究系统的复杂性以及仿真器所需的保真度，这项工作可能需要一个完全独立的团队专门维护仿真器并使其正常运行。
这在当今快速发展的科技行业中尤其适用。例如，Kubernetes 每年发布三个新版本，每个版本都包含改变系统行为的重大新功能。使仿真器与 Kubernetes 功能保持同步至少可以说是一项艰巨的任务。
仿真未在更多分布式计算环境中使用的第二个原因是，许多基础设施工程师没有统计方面的培训或专业知识来开发、运行和分析仿真结果。 这并非要贬低基础设施工程师。我过去参与的基础设施团队都充满了聪明才干的人，他们做得很好。我在这里的观点仅仅是，正确地运行仿真非常耗时，并且结果通常难以解释。如果没有合适的工具和培训，那么更多工程师不尝试仿真他们的系统是可以理解的。
仿真不是基础设施团队常用工具的最后一个原因是，成本效益权衡没有得到很好的理解，特别是对于管理层而言。让我们回到土木工程的类比，您可以看到建造桥梁的成本非常高，如果桥梁倒塌，成本会更高。因此，很容易论证在建造真实桥梁之前，对模拟桥梁施加极端条件和应力是值得的。
另一方面，云计算的出现在某种程度上将计算机工程师与他们运行的物理硬件分离开了。如果云虚拟机 (VM) 损坏，您可以直接将其关闭并启动另一个。此外，“快速行动，打破陈规”的敏捷思维鼓励工程师只需“尝试一下，看看会发生什么”，如果它坏了，那么很容易修复。考虑到人员编制有限，并且团队被要求用更少的资源做更多的事情，很容易理解为什么为运行仿真配备一个完全独立的团队对工程领导层来说不是一个有吸引力的前景。
正如本文所论证的那样，这些障碍都不是不可逾越的。仿真可以用于日常工程工作，并且收益大于成本。那么，这些好处是什么呢？
为什么要仿真？
基础设施团队定期（如果不是每天）使用仿真分析至少有四个好处：事后分析、回归测试、容量规划和功能设计。让我们看看其中的每一个。
事后分析
我们都经历过：凌晨 3 点，生产集群中的某些东西坏了，您刚刚收到寻呼。您昏昏沉沉地登录 VPN 并开始查看日志和指标。很明显有些东西出了问题，您只是不确定是什么。当其他几个人开始登录时，您加入 Zoom 会议并开始讨论补救方案。您做了一些小的调整，查找可能需要回滚的最近更改，然后——就像它开始时一样快——问题消失了。寻呼解除，所有指标恢复正常，你们都面面相觑，就像在说：“刚刚发生了什么？” 您花了一些时间调查，但找不到任何东西，每个人都很累，所以您回到床上，计划早上进一步调查。
早上来了，细节已经开始消退。最准确、最细粒度的指标已被聚合；受影响的主机已被关闭并从队列中循环退出；您仍然在 ElasticSearch 中有日志，但您知道时间在流逝，因为这些日志会在一周后被循环退出。经过几天的调查，您空手而归，唯一能做的就是等待看看它是否会再次发生。
如果相反，您可以完全重播前一天晚上发生的事件，一遍又一遍，在隔离的环境中？您可以更改环境并查看这是否能使问题变得更好或更糟。也许有一些您通常不收集的指标，您可以在模拟世界中开始收集这些指标，这可能会提供答案。然后，一旦您确定了问题，您可以验证修复，再次在您的测试环境中，而无需“在生产环境中测试”。听起来不错，对吧？
这正是仿真为分布式系统和基础设施团队提供的能力。通过收集事件“足够详细”的追踪，这些事件发生在生产环境中事件发生期间，您可以将该追踪保存在长期存储中，并根据需要多次重播事件，直到问题被识别出来并且可以制定完整的补救措施。（“足够详细”意味着什么的问题留给读者作为练习。）
回归测试
您的基础设施在不断变化。开发了需要新型硬件或部署现有软件的新方法的新产品功能。出现了新的工具，承诺解决您基础设施中的一个或另一个痛点。技术债务得到清理。所有这些更改都有可能引入，甚至更糟糕的是，重新引入您过去遇到的问题——即使您的更改已经过多次代码审查和良好的测试覆盖率。当您部署到生产环境时，您如何获得进一步的信心，确保事情不会出错？
许多组织中使用的常用技术包括暂存环境（它完全模仿您的生产环境，但不服务于生产流量）；渐进式部署（将更改部署到您基础设施的一小部分，然后逐渐将其推广到越来越大的百分比）；或自动金丝雀分析（查找您指标中的异常，并在检测到异常时回滚最近的更改）。所有这些技术都很好且有用，特别是结合使用时，但它们都有一个共同的缺陷：它们很昂贵。
分布式系统中的许多问题只有当系统“足够大”并且处于“显著负载”下时才会显现出来。维护与生产环境大小相同的暂存环境成本过高，并且渐进式部署方案不会捕获仅当更改部署到 90% 的队列时才会发生的问题。
仿真再次可以提供帮助。随着时间的推移，您可以创建生产基础设施追踪的集合，这些追踪代表“正常”操作和过去遇到的特定中断或事件。然后，在您的 CI（持续集成）管道中，在更改进入您的暂存环境之前，您可以模拟所有这些场景并将任何错误呈现给开发人员进行调查。您可以在每次合并到主分支时都这样做，作为类固醇上的端到端测试的一种形式——从某种意义上说，您正在将只能在规模上识别的问题的识别“左移”。
容量规划
说到规模，我想基础设施团队的每位工程师都曾被问到过这个问题，“如果我们的流量明天增加 10 倍，我们的基础设施会发生什么？” 或者他们被问到过相关的问题，“由于这个新功能，我们的流量明天将增加 10 倍，那么我们需要多少额外的计算资源？”
云计算时代已将容量规划推到了许多组织的后台。毕竟，如果您可以在需要时启动一些新硬件，为什么还要费心计划它呢？ 除非这并非许多类型工作负载的现实。 现代 AI 工作负载需要大量的 GPU 硬件，这些硬件通常供不应求，并且即使是更普通的计算资源也可能难以获得，具体取决于所需的数量以及一天中的时间或季节。
仿真也在这里提供了答案。您可以仿真您现在需要的云资源，或者您可以修改仿真输入（例如，通过获取现有的追踪并将其放大 10 倍），以尝试了解您将来需要什么以及这将花费多少成本。通过调整仿真参数，工程师可以生成一系列具有不同置信水平的不同场景，用于规划和预测。
功能设计
本文一直在“最不专业”到“最专业”的范围内移动，最后一个类别可能适用于最少数量的分布式系统工程师，但对于极其重要的一组工程师而言仍然如此：系统本身的设计者和构建者。如前所述，在规模上推理分布式系统可能非常困难，尤其是在不断向系统中添加新功能时。这些功能将如何交互？当两个看似不相关的功能由可能甚至不认识彼此的两位工程师实现时，以意想不到的方式发生冲突时会发生什么？
与回归测试一样，Kubernetes 等分布式系统的设计者可以使用仿真来验证他们提出的功能。如果每个想要在 Kubernetes 生态系统中从 alpha 升级到 beta 状态的功能的实施者，都必须提供仿真结果，显示拟议的功能在生产规模的 Kubernetes 集群上运行？这听起来像是一个白日梦，但事实并非如此——我们只需要投资于工具，使其成为可能且易于做到。
奖励应用：AI 训练
在更详细地检查这些工具之前，让我重点介绍分布式系统仿真的一个潜在应用，它具有不确定但可能很高的价值主张：分布式系统 AI 模型的训练。今天的 AI 系统需要大量的训练集和大量的计算资源来学习；为了构建 AI 基础设施工程师，该 AI 必须在数十万个类似生产的系统上进行训练，如果没有某种模拟环境，这几乎是不可能做到的。我在这里稍微保留了一些意见，因为即使那样，系统是否能够以今天熟练的高级工程师可以达到的程度推理分布式系统基础设施也是不确定的，但这无疑是一个令人兴奋的进一步探索领域。
操作指南：运行仿真
任何仿真都必须决定仿真环境的哪些组件将是真实的，哪些将是虚假的或模拟的。仿真设计者的目标是选择“正确”的模拟组件集。本节简要介绍在您的仿真环境中需要考虑的几个设计轴（Sulistio、Yeo 和 Buyya4 更详细地介绍了这些设计轴以及其他几个设计轴）。
系统的哪些组件被模拟？
在传统的工程仿真中（例如，桥梁），整个仿真都是捏造的。过程中没有任何“真实”的钢梁；一切都只是计算机中的数字。相比之下，一些仿真（例如，在赛车中）使用硬件在环方法，其中真实系统正在经历模拟的外部环境。分布式系统可以改为使用软件在环方法，其中部分或全部真实系统组件与模拟的外部环境交互。1
这两种方法各有优缺点：当我在 Yelp 工作时，我为 Apache Mesos 构建了一个完全虚假的仿真环境，该环境用于测试集群配置的更改。它运行良好，但很难与真实系统的更改保持同步。另一方面，我当前的项目 SimKube（在下一节中讨论）使用软件在环方法，这意味着它始终能够与最新的 Kubernetes 版本保持同步，但代价是仿真回放速度（SimKube 必须等待 Kubernetes 控制平面实时反应，而不管仿真的其余部分如何）。
时间是仿真的输入吗？
这是前一个问题的扩展，但它值得特别强调，因为时间使一切变得更加困难。在大多数情况下，您需要在仿真中包含一些时间概念。您可以运行时间点仿真。例如，对于桥梁，您可以计算当重物放置在桥梁上时瞬时施加的所有力，以查看它是否会断裂，但通常更有用的是考虑系统如何随时间演变：当重型汽车驶过桥梁时会发生什么？
在分布式系统中，您同样可以计算系统中某个时间点的快照，但大多数有趣的涌现行为都发生在系统演变过程中。因此，作为仿真构建者，您需要了解如何在仿真中表示时间。您的仿真是否必须实时运行，或者时间是仿真器的离散输入吗？您可以加速或跳过没有“有趣”事件发生的时间段吗？这会如何影响仿真的保真度？
您想要模拟哪些类型的事件？
为了构建可以回答您想要回答的类型问题的仿真器，您需要了解仿真的输入是什么。有很多方法可以回答或分类这些输入，但这里有两个：（1）仿真的输入是离散事件还是连续流？在物理仿真中，您可以考虑在时间 t 发生的离散事件，其中一个重物被放置在桥梁上，或者您可以考虑在一段时间内从一个速率变化到下一个速率的连续阵风（t0, t1）。（2）同样，对于分布式系统，您可以考虑在时间 t Kubernetes Deployment 从 A 个副本扩展到 B 个副本的离散事件，或者您可以考虑在一段时间内连续变化的流量流速率，该流量流速率击中特定端点。也许现在很明显了，但是您在这里做出的选择将极大地影响您可以运行的仿真类型。
当仿真偏离现实时您会怎么做？
运行仿真的全部意义在于创建现实的抽象；特别是，这意味着您运行的每个仿真都将是有损的。重要的问题是您是否仍然可以从有损仿真中收集有用的信息。最具挑战性的问题是：当您的仿真不再反映实际发生的情况时，您如何取得进展？
考虑一个真实的 Kubernetes 集群，其中的 Deployment 从 10 个副本扩展到 15 个副本。也许这种扩展活动是自动扩缩器中的错误造成的。您，负责该系统的基础设施工程师，修复了自动扩缩器中的错误，并想要重新运行仿真。您的更改导致 Deployment 从 10 个副本缩小到 5 个副本。您如何处理有关原始场景中扩展的五个 Pod 的信息？您是否将其丢弃并让仿真从那时起有机地演变？您是否保留该信息并在下次模拟 Deployment 需要扩展时应用它？这里没有正确的答案，您所做的一切都将涉及一些虚构。此时，您需要转向统计学：您可以计算可能发生的各种操作的概率吗？您可以为仿真的输出创建置信区间吗？然后，您仍然可以从您构建的虚构场景中获得一些有用的信息。
当然，在仿真中您还可以考虑许多其他设计方面；此处的目的不是提供运行每个可能仿真的全面指南，而是提供您需要用来思考您的环境中的仿真以及如何使用它们来获得所需答案的工具。
案例研究：SimKube
SimKube 是我在应用计算公司过去一年中一直在进行的项目，用于运行 Kubernetes 集群的仿真。它建立在理解和改进 Kubernetes 调度器的愿望之上，但我后来意识到它也具有许多其他应用。使用上一节的分类法，SimKube 是一个离散事件、实时、软件在环仿真环境（请注意，还有其他几种 Kubernetes 仿真器产品，包括 K8sSim5、Kubernetes-in-the-Loop3 和 Kubernetes 调度器仿真器；但这些仿真器环境在范围或功能上都与 SimKube 不同）。
SimKube 运行真实的 Kubernetes 控制平面（可能包括任何辅助控制器，例如集群自动扩缩器或 Karpenter、Apache YuniKorn，甚至内部自定义 Kubernetes 操作员），在其之上模拟了计算节点的“数据平面”。数据平面通过 KWOK (Kubernetes WithOut Kubelet) 实现，KWOK 提供了一系列机制来模拟计算节点以及计划在这些节点上的 Pod，而无需昂贵的云环境进行测试。
以下简要介绍了我如何使用 SimKube 运行一组仿真，比较 KCA (Kubernetes 集群自动扩缩器) 和 Karpenter。KCA 和 Karpenter（顾名思义）都是集群自动扩缩引擎：它们分析 Kubernetes 集群上运行的工作负载，并根据一组预定义的规则和条件确定集群是否需要更多或更少的计算资源。KCA 首先开发，支持各种不同的集群配置和外部云提供商；Karpenter 是 AWS 最近开发的（它在今年早些时候达到了 1.0 里程碑），并且通常被集群运营商认为“更快更有效”，但它目前仅支持 AWS 和 Microsoft Azure。我想使用 SimKube 来检验这一说法。
为了设置我的仿真，我首先需要一些真实数据来仿真。对于此实验，我使用了 DSB (DeathStarBench)，它是各种不同的分布式系统研究中常用的一种流行的基于微服务的应用程序集合。2 我配置了“社交网络”应用程序 DSB 在 Kubernetes 集群上运行，并对该应用程序施加了一些负载，以便各种 Pod 可以向上和向下扩展。运行此应用程序的“生产”集群是在 AWS c6i.8xlarge EC2 实例上运行的单节点 Kubernetes 集群，未配置自动扩缩。图 1 和图 2 显示了实验期间（约 20 分钟）正在运行和待处理（即，未调度）的 Pod 的数量。图 1 是一个图表，显示了单节点 Kubernetes 集群上 DSB 社交网络应用程序的正在运行的 Pod 计数。
这些图表显示了缺少自动扩缩的影响：在节点上调度 32 个 Pod 后，它已满，并且所有未来的 Pod 都不可调度并标记为待处理。如果这是一个真实的应用程序，这可能会导致完全的站点中断，因为正在运行的 Pod 可能会被流量淹没，并且没有空间来扩展新的 Pod。图 2 是一个图表，显示了单节点 Kubernetes 集群上 DSB 社交网络应用程序的待处理 Pod 计数。
接下来，为了仿真 KCA 和 Karpenter 的性能，我运行了 10 次从集群收集的追踪迭代，以查看这些自动扩缩引擎中的每一个的性能如何。这些仿真也在 AWS c6i.8xlarge EC2 实例上运行——不是因为仿真本身需要那么多资源（仿真很容易在我的笔记本电脑上运行），而是因为我正在从 Prometheus 收集一秒粒度的仿真数据，并将其保存到 Amazon S3 上的 Parquet 文件中，这需要大量主机内存。（请注意，这提出了围绕分布式系统（尤其是仿真）的另一个重要问题：获得整个系统“准确”表示所需的指标数量是天文数字。）
以下是结果。图 3 中的图表显示了 DSB 社交网络追踪的 10 次模拟重放的正在运行和待处理的 Pod 计数，自动扩缩由 Kubernetes 集群自动扩缩器提供。图 4 中的图表显示了 DSB 社交网络追踪的 10 次模拟重放的正在运行和待处理的 Pod 计数，自动扩缩由 Karpenter 提供。
从这些图表中可以看出，所有 Pod 现在都已正确调度。这表明（如果这是一个真实的生产系统）拥有集群级自动扩缩器将防止事件发生。接下来，让我们看看每个自动扩缩器启动的节点。表 1 显示了在 10 次仿真过程中的每次仿真中，集群自动扩缩器启动的每种类型的最大实例数。表 2 显示了在 10 次仿真过程中的每次仿真中，Karpenter 启动的每种类型的最大实例数。
这些表格突出了 KCA 和 Karpenter 之间的一个显著差异：开箱即用，KCA 使用随机节点选择算法，该算法不考虑成本或节点对工作负载的适用性。可以配置 KCA 来考虑此信息，但这需要集群运营商付出更多努力。另一方面，Karpenter 尝试更智能地进行实例选择，因此在此实验中它的行为更可预测。
然而，此实验的规模太小，无法真正捕捉到两个自动扩缩器之间的性能特征（我们峰值时仅运行约 60 个 Pod），因此对于最后一组仿真，我将仿真规模扩大了 100 倍，以查看 KCA 和 Karpenter 在显著负载下的行为。
在此轴上比较性能很棘手，因为 KCA 和 Karpenter 的内部结构截然不同。简而言之，KCA 使用单个“扩缩”循环，其中它首先确定是否有任何 Pod 待处理，以及如果节点要向上扩展，它们是否可以被调度。此循环默认每分钟运行一次。另一方面，Karpenter 使用一组控制器来监视不可调度的 Pod 并对其采取适当的措施。Karpenter 有 23 个不同的控制器，但对于本次讨论的目的，有两个重要的控制器：“快速”控制器在新 Pod 出现时立即收到通知，并尽快采取行动；“慢速”控制器独立运行，尝试确定最佳调度决策并“整理碎片”集群。这种双层方法是 Karpenter 如何能够实现更好的扩缩性能的原因，如图 5 和图 6 所示。图 5 是一个直方图，显示了 Kubernetes 集群自动扩缩器在向上扩缩时的挂钟时间。图 6 是一个直方图，显示了 Karpenter 自动扩缩器在配置（向上扩缩）时的挂钟时间。
这些直方图比较了 Pod 在被调度到两个系统中的每一个系统之前处于待处理状态的时间长度。它们清楚地表明，与 KCA 大约需要 10 秒或更长时间相比，Karpenter 能够显著更快地调度 Pod，在几秒钟内处理其大部分配置周期。
但是，在您匆忙宣布“Karpenter 在各个方面都明显优于 KCA”之前，请记住这是一个高度人为的示例案例研究，旨在演示 SimKube 的功能。您不应一定根据这些结果做出任何技术决策；不过，有趣的是，即使在这样一个人为的例子中，我们也能够收集到一些关于 Kubernetes 生态系统的两个复杂子系统的行为的有用信息。
另一方面，如果您有兴趣了解自动扩缩如何提高您的 Kubernetes 集群性能，那么您应该做的是使用 SimKube 收集您的生产工作负载的追踪，并使用此数据重复这些实验，以便您可以就最适合您的环境做出明智的决定。
总结
本文的目标是为如何使用仿真来改进您管理的分布式系统提供一些想法，或者至少让您相信仿真分布式系统并非不可能，并且可以提供有用的见解。这些实验的原始数据可在 ACRL（应用计算研究实验室）公共数据存储库中找到，更详细的结果撰写在 应用计算研究实验室博客 上。图 7 显示了一个（假设的）图表，该图表可以通过仿真生成，以分析在给定副本计数（又名，正在运行的 Pod 数量）和资源请求（又名，CPU、内存）的各种参数值的情况下运行应用程序的成本。
在这个领域还有大量未来的工作要做：如果我们能够构建合适的工具，我们可以开始在各种不同的设置中使用仿真来回答关于分布式系统的成本、可靠性和易用性的问题。我希望看到一种工具，给定一小组参数和这些参数的可接受值范围，使用数十个或数百个仿真探索整个空间，并且能够生成一种帕累托有效曲线，工程师可以使用该曲线来就其基础设施做出决策（见图 7）。
仿真在 AI 系统的出现中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练 AI 代理在我们的基础设施中运行，而仿真绝对提供了这种能力。
最后，需要更好的工具来理解和分析这些仿真的结果。基础设施领域有很多监控工具，但相对而言数据分析工具很少。这使得工程师更难对其管理的系统做出明智的决策。
参考文献
1. Demers, S., Gopalakrishnan, P., Kant, L. 2007. 软件在环的通用解决方案。在IEEE 军事通信会议, 1–6; https://ieeexplore.ieee.org/document/4455268.
2. Gan, Y., Zhang, Y., Cheng, D., Shetty, A., Rathi, P., Katarki, N., Bruno, A., et al. 2019. 微服务及其对云和边缘系统的软硬件影响的开源基准套件。在第 24 届编程语言和操作系统架构支持国际会议论文集, 3–18; https://dl.acm.org/doi/10.1145/3297858.3304013.
3. Straesser, M., Haas, P., Frank, S., Hakamian, A., van Hoorn, A., Kounev, S. 2024. Kubernetes-in-the-Loop：通过真实的容器编排丰富微服务仿真。在性能评估方法和工具, ed., E. Kalyvianaki 和 M. Paolieri, 82–98. Cham: Springer Nature Switzerland; https://link.springer.com/chapter/10.1007/978-3-031-48885-6_6.
4. Sulistio, A., Yeo, C. S., Buyya, R. 2004. 基于计算机仿真的分类法及其到并行和分布式系统仿真工具的映射。软件：实践与经验 34(7). 653–73; https://dl.acm.org/doi/abs/10.1002/spe.585.
5. Wen, S., Han, R., Qiu, K., Ma, X., Li, Z., Deng, H., Liu, C. H. 2023. K8sSim：Kubernetes 调度器的仿真工具及其在调度算法优化中的应用。微型机械 14(3), 651; https://www.mdpi.com/2072-666X/14/3/651.
David R. Morrison 是应用计算研究实验室的创始人，应用计算研究实验室是一个专注于分布式系统、调度和优化的私营独立研究机构。他于 2014 年在伊利诺伊大学厄巴纳-香槟分校获得博士学位，拥有十多年的行业经验（在 Airbnb 和 Yelp 等公司），并在学术研究方面拥有深厚的背景。在业余时间，他拼搭乐高积木、玩棋盘游戏和创作小说。在 Mastodon 上与他联系，地址为 @[email protected]。
版权 © 2024 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue 第 22 卷，第 6 期—
在 数字图书馆 中评论本文
更多相关文章
Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠且安全的软件需要一系列方法来推断系统的正确性。除了行业标准的测试方法（如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言，为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，并且由于在这些领域已看到的良好回报而加速发展。
Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经达到了分布式计算无处不在的地步。内存应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，这只能通过将系统部署为多个冗余组件的集合来满足；高持久性要求只能通过数据复制来满足，有时跨越广阔的地理距离。
Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 从企业到云端：谷歌的虚拟桌面
超过四分之一的 Googler 使用内部、数据中心托管的虚拟桌面。这种本地部署的产品位于企业网络中，允许用户从世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显着的特性中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在企业数据中心之间移动以跟随出差的 Googler。直到最近，我们的虚拟桌面都托管在使用名为 Ganeti 的自研开源虚拟集群管理系统的 Google 企业网络上的商用硬件上。今天，这项重要且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。
Pat Helland - 超越分布式事务的生存
本文探讨并命名了在拒绝分布式事务的世界中，用于实现大规模关键任务应用程序的一些实用方法。主题包括管理细粒度的应用程序数据，这些数据可能会随着应用程序的增长而随时间重新分区。设计模式支持在这些可重新分区的数据片段之间发送消息。
© 保留所有权利。