PDF面向互联网规模服务的集群调度器设计
拥抱失败以提高可用性
Diptanu Gon Choudhury 和 Timothy Perrett
在过去的十年中，集群调度器已成为互联网规模服务的基础，这些服务跨越数百或数千台机器，遍布许多地理上分布的数据中心。集群调度器起源于高性能计算或管理在仓库规模计算系统上运行的服务，这些系统可以有效利用计算资源。调度器还为应用程序开发人员提供 API，用于编写分布式应用程序（如 Spark 和 MapReduce）或构建应用程序管理平台（如 DC/OS（数据中心操作系统））。在过去的几年里，Kubernetes、HashiCorp 的 Nomad 和 Apache Mesos 等开源调度器普及了规模化，使许多企业能够采用以前只有 Facebook、Google 和 Twitter 等公司才能使用的调度器技术。
尽管这种普遍性显而易见，但操作和实施调度软件是一项极其棘手的任务，其中包含许多细致入微的边缘情况。本文根据作者为大型互联网公司设计、构建和运营各种调度器的真实经验，重点介绍了其中一些情况。
失败是不可避免的
从长远来看，一切都会失败。每天，世界已经开始依赖的许多互联网服务都会发生许多小的——甚至难以察觉的——失败。机器崩溃、API 变得间歇性延迟、硬盘驱动器故障以及网络饱和，但通常由它们驱动的服务不会未能响应用户请求。虽然从这些故障中自动恢复似乎是一个已解决的问题，但现实情况是，许多不同的流程都参与了协调这种恢复。调度软件通常是允许服务通过与各种其他数据中心服务交互来恢复的基础设施。
现代分布式系统（如搜索、社交网络和云对象存储）消耗的资源远多于少量服务器甚至大型机所能提供的资源。这些系统消耗的资源数量级为数万台机器，可能分布在许多数据中心。这通常意味着不可能将数据中心视为服务器的集合，并且单个服务器的概念变得不太相关。
软件开发人员只关心可用资源，如 RAM、CPU 和用于访问网络系统的可用带宽。在某种程度上，调度器允许操作员忽略计算资源的分布。在这些范围内，当在调度器上运行的工作负载失败时，调度器可以简单地在可用池中查找资源，并重新调度该作业以在用户施加的约束条件下进行处理。正是在这个失败的时刻，事情变得有趣起来。工作负载为什么会失败？是应用程序问题？还是机器特定问题？或者可能是集群范围或其他的环境问题？更重要的是，调度器的架构如何影响工作负载恢复的能力和时间线？这些问题的答案直接影响和决定了调度器在恢复失败工作负载方面的有效性。
集群调度器的职责之一是监控单个工作单元，最原始的补救形式是将该工作负载移动到不同的、健康的节点；这样做通常可以解决给定的故障场景。然而，当使用任何类型的共享基础设施时，您必须仔细评估应用于该共享基础设施的隔离选项，并客观地评估级联故障的机会。例如，如果将 I/O 密集型作业重新定位到已经托管另一个 I/O 密集型作业的节点，则在没有任何 IOPs（I/O 操作）隔离的情况下，它们可能会使网络链路饱和，从而导致节点上其他租户的 QoS（服务质量）下降。
以下章节重点介绍了调度系统中的各种故障域，并涉及操作员在机器、调度器、环境和集群范围的故障中遇到的一些实际问题。此外，本文还提供了一些应对故障的答案。
机器故障的考虑因素
机器级别的故障可能是最常见的。它们有多种原因：硬件故障，如磁盘崩溃；网络接口故障；软件故障，如过度日志记录和监控；以及容器化守护程序的问题。所有这些故障都会导致应用程序性能下降或潜在的不一致的集群状态。虽然所有可能的系统故障模式都太多，无法在一篇文章中提及，但在调度领域，有少数重要的因素需要考虑；以下章节详细介绍了现代 Linux 操作系统的工作原理，以及如何减轻现场遇到的典型故障模式的影响。
容量规划
无论计算容量位于何处——公有云还是私有数据中心——在某些时候都需要进行容量规划，以确定需要多少台机器。传统的容量规划方法8假设计算资源完全专用，其中给定的机器只有一个租户。虽然这是一种常见的行业实践，但它通常是无效的，因为应用程序作者往往对他们的运行时性能过于乐观（导致容量不足和潜在的运行时中断）或对资源消耗过于谨慎，从而导致大规模运营时所有权成本高且浪费量大5。
假设应用程序已经过性能和资源消耗的基准测试，在调度系统上运行该应用程序会为容量规划带来额外的挑战：共享组件将如何处理多租户？常见的配置具有用于路由流量、监控和日志记录（以及其他任务）的每节点实用程序；这些是否会潜在地影响实验室性能数据？它们很可能会产生（负面）影响。
确保容量计划包括操作系统、文件系统、日志记录代理以及将作为共享组件运行的任何其他组件的余量。至关重要的是，任何作为共享组件的东西都应该对计算资源有明确定义的限制（如果可能）。不为系统服务配置足够的资源会无意中表现为繁忙邻居问题。许多调度器允许操作员为运行系统组件保留资源，正确配置这些资源预留可以显着提高应用程序性能的可预测性。
• 文件系统。 了解文件系统的开销和资源使用情况。例如，当使用 ZFS 将 ARC（自适应替换缓存）限制为可接受的大小，或者当计划打开重复数据删除或压缩以考虑 ZFS 本身将要使用的 CPU 周期时，这非常有用。考虑另一个例子：两个容器进行大量文件系统 I/O，但缓存非常有限，最终会导致彼此的缓存失效，从而导致 I/O 性能不佳。在 Linux 中限制文件系统 IOPs 并不简单，因为块 I/O 和内存控制器无法相互交互，以使用传统的 cgroup v1 限制回写 I/O。下一版本的 cgroup 可以 正确限制 I/O，但一些控制器——例如 CPU 控制器——尚未合并。
• Sidecars。 日志记录、监控或服务网格（如 Envoy2）可能会消耗大量资源，这需要考虑在内。例如，如果日志记录代理（如 Fluentd3）正在将日志转发到远程接收器，则应限制该进程的网络带宽，以便容器可以获得其预期的应用程序流量网络资源份额。公平共享此类资源很困难，因此有时更容易为节点上的每个分配运行 Sidecars，而不是共享它们，以便可以在分配的 cgroup 层次结构下计算其资源。
• 管理。系统或组件配置策略（如垃圾回收）应基于底层资源理解的单位。例如，基于天数的日志保留策略在存储空间受字节数限制的节点上无效——如果可用字节在数小时内耗尽，则每三天轮换日志是没有用的。系统管理员通常应用与他们为集群范围的日志聚合服务编写的策略相同类型的策略用于本地节点。这可能会在集群级别产生灾难性后果，因为服务旨在水平扩展，其中工作负载可能分布在许多具有相同或相似硬件配置的节点上。
这些是出于容量规划目的需要考虑的一些关键要素，但这绝不是一个详尽的集合。请务必考虑可能适用于您情况的任何特定于环境的容量限制，始终将您的计划建立在现场收集的有关实际使用情况的真实数据之上。
OOM Killer
Linux 中的 OOM（内存不足）killer 在内存极低的情况下介入，并根据一组规则和启发式方法杀死进程以回收内存。OOM killer 的决策基于所谓的 oom_score，它会随着时间的推移根据某些规则而变化，并且在大多数情况下是不确定的。
OOM killer 是在设计允许超额订阅1的调度器时需要记住的重要系统组件，因为它们允许在一台机器上运行比实际资源更多的任务。在这种情况下，设计一个良好的 QoS 模块非常重要，该模块可以主动跟踪任务的资源使用情况并主动杀死它们。如果任务消耗的内存超过分配给它们的内存，则调度器应在总体资源利用率迫使系统 OOM killer 调用之前杀死任务。例如，QoS 模块可以通过监听指示内存压力的内核通知来实现他们自己的内存释放策略，并随后杀死低优先级任务，这将阻止内核调用 OOM killer。
让调度器代理杀死任务可以实现确定性行为，并且更容易调试和排除故障。例如，在 Mesos 集群管理器中，Mesos 代理运行一个 QoS 控制器，该控制器持续监控使用可撤销资源运行的任务，并在它们干扰正常任务时杀死它们。
容器资源泄漏
自从十年前引入 Linux 内核以来，容器技术已经得到了极大的改进。然而，世界仍然是不完美的，并且建立在这些基础之上的工具随着时间的推移增加了更多的复杂性，为有趣且难以解决的问题打开了大门。操作员将遇到的常见运行时问题之一是相关资源的泄漏。例如，假设您以桥接网络模式启动一个容器；在后台将创建一个虚拟以太网适配器。如果应用程序意外崩溃——并且未被外部代理杀死——容器守护程序可能会随着时间的推移泄漏虚拟接口，当泄漏适量的接口时，最终会导致系统问题。这会导致尝试在该机器上启动的新应用程序失败，因为它们无法创建虚拟网络适配器。
修复这些类型的故障可能很困难；必须首先监控该问题，以跟踪随时间创建和垃圾回收的资源，确保泄漏保持在最低限度或得到有效缓解。操作员经常发现自己编写代理来禁用节点上的调度，直到资源可用，以确保节点不在压力下运行，或者在问题通过导致中断来显现自身之前抢先重新分配工作。即使自动缓解程序到位，最好还是将此类问题告知操作员，因为这些问题通常是底层容器运行时中的错误造成的。
附加资源订阅不足
调度器通常基于节点资源（如 CPU、内存、磁盘和 I/O 子系统的容量）为任务选择放置或装箱策略。然而，重要的是要考虑附加到节点的共享资源，如网络存储、附加到 ToR（架顶式）交换机的聚合链路层带宽等，以确保此类资源分配到合理的限制或被明智地超额订阅。幼稚的调度器策略可能会低估节点本地资源使用率，但高估聚合资源（如带宽）。在这种情况下，优化集群级效率比本地优化策略（如装箱）更好。
多租户
多租户是性能工程师在弹性共享基础设施中解决的最困难的挑战之一。由许多具有不同资源使用模式的不同服务共享的集群通常会显示所谓的繁忙邻居问题。服务的性能可能会因其他同租户服务的存在而降低。例如，在 Linux 操作系统上，对网络施加 QoS 可能很复杂，因此操作员有时不会费力地实施流量整形机制来控制容器中网络 I/O 的吞吐量和带宽。如果两个网络 I/O 密集型应用程序在同一节点上运行，它们将对彼此的性能产生不利影响。
多租户的其他常见问题包括 cgroup 控制器未正确计算某些资源，例如 VFS IOP，其中磁盘 I/O 非常密集的服务的性能在与类似服务位于同一位置时会降低。在过去五到六年里，人们一直在努力在 Linux 上设计新的 cgroup 控制器9，以进行更好的计算，但并非所有这些控制器都已投入生产。当工作负载使用 SIMD（单指令多数据）指令（如 Intel 的 AVX-512 指令集中的指令）时，处理器会限制 CPU 时钟速度以降低功耗，从而减慢在同一 CPU 内核上运行的非 SIMD 指令的其他工作负载的速度。6
公平共享资源通常是调度器提供的最常见的方法，资源的份额通常通过标量值表示。从最终用户的角度来看，标量值更容易理解，但在实践中，由于干扰，它们并不总是效果良好。7 例如，如果为在同一机器上运行的两个工作负载分配 100 个 IOPs 单位，则进行顺序 I/O 的工作负载可能比执行随机 I/O 的工作负载获得更多的吞吐量。
集群级故障的考虑因素
大多数在半夜惊醒操作员的故障都影响了整个集群或机群中的服务器机架。集群级故障通常是由错误的配置更改、错误的软件部署或在某些情况下是由于某些服务中的级联故障导致多租户环境中的资源争用而触发的。大多数调度器都带有针对不健康任务的补救步骤，例如重启或从节点中驱逐低优先级任务以减少资源争用。集群范围的故障表明问题远比可以用本地补救技术解决的本地节点相关问题大得多。
此类故障通常需要呼叫随叫随到的工程师进行补救操作；然而，调度器也可以在此类故障期间发挥补救作用。作者编写和部署了具有集群范围故障检测器的调度器，这些调度器将阻止节点持续在本地重启任务。它们还允许操作员定义补救策略，例如恢复到上次已知的良好版本或降低重启频率、停止驱逐其他任务等，然后操作员可以调试可能的故障原因。此类故障检测算法通常会考虑同一台机器上同租户任务的健康状况，以区分服务级故障与其他形式的基础设施相关故障。
集群范围的故障应受到调度器开发人员的重视；作者遇到过一些故障，这些故障产生了如此多的集群事件，以至于它们饱和了调度器对故障做出反应的能力。因此，必须采取复杂的措施来确保对事件进行采样，而不会丢失底层问题的性质和严重程度的上下文。根据故障的严重程度，事件的饱和通常会使操作陷入停顿，除非它得到快速缓解。本节介绍了一些最常用的缓解集群级故障的技术。
错误的软件推送
大多数集群级作业故障都是错误的软件推送或配置更改的结果。跟踪此类故障的开始时间并将它们与集群事件（如作业提交、更新和配置更改）相关联通常很有用。另一种常见但简单的技术，用于在面对错误的软件推送时降低集群范围故障的可能性，是滚动更新策略，该策略仅在新实例被证明是健康的或从关键指标的角度来看按预期工作之后，才逐步部署新版本的软件。Nomad 和 Kubernetes 等调度器都带有此类规定。它们仅在当前的任务集通过健康检查时才继续部署较新版本的软件，如果它们开始遇到故障，则停止部署。
系统软件故障
系统软件（如 Docker 守护程序以及监控和日志记录软件）是调度器基础设施不可或缺的一部分，因此有助于集群的健康状况。新版本的此类软件经常在部署后才发现它们在集群中一段时间后会导致故障。在一个实例中，AWS（亚马逊网络服务）上的特定 Auto Scaling Group 在集群加入调度器基础设施几天后开始行为异常；事实证明，已经推出了新版本的 Docker，该版本存在功能回归。
在大多数情况下，处理此类故障的最佳策略是禁用这些机器上的调度，并耗尽分配的工作，以强制将工作负载重新定位到数据中心的其他位置。或者，您可以引入额外的资源容量以及所有系统软件的工作配置，以便可以成功调度挂起的工作负载。
此类故障会影响特定集群或资源池中所有作业的任务；因此，调度器应具有良好的机制来处理它们。一个健壮的调度器设计理想情况下应该能够检测到给定集群或资源池的问题，并主动停止在那里调度工作负载。这种主动补救事件应包含在调度器发出的遥测信息中，以便随叫随到的工程师可以进一步调试和解决特定问题。
共享资源故障
基础设施级别的故障模式包括光纤中断；机器、机架或 ToR（架顶式）交换机的电源分配故障；以及许多其他环境可能性。在这种情况下，除了将受影响的工作负载移动到未受影响的系统之外，调度器几乎无法缓解问题。
在某些集群调度器中，当节点与网络断开连接时，默认行为是开始杀死任务。在操作上，当节点恢复到健康状态时，这可能会导致重大挑战。在大多数情况下，最好将保证当前正在运行的任务的固定数量的复杂性委托给应用程序本身。这通常使调度系统更易于操作，并允许应用程序精确地获得其所需的 一致性和故障语义。当故障得到缓解时，应允许任务优雅地加入集群。此类措施减少了集群中的动荡，并允许其更快地恢复。
全局资源耗尽
除了节点资源外，调度器的资源分配器还应跟踪全局资源，如集群内的聚合带宽或功耗。未能跟踪这些全局资源可能会导致放置决策过度订阅集群资源，从而导致数据中心内出现瓶颈，从而降低已配置硬件的效率。
例如，在单个机架中装箱过多的网络 I/O 密集型任务可能会使到数据中心骨干网的链路饱和，从而造成争用，即使节点级别的网络链路可能没有饱和。在数据中心的特定部分非常紧密地装箱工作负载也可能对功耗产生有趣或意想不到的副作用，从而影响可用的冷却解决方案。
软件分发机制
了解软件分发机制的瓶颈非常重要。例如，如果分发机制的总容量为 5 Gbps，则启动具有数万个任务的作业很容易使分发机制甚至共享骨干网的限制饱和。这可能会对整个集群和/或正在运行的服务产生不利影响。其他服务的并行部署通常会受到这种故障模式的影响；因此，必须限制任务启动的并行性，以确保在部署或更新任务时不会产生额外的瓶颈。
请记住，本质上是集中式的分发机制（如 Docker 注册表）是可用性方程的一部分。当这些集中式系统发生故障时，作业提交或更新请求也会失败，从而使服务面临在更新时变得不可用的风险。在本地节点上广泛缓存工件以减少集中式分发机制的压力，可以成为有效缓解集中式分发中断的策略。在某些情况下，对等分发技术（如 BitTorrent）可以进一步提高此类系统的可用性和健壮性。
补救措施的回退策略
某些工作负载可能在集群中的任何节点上都无法良好运行，并且可能会对服务和节点的健康状况产生不利影响。在这种情况下，调度器必须检测趋势，同时重新分配工作负载或带来额外的容量，以确保它们不会耗尽全局资源，例如云提供商的 API 调用限制，或对同租户工作负载产生不利影响，从而导致级联故障。
控制平面故障的考虑因素
调度器内的控制平面与计算节点和集群具有不同的故障考虑因素，因为控制平面必须对集群中发生的变化（包括各种形式的故障）做出反应。编写此类系统的软件工程师应了解用户交互、规模和工作负载的 SLA（服务级别协议），然后得出适当的设计，其中包含处理控制平面中的故障。 本节着眼于控制平面开发人员的一些重要设计考虑因素。
可靠的集群状态协调
归根结底，大多数调度器只是管理集群状态、监控在集群上运行的任务并确保它们的 QoS。调度器通常跟踪集群状态，并为其管理的所有集群对象（如集群、节点、作业和任务）维护内部有限状态机。集群状态协调的两种主要方式是级别触发和边缘触发机制。前者被 Kubernetes 等调度器采用，它定期查找未放置的工作并尝试调度该工作。这些类型的调度器通常会受到协调固定基线延迟的影响。
边缘触发调度更为常见。大多数调度器（如 Mesos 和 Nomad）都采用这种模型。当集群基础设施中发生某些变化时，例如任务失败、节点失败、节点加入等，会生成事件。调度器必须对这些事件做出反应，更新集群对象的有限状态机并相应地修改集群状态。例如，当 Mesos 中的任务失败时，框架会从 master 收到 TASK_LOST 消息，并根据某些规则对该事件做出反应，例如在集群中的其他位置重启任务或将作业标记为死亡或完成。Nomad 类似：它根据死亡的分配类型调用调度器，然后调度器决定是否需要替换该分配。
虽然事件驱动的调度器在实践中更快、响应更快，但保证正确性可能更难，因为调度器没有空间丢弃或遗漏事件的处理。丢弃集群事件将导致集群无法收敛到正确的状态；作业可能未处于预期状态或未运行正确数量的任务。调度器通常通过使代理或集群事件的来源重新发送事件直到他们收到来自消费者的确认事件已持久化来处理此类问题。
调度器的配额
调度器通常提供给组织中的各个团队，用于消耗数据中心中的计算基础设施。调度器通常实施配额，以确保各个作业在资源争用期间在集群上拥有适当数量的资源。除了计算集群上的计算资源配额外，调度器开发人员还必须考虑调度器为每个作业花费多少调度时间。例如，调度具有 15,000 个任务的批处理作业所需的时间将远远超过调度具有 10 个任务的作业的时间。或者，作业可能只有少量任务，但放置约束非常严格。调度器可能会花费不同量的时间为来自不同团队的各种作业提供服务，具体取决于约束和任务量或集群中的动荡。单体调度器（集中所有调度工作）比两级调度器（如 Mesos）更容易出现这些类型的问题，在 Mesos 中，操作员可以运行多个框架以确保各种调度器服务于单一目的，从而不共享其他任何事情的调度时间。
对于单体调度器，开发诸如各种类型作业或团队的配额等概念非常重要。扩展调度器的另一种可能性是以类似于 Nomad 的方式进行并行调度，操作员可以在其中运行许多并行工作的调度器实例，并且可以决定他们想要为某种作业类型运行多少个调度器进程。
从故障中恢复集群状态
调度器操作员实际上想要 AP（CAP 可用性、分区容错）系统，因为他们更喜欢可用性和可操作性而不是一致性。在处理完所有集群事件后或通过某种形式的协调机制，最终必须保证集群状态的收敛。然而，大多数真实世界的调度器都建立在高度一致的协调系统（如 ZooKeeper 或 etcd）之上，因为当数据存储提供线性化保证时，构建和推理此类分布式系统更容易。调度器丢失其整个数据库几个小时的情况并不少见。AWS 发生 Dynamo 中断时就发生过一次这样的情况，一个在 AWS 之上运行的大型调度器正在使用 Dynamo 来存储集群状态。在这种情况下，可以做的事情不多，但调度器开发人员必须考虑这种情况，并以对集群上运行的服务造成最小影响为目标进行开发。
某些调度器（如 Mesos）允许操作员配置一个持续时间，在此持续时间之后，与调度器断开连接的代理开始杀死机器上运行的任务。通常，这样做是假设调度器与节点的断开连接是由于网络分区等故障造成的；由于调度器认为节点已离线，因此它已在集群中的其他位置重新启动了该机器上的任务。当调度器遇到中断或以不可恢复的方式失败时，这不起作用。最好设计调度器代理，使其在代理与调度器断开连接时不杀死任务，而是允许任务运行，甚至在长时间运行的服务失败时重新启动它们。一旦代理重新加入集群，协调机制应将集群状态收敛到预期状态。
当调度器丢失其所有数据时，恢复集群状态的过程很复杂，并且设计在很大程度上取决于调度器的架构和数据模型。在 Apache Mesos 上，调度器框架11 可以查询已知任务 ID 的任务状态。Mesos master 会响应非终端任务的当前状态。在 Nomad 上，集群状态捕获在调度器的 raft 存储中，并且没有好的方法来备份集群状态并从快照恢复。用户应重新提交作业。然后，Nomad 可以协调集群状态，这会在服务中产生大量动荡。
结论
在分布式集群调度器的各个方面进行故障设计对于操作稳定性和可靠性至关重要。开发调度器代理时应了解，给定系统上只存在有限数量的资源。进程可能会泄漏资源或消耗超出其预期数量的资源，从而导致资源争用造成的意外性能下降。这些调度器代理还必须能够在给定故障（或一组故障）期间，即使在特定故障模式可能用集群事件淹没调度器的情况下（例如，由电源故障造成的许多代理系统丢失），通过使用健壮的协调机制来收敛到良好状态。
希望构建调度系统的工程师应考虑他们使用的底层基础设施的所有故障模式，并考虑调度系统的操作员如何配置补救策略，同时帮助租户系统所有者在故障排除期间尽可能保持租户系统的稳定。
这一工程领域的前沿性质使其成为最令人兴奋的工作领域之一，使工作负载迁移、统一可扩展性和自愈系统得以广泛应用。
参考文献
1. Apache Mesos; http://mesos.apache.org/documentation/latest/frameworks/。
2. Envoy; https://envoy.k8s.ac.cn/。
3. Fluentd; https://www.fluentd.org/。
4. Ionel, G., Schwarzkopf, M., Gleave, A., Watson, R. N. M., Hand, S. 2016. Firmament：大规模快速集中式集群调度。《第12届Usenix操作系统设计与实现研讨会论文集》；https://research.google.com/pubs/pub45746.html。
5. Isard, M., Prabhakaran, V., Currey, J., Wieder, U., Talwar, K., Goldberg, A. 2009. Quincy：分布式计算集群的公平调度。《第22届 SIGOPS操作系统原理研讨会论文集》：261-276；https://dl.acm.org/citation.cfm?id=1629601。
6. Krasnov, V. 2017. 关于英特尔频率调整的危险性。Cloudflare；https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/。
7. Lo, D., Cheng, L., Govindaraju, R., Ranganathan, P., Kozyrakis, C. 2016. 通过Heracles提高大规模资源效率。《计算机系统汇刊》34(2)；http://dl.acm.org/citation.cfm?id=2882783。
8. Microsoft System Center. 2013. 用于确定服务器容量的方法和公式。TechNet 库；https://technet.microsoft.com/en-us/library/cc181325.aspx。
9. Rosen, R. 2016. 理解新的控制组 API。LWN.net；https://lwn.net/Articles/679786/。
10. Schwarzkopf, M., Konwinski, A., Abd-El-Malek, M., Wilkes, J. 2013. Omega：大型计算集群的灵活、可扩展调度器。SIGOPS欧洲计算机系统会议；https://research.google.com/pubs/pub41684.html。
11. Verma, A., Pedrosa, L., Korupolu, M., Oppenheimer, D., Tune, E. Wilkes, J. 2015. 谷歌使用 Borg 进行大规模集群管理。《第10届欧洲计算机系统会议论文集》；https://dl.acm.org/citation.cfm?id=2741964。
相关文章
Hadoop 超线性可扩展性
Neil Gunther、Paul Puglia 和 Kristofer Tomasette
并行性能的永动机
https://queue.org.cn/detail.cfm?id=2789974
与 Phil Smoot 的对话
管理大型服务的挑战
https://queue.org.cn/detail.cfm?id=1113332
网络是可靠的
Peter Bailis 和 Kyle Kingsbury
现实世界通信故障的非正式调查
https://queue.org.cn/detail.cfm?id=2655736
Diptanu Gon Choudhury (@diptanu) 在 Facebook 从事大规模分布式系统方面的工作。他是 Nomad 开源集群调度器的维护者之一，之前曾在 Netflix 从事基于 Apache Mesos 的集群调度器工作。
Timothy Perrett (@timperrett) 是一位资深基础设施工程师、已出版的作家和演讲者，曾在多家蓝筹公司领导工程团队。他主要对调度系统、编程语言理论、安全系统以及改变行业软件工程方法感兴趣。
版权所有 © 2018 。
最初发表于 Queue vol. 16, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Niklas Blum, Serge Lachapelle, Harald Alvestrand - WebRTC - 开放 Web 平台的实时通信
在这个疫情时期，世界比以往任何时候都更转向基于互联网的 RTC（实时通信）。在过去十年中，RTC 产品的数量激增，这在很大程度上是由于更便宜的高速网络接入和更强大的设备，同时也归功于一个名为 WebRTC 的开放、免版税平台。WebRTC 的作用正在从实现有用的体验转变为对于数十亿人继续工作和教育以及在疫情期间保持重要的人际交往至关重要。WebRTC 未来的机遇和影响确实令人着迷。
Benjamin Treynor Sloss, Shylaja Nukala, Vivek Rau - 重要的指标
衡量您的站点可靠性指标，设定正确的目标，并努力准确衡量这些指标。然后，您会发现您的服务运行得更好，停机时间更少，并且用户采用率更高。
Silvia Esparrachiari, Tanya Reilly, Ashleigh Rentz - 跟踪和控制微服务依赖关系
如果您曾将钥匙锁在房屋或汽车内，您会对依赖循环感到熟悉。没有钥匙您就无法打开锁，但是不打开锁您就无法拿到钥匙。有些循环很明显，但是更复杂的依赖循环在导致中断之前可能很难找到。跟踪和控制依赖关系的策略对于维护可靠的系统是必要的。
Štěpán Davidovič, Betsy Beyer - 金丝雀分析服务
期望从事产品开发或可靠性的工程师具备统计知识是不合理的；消除这一障碍导致了 CAS 的广泛采用。事实证明，即使对于不需要配置的基本案例，CAS 也很有用，并且显着提高了 Google 的发布可靠性。影响分析表明，CAS 可能已经阻止了数百起值得事后分析的中断，并且不使用 CAS 的组的事后分析率明显更高。
© 保留所有权利。