PDF现在并不存在
分布式系统中同时性的问题
Justin Sheehy
“现在。”
我写下这个词到你读到它之间，至少过去了几个星期。这种延迟在书面媒体中是我们理所当然，甚至不会考虑的。
“现在。”
如果我们身处同一房间，而我大声说出来，你可能会有更强的即时感。你可能会直觉地感觉到你听到这个词的时间与我说出它的时间完全相同。这种直觉是错误的。如果，你不信任你的直觉，而是思考声音的物理特性，你就会知道在我说和你听到之间一定有时间流逝。空气的运动，携带着我的话语，需要时间从我的嘴到达你的耳朵。
“现在。”
即使我举起一块写着这个词的牌子，我们都看着它，我们对这个图像的感知也不会在同一时刻发生，因为携带关于牌子的信息的光到达我们每个人的时间量是不同的。
虽然计算机的某些方面是“虚拟的”，但它们仍然必须在物理世界中运行，并且不能忽视这个世界的挑战。格蕾丝·霍珀海军准将（我们领域最重要 pioneers 之一，其成就包括创建了第一个编译器）过去常常通过给她的每个学生一根 11.8 英寸长的电线来解释这一点，这是电在一纳秒内可以传播的最大距离。这种信息、时间和距离之间关系的物理表示，是解释为什么信号（就像我上面的隐喻牌子）总是不可避免地需要时间才能到达目的地的一种工具。鉴于这些延迟，很难推断“现在”在计算机系统中究竟意味着什么。
尽管如此，如果我们提前仔细计划，从理论上讲，没有什么可以阻止我们对“现在”的共同概念达成一致。（相对论在这里不是问题，尽管它是一个诱人的干扰。目前人类的所有计算系统都共享足够接近的参考系，使得时间感知中的相对论差异变得无关紧要）。NTP（网络时间协议）14，用于同步互联网上系统之间的时钟，部分通过计算消息在主机之间传输所需的时间来工作。一旦知道了传输时间，主机就可以在调整其时钟以匹配更权威的来源时考虑进去。通过在该网络中提供一些非常精确的来源（基于原子辐射连续测量的时钟），我们能够使用 NTP 将计算机的时钟同步到很小的误差范围内。构成全球 GPS 的每个卫星都包含多个原子钟（因此单个时钟故障不会使卫星变得毫无价值），并且 GPS 协议允许任何拥有接收器的人——只要他们可以看到足够的卫星来求解所有变量——不仅可以确定接收器自身的位置，还可以以极高的精度确定时间。
我们已经理解这些协议几十年了，因此很容易相信我们已经克服了这类问题，并且我们应该能够构建假设我们的时钟是同步的系统。原子钟、NTP 和 GPS 卫星提供了知识和设备，可以解释信息传输所需的时间。因此，任何地方的系统都应该能够就“现在”达成一致，并共享对时间进度的共同、单一的看法。然后，网络和计算中的整个类别的难题将变得容易得多。如果所有你关心的系统都对时间有完全相同的感知，那么即使其中一些主机发生故障，许多这些问题也变得容易处理。然而，这些问题仍然存在，并且处理它们不仅是一个持续活跃的研究领域，也是构建实用分布式系统时的主要关注点。
你可能会看到理解时间的成熟机制，并认为研究人员和系统构建者正在做大量不必要的工作。当我们知道如何同步时，为什么还要尝试解决假设时钟可能不同的问题？为什么不直接使用正确的时间源和协议组合来使时钟一致，并继续解决那些问题呢？有一件事使这变得难以置信，并使这些问题不仅重要，而且必须正面面对：一切都会崩溃。
真正的问题不是信息从一个地方传输到另一个地方需要时间的理论概念。真正的问题是，在计算系统所在的物理世界中，组件经常会发生故障。构建系统时最常见的错误之一——尤其是，但不仅限于，商品机器和网络上的分布式计算系统——是假设可以逃脱基本的物理现实。光速就是这样一种现实，但更具危害性且同样普遍的一种现实是：我们无法制造永不损坏的完美机器。正是这些现实的结合，即异步和部分故障，共同使构建分布式系统成为一项艰巨的任务。如果我们不计划和考虑单个组件中的故障，我们几乎可以保证组合系统的故障。
分布式系统理论中最重要的结果之一是不可能性结果，它展示了在事物可能发生故障的世界中构建系统能力的局限性之一。这通常被称为 FLP 结果，以其作者 Fischer、Lynch 和 Paterson 的名字命名。8 他们的工作获得了 2001 年 Dijkstra 分布式计算领域最具影响力的论文奖，明确地表明，在“同步”模型中可以实现的某些计算问题（其中主机具有相同或共享的时钟）在较弱的异步系统模型下是不可能的。诸如此类的不可能性结果非常重要，因为它们可以引导你避免在设计自己的系统时走入死胡同。它们还可以提供蛇油探测器，因此你可以对任何声称产品可以做到你明知不可能的事情的人感到怀疑是合理的。
一个相关的结果，比 FLP 更为当今的开发人员所熟知，是 CAP 定理（代表一致性、可用性和分区容错性）。这最初由 Eric Brewer5 非正式地提出，后来由 Seth Gilbert 和 Nancy Lynch9 证明了其正式版本。从分布式系统理论的角度来看，CAP 定理不如 FLP 有趣：一个“击败”CAP 正式版本的反例假设了一个比 FLP 更弱和更具对抗性的世界模型，并要求在该模型中实现更多目标。虽然一个不完全是另一个的子问题，但 FLP 是一个更强大、更有趣，或许也更令人惊讶的结果。已经熟悉 FLP 的研究人员可能会觉得 CAP 想法有点无聊。
然而，可以合理地认为，CAP 的价值可能在于更容易被那些不熟悉分布式系统文献的人所理解和掌握。这将是值得称赞和有价值的，但过去几年表明（通过数十篇文章和博客文章，其中许多文章严重误解了基本思想），CAP 的想法可悲地并没有成为当今开发人员理解在分布式和不完美世界中编程的现实的简便方法。无论从 CAP 还是 FLP 或任何其他角度来看，这种现实都是一个你必须假设你用作构建块的组件是不完美的世界。（任何理论上的“不可能性结果”，例如 CAP 或 FLP，都与它的系统模型内在相关。这是结果所依赖的世界的理论模型。任何此类结果实际上并没有说某些目标——例如共识——通常是不可能的，而是说它在该特定模型中是不可能的。这对于从业者在开发关于哪些路径可能是死胡同的直觉时非常有用，但如果你只学习结果而不学习结果适用的上下文，它也可能具有误导性。）
真正的问题是事物会崩溃。此处引用的文献，例如 FLP，都与处理预期组件会发生故障的系统有关。如果这就是问题所在，那么为什么我们不使用不会崩溃的东西，然后用我们可以假设是健壮的组件构建更好的系统呢？
在过去几年中，谷歌的 Spanner 系统经常被引用作为证明这种假设合理性的依据。6 该系统完全使用了前面提到的技术（NTP、GPS 和原子钟）来协助协调构成 Spanner 的主机的时钟，并最大限度地减少和测量（但不是消除）关于这些时钟之间差异的不确定性。Spanner 论文及其记录的系统经常被用来支持关于拥有具有单一时间视图的分布式系统是可能的说法。
尽管指向谷歌并使用这种权威论证很有吸引力，但每个提出这种说法的人都是错误的。事实上，任何引用 Spanner 作为同步“已解决”证据的人要么是在撒谎，要么根本没有真正阅读过这篇论文。反对该说法的最简单和最明确的证据是 Spanner 论文本身。Spanner 的 TrueTime 组件没有提供一个简单和统一的共享时间线。相反，它非常清楚地提供了一个 API，该 API 直接公开了关于系统时钟之间感知时间差异的不确定性。如果你向它询问当前时间，它不会给你一个单一的值，而是给你一对值，描述围绕“现在”的可能性范围——也就是说，TrueTime 所做的事情与解决这个根本问题相反。它做出了勇敢而引人入胜的选择，即直接面对它并明确说明不确定性，而不是假装在工作分布式系统中“现在”的单一绝对值是有意义的。
在 Spanner 的生产环境中，任何时刻的时钟漂移通常在 1 到 7 毫秒之间。这是谷歌在包括 GPS、原子钟、驱逐最严重漂移的时钟以及更多措施以最大限度地减少偏差之后所能做到的最好程度。典型的 x86 时钟会根据各种不可预测的环境因素（例如负载、热量和功率）改变其速度。即使是同一机架顶部和底部之间的差异也可能导致偏差差异。如果像谷歌这样花费巨大的环境中，最好的情况是忍受几毫秒的不确定性，那么我们大多数人都应该假设我们的时钟偏差远不止于此。
在证明分布式系统设计中“就当没问题”方法合理性的另一个常见说法是，足够高质量的设备不会发生故障，或者至少故障非常罕见，以至于你不需要担心它。这种说法如果来自此类设备的制造商，那是可以理解的，尽管是不正确的，但通常是此类设备的用户，例如分布式数据库软件的设计者，被听到发出此类说法。（Spanner 和其他人所依赖的 GPS 的设计者当然不同意这种说法。有近 30 颗 GPS 卫星，你只需要看到其中四颗就可以使系统工作。这些卫星中的每一颗都有多个冗余原子钟，因此当其中一个原子钟发生故障时，它可以继续工作。）
这种说法最常见的变体之一是“网络是可靠的”，在本地数据中心网络的背景下。当网络行为不佳时，许多系统具有未定义且很可能灾难性的行为。想要向你出售这些系统的人通过解释说这种故障极其罕见来证明他们选择忽视现实是合理的。通过这样做，他们对他们的客户造成了双重损害。首先，即使此类事件很少发生，你难道不想了解你的系统在它们确实发生时会如何表现，以便为这些事件对你的业务产生的影响做好准备吗？其次，更糟糕的是，这种说法简直是谎言——事实上，这是一个如此明目张胆的谎言，以至于它是分布式计算的经典八谬论中的第一个。7,15此类故障的现实在之前的一篇 Queue 文章3 中有充分的记录，并且证据非常清楚和现实，以至于任何通过声称“网络是可靠的”而不带讽刺意味地为软件设计选择辩护的人，可能都不应该被信任来构建任何计算系统。虽然有些系统和网络可能没有以给定的观察者可以注意到的方式发生故障，但将系统的安全性建立在假设它永远不会发生故障的基础上是愚蠢的。
与这种对物理问题的挥手告别相反的方法是假设几乎没有什么可以依靠，并且仅使用非常对抗性世界的形式模型进行设计。FLP 被证明的“异步”模型不是构建工作系统最具对抗性的模型，但它肯定比大多数开发人员认为他们的系统运行在其中的世界更具敌意。这种思路是，如果你在其中建模的世界比你运行的世界更糟糕，那么你在模型中可以成功的事情应该在实际的实现世界中是可能的。（注意，分布式系统理论家有一些更难成功的模型，例如那些包括“拜占庭”故障可能性的模型，其中系统的某些部分可能以比仅仅崩溃或延迟更糟糕的方式发生故障。对于一个真正具有对抗性的网络/系统模型，你可以看到，例如，密码协议理论家使用的符号或计算模型。在那个世界中，系统构建者真的假设你自己的网络会伤害你。）
正是在这种背景下，假设一个比我们认为我们实际运行的世界稍微糟糕的世界，设计了最著名的共识和协调协议，例如 Paxos12。对于分布式系统的这些基本构建块，知道即使在与设计者作对的世界中，它们也可以提供最重要的保证，例如任意丢失消息、崩溃主机等等，这很有用。（例如，对于 Paxos 和相关协议，最强调的属性是“安全性”——保证不同的参与主机永远不会做出冲突的决策。）另一个这样的工作领域是逻辑时间，表现为向量时钟、版本向量以及其他抽象事件排序的方式。这个想法通常承认无法假设同步时钟，并为时钟完全不可靠的世界构建排序概念。
当然，你应该始终努力使一切（包括网络）尽可能可靠。将这种持续的目标与可实现完美终态相混淆是愚蠢的。同样愚蠢的是纯粹主义的观点，即只有最完善和完全理解的理论模型才是构建系统的明智起点。许多最有效的分布式系统都建立在有价值的要素之上，这些要素与分布式计算的最常见模型并不完全匹配。一个典型的此类构建块是 TCP。这种几乎无处不在的协议提供了一些非常有用的属性，这些属性的确切集合与开发诸如 FLP 之类的理论结果中使用的任何典型网络模型都不完全匹配。这给系统构建者造成了一个难题：在设计时不假设类似 TCP 的东西是愚蠢的，但在某些情况下，如果他们试图理解分布式系统理论如何应用于他们的工作，这会使他们处于不稳定的境地。
Zab 协议是流行的 Apache ZooKeeper 协调软件最基本的部分，是尝试走这条中间道路的一个引人入胜的例子。10 ZooKeeper 的作者了解现有的共识协议（例如 Paxos），但他们决定想要自己的协议，该协议具有一些附加功能，例如能够一次处理许多请求，而不是等待每个提议完成再开始下一个提议。他们意识到，如果他们基于 TCP 构建，他们就拥有了底层系统的优势，该系统提供了一些有价值的属性，他们可以在协议中假设这些属性。例如，在单个连接的 TCP 套接字中，发送方生成消息 A，然后生成消息 B，可以安全地假设，如果接收方读取 B，则接收方之前已读取 A。这种“前缀”属性非常有用，并且在异步模型中不存在。这是一个具体的例子，说明了通过同时关注该领域的研究和实际可用于构建的特定技术，而不是忽略任何一个，可以获得的优势。
然而，当试图务实时，必须小心不要让这种务实主义变成其自身奇怪的纯粹性，并成为草率工作的借口。在 ZooKeeper 内部实现的 Zab 协议（事实上的参考实现）从来都不是对设计的 Zab 协议的准确实现。13 你可能会称自己为“务实主义者”，并注意到大多数其他软件也不符合正式规范；因此你可能会说这里没有什么不寻常的需要担心。你有两个理由是错误的。首先，ZooKeeper 和类似软件所扮演的角色与其他软件不同；它正是为了提供基本的安全属性，形成一个基石，系统其余部分可以在其上做出强大的假设。其次，如果像这样的协议的安全属性存在问题，这些问题的出现（虽然可能非常危险）可能是微妙且容易被忽略的。如果没有强烈地相信实现反映了分析的协议，那么用户信任系统是不合理的。声称系统的“足够好的正确性”已通过其受欢迎程度得到证明是无稽之谈，如果普通用户无法评估该正确性。
所有这一切并不是要挑剔 ZooKeeper。事实上，ZooKeeper 是其类型中最高质量的开源软件之一，许多优秀的工程师不断改进它。在最近的分析中，它在压力下的表现远胜于任何竞争对手。1 我指出 ZooKeeper 只是作为一个例子，说明了在理论和实践方面采取中间道路的必要性和陷阱。将理论映射到实践可能极具挑战性。
这种中间道路的另一个例子是混合逻辑时钟11，它将逻辑时间的通用技术与物理时钟的时间戳集成在一起。这允许用户应用一些有趣的技术，这些技术基于对整个系统中物理时钟的视图（不完善，但仍然有用）。与 Spanner 非常相似，这并没有假装创建一个单一的统一时间线，但确实允许系统设计者基于关于跨集群感知和通信时间的最佳可用知识进行构建。
所有这些不同的协调系统——包括 Paxos、Viewstamped Replication、Zab/Zookeeper 和 Raft——都提供了跨分布式系统定义事件顺序的方法，即使物理时间不能安全地用于该目的。然而，这些协议绝对可以用于该目的：提供跨系统的统一时间线。你可以将协调视为为“现在”提供逻辑替代品。然而，当以这种方式使用时，这些协议会产生成本，这是由它们所有协议从根本上共同拥有的东西造成的：持续通信。例如，如果你协调分布式系统中发生的所有事情的顺序，那么在最佳情况下，你能够提供的响应延迟不小于该系统内部的往返时间（两个顺序消息传递）。
根据你的协调系统的详细信息，吞吐量也可能存在类似的限制。对性能有积极要求的系统的设计者可能希望正确地做事，但发现持续协调的成本过高。当预计主机或网络经常发生故障时，尤其如此，因为许多协调系统仅提供“最终活性”，并且只能在最少麻烦的时候取得进展。然而，即使在那些罕见的万事俱备的情况下，持续协调的通信成本也可能太高。
在许多计算领域（包括 CPU 架构、多线程编程和 DBMS（数据库管理系统）设计）中，放弃严格协调以换取性能是一种众所周知的权衡。通常，这已变成一场游戏，旨在找出提供给用户不令人意外的行为真正需要多少协调。虽然一些并发但本地系统的设计者已经开发了相当多的技巧来管理恰到好处的协调（例如，RDBMS 领域具有有趣的性能黑客的悠久历史，通常导致 ACID [原子性、一致性、隔离性、持久性] 比你可能猜到的要少得多2），但对于通用分布式系统来说，对此类技术的探索才刚刚开始。
这是一个激动人心的时刻，因为如何在分布式系统设计中进行这些权衡的主题才刚刚开始被认真研究。加州大学伯克利分校的 BOOM（Berkeley Orders of Magnitude）团队正在关注这个主题，多位研究人员正在采用不同但相关的方法来理解如何进行有纪律的权衡。4 他们在了解何时以及如何安全地决定不关心“现在”，从而不支付协调成本方面取得了新的突破。像这样的工作可能很快就会使我们更深入地了解，为了完成我们的工作，我们真正需要多少同步时间。如果分布式系统可以在减少协调的情况下构建，同时仍然提供所有需要的安全属性，那么它们可能会更快、更具弹性并且更能够扩展。
避免需要担心时间和协调的另一个重要研究领域涉及 CRDT（无冲突复制数据类型）。这些是数据结构，其更新永远不需要排序，因此可以在不尝试解决时间问题的情况下安全地使用。它们提供了一种有时称为强最终一致性的安全性：系统中所有接收到相同更新集（无论顺序如何）的主机都将具有相同的状态。长期以来人们都知道，如果你所做的所有工作都具有某些属性（例如可交换、可结合和幂等），就可以实现这一点。CRDT 令人兴奋的原因在于，该领域的研究人员16 正在扩展我们对在这种限制下我们可以表达多少内容以及我们可以在提供丰富的、可供开发人员开箱即用的数据类型的同时，以多低的成本完成此类工作的理解。
判断这些主题的开发才刚刚开始的一种方法是，流行的分布式系统更喜欢临时黑客，而不是处理其一致性、协调或共识问题的最著名选择。这方面的一个例子是任何具有“后写获胜”策略来解决冲突写入的分布式数据库。由于我们已经知道“后写”本身就是一个毫无意义的术语，原因与“现在”不是整个系统中的简单值相同，因此这实际上是一个“许多写入，不可预测地选择，将被丢失”策略——但这不会卖出那么多数据库，不是吗？即使最先进的技术仍在迅速改进，任何人也应该能够做得更好。
另一个例子，与“大多数写入丢失”数据库策略一样糟糕，是选择通过临时协调代码而不是使用正式建立和充分分析的共识协议来解决集群管理问题。如果你真的需要一些不同于众所周知的共识协议来解决它们解决的相同问题（提示：你不需要），那么至少你应该像 ZooKeeper/Zab 实现者那样做，并清楚地记录你的目标和假设。这不会使你免于灾难，但至少会帮助后来的考古学家检查你的遗骸。
对于分布式系统的构建者来说，这是一个非常激动人心的时刻。许多变化仍在发生。然而，有些真理很可能仍然存在。“现在”作为一个简单的值，在一段距离内具有意义的想法将永远存在问题。我们将继续需要更多的研究和更多的实践经验来改进我们应对这种现实的工具。我们可以做得更好。我们可以现在就做到。
致谢
我要感谢提供反馈的人，包括 Peter Bailis、Christopher Meiklejohn、Steve Vinoski、Kyle Kingsbury 和 Terry Coatta。
参考文献
1. Aphyr. 2013. Call me maybe: ZooKeeper; http://aphyr.com/posts/291-call-me-maybe-zookeeper.
2. Bailis, P. 2013. When is "ACID" ACID? Rarely; http://www.bailis.org/blog/when-is-acid-acid-rarely/.
3. Bailis, P., Kingsbury, K. 2014. The network is reliable. Queue 12(7); https://queue.org.cn/detail.cfm?id=2655736.
4. BOOM; http://boom.cs.berkeley.edu/papers.html.
5. Brewer, E. A. 2000. Towards robust distributed systems; http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf.
6. Corbett, J. C., et al. 2012. Spanner: Google's globally distributed database. Published in Proceedings of the 10th Symposium on Operating System Design and Implementation; http://research.google.com/archive/spanner.html; http://static.googleusercontent.com/media/research.google.com/en/us/archive/spanner-osdi2012.pdf.
7. Deutsch, P. The eight fallacies of distributed computing; https://blogs.oracle.com/jag/resource/Fallacies.html.
8. Fischer, M. J., Lynch, N. A., Paterson, M. S. 1985. Impossibility of distributed consensus with one faulty process. Journal of the 32(2): 374-382; http://macs.citadel.edu/rudolphg/csci604/ImpossibilityofConsensus.pdf.
9. Gilbert, S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. SIGACT News 33 (2): 51-59; http://webpages.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf.
10. Junqueira, F. P., Reed, B. C., Serafini, M. 2011. Zab: high-performance broadcast for primary backup systems; http://web.stanford.edu/class/cs347/reading/zab.pdf.
11. Kulkarni, S., Demirbas, M., Madeppa, D., Bharadwaj, A., Leone, M. 2014. Logical physical clocks and consistent snapshots in globally distributed databases; http://www.cse.buffalo.edu/tech-reports/2014-04.pdf.
12. Lamport, L. 1998. The part-time parliament. Transactions on Computer Systems 16(2): 133-169; http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#lamport-paxos.
13. Medeiros, A. 2012. ZooKeeper's atomic broadcast protocol: theory and practice; http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf.
14. NTP; http://www.ntp.org.
15. Rotem-Gal-Oz, A. Fallacies of distributed computing explained; http://www.rgoarchitects.com/Files/fallacies.pdf.
16. SyncFree; https://syncfree.lip6.fr/index.php/publications.
喜欢它，讨厌它？请告诉我们
Justin Sheehy 是 VMware 剑桥 MA 研发中心的主管，并且在公司存储与可用性业务中也扮演着战略架构师的角色。在加入 VMware 之前，他的三个最新职位分别是 Basho 的 CTO、MITRE 的首席科学家以及 Akamai 的高级架构师。他的大部分职业生涯都专注于弹性分布式系统，包括如何构建它们以及如何应用它们来解决与可扩展性和可用性相关的业务问题。可以在 Twitter 上找到 Justin，账号是 @justinsheehy。
© 2015 1542-7730/14/0200 $10.00
最初发表于 Queue 第 13 卷，第 3 期—
在 数字图书馆 中评论本文
更多相关文章
Marc Brooker, Ankush Desai - AWS 系统正确性实践
构建可靠和安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法（例如单元测试和集成测试）之外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言，为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域已经看到的投资回报加速了这一进程。
Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经到了分布式计算无处不在的地步。内存中应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群上；在线服务具有高可用性要求，这只能通过将系统部署为多个冗余组件的集合来满足；高持久性要求只能通过数据复制来满足，有时跨越广阔的地理距离。
David R. Morrison - 模拟：分布式系统中未充分利用的工具
模拟在人工智能系统的出现中扮演着巨大的角色：我们需要一种高效、快速且经济高效的方式来训练人工智能代理在我们的基础设施中运行，而模拟绝对提供了这种能力。
Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 公司到云端：Google 的虚拟桌面
超过四分之一的 Googler 使用内部、数据中心托管的虚拟桌面。这种本地产品位于公司网络中，允许用户在世界任何地方远程开发代码、访问内部资源和使用 GUI 工具。在其最显著的特性中，虚拟桌面实例可以根据手头的任务调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Googler。直到最近，我们的虚拟桌面都托管在使用名为 Ganeti 的自研开源虚拟集群管理系统的 Google 公司网络上的商用硬件上。今天，这项重要且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。
© 保留所有权利。