PDFTitus：向 Netflix 云引入容器
在已有的云原生基础设施中采用容器方法
Andrew Leung、Andrew Spyker 和 Tim Bozarth
2008 年，Netflix 全面转向云迁移，并开始将其所有内部托管的基础设施迁移到 AWS（亚马逊网络服务）。如今，几乎所有 Netflix 服务都在 AWS 中的 VM（虚拟机）上运行。客户的目录浏览体验、内容推荐计算和支付都由 AWS 提供支持。
多年来，Netflix 帮助构建了许多云原生模式，例如松耦合微服务和不可变基础设施，这些模式已成为行业最佳实践。全面迁移到云端对 Netflix 来说非常成功。尽管已经拥有成功的云原生架构，Netflix 仍在投资容器技术。
新兴的容器技术
容器技术使 Netflix 能够以更简单、更灵活和更高效的方式遵循已用于 VM 的许多相同模式。推动这项投资的一些因素包括：
端到端应用程序打包。 用于本地开发的容器镜像与生产环境中运行的镜像相同（或至少非常相似）。这种打包方式使开发人员能够更轻松地在类似生产的环境中构建和测试应用程序，从而提高可靠性并减少开发开销。
灵活的打包。 Netflix 历史上一直提供面向 Java 虚拟机 (JVM) 的开发和部署环境，使用通用的 VM 镜像，应用程序配置“烘焙”到其中。对于非 JVM 应用程序，正确配置此镜像可能很困难。容器镜像提供了一种简便的方法来构建仅包含应用程序所需内容的应用程序特定镜像。
更简单的云抽象。 将 Netflix 应用程序部署到虚拟机中需要选择大致合适的 VM 实例类型，并对其进行配置以运行和管理应用程序。许多因素会影响哪种实例类型最佳，包括硬件（例如，CPU、内存、磁盘）维度、定价、区域可用性和高级功能支持（例如，专用网络或存储功能）。对于许多开发人员来说，这是一个令人困惑的、以机器为中心的步骤，容易出错。容器通过提供更以应用程序为中心的部署来简化此过程，该部署仅需要声明应用程序的需求。
更快、更高效的云资源。 容器是轻量级的，这使得构建和部署它们比 VM 基础设施更快。此外，由于容器仅包含单个应用程序所需的内容，因此它们更小，并且可以更密集地打包到 VM 上，从而减少整体基础设施占用空间。
这些因素不会改变 Netflix 现有云原生基础设施的模式或方法。相反，容器提高了开发人员的生产力，使他们能够更快地开发、部署和创新。容器也在整个行业中兴起，成为部署和运行云原生应用程序的事实标准技术。投资容器可确保 Netflix 的基础设施与关键行业趋势保持一致。
虽然开发人员生产力的价值推动了公司的大部分战略投资，但投资容器的一个重要的实际原因是 Netflix 团队已经开始使用它们。这些团队不仅提供了如何从容器中获益的切实证据，而且还突显了内部容器支持的缺乏。
Netflix 独特的容器挑战
在许多公司中，容器的采用发生在构建新的绿地应用程序时，或者作为更大的基础设施重构的一部分，例如迁移到云端或将单体应用程序分解为微服务。 Netflix 的容器采用与众不同，因为它是由已经在云原生基础设施上运行的应用程序驱动的。这种独特的环境影响了我们构建技术的方式以及我们管理内部采用的方式，具体体现在以下几个方面：
• 由于应用程序尚未进行重构，因此它们可以迁移到容器而无需任何重大更改非常重要。
• 由于 Netflix 文化提倡自下而上的决策，因此没有强制要求团队采用容器。因此，我们最初只关注少数想要尝试容器并希望从采用中获得重大收益的内部用户和用例。
• 我们预计某些应用程序将继续在 VM 中运行，而其他应用程序将在容器中运行，因此确保它们之间的无缝连接非常重要。
• 早期容器采用用例包括传统的微服务和各种批处理作业。因此，目标是同时支持这两种类型的工作负载。
• 由于应用程序将从稳定的 AWS EC2（弹性计算云）基底迁移到运行在 EC2 之上的新的容器管理层，因此提供适当级别的可靠性至关重要。
现有云基础设施中的容器
Netflix 独特的Requirements 导致我们开发了 Titus，这是一个针对 Netflix 云基础设施的容器管理系统。 Titus 的设计侧重于以下几个关键领域：
• 允许现有的 Netflix 应用程序在容器中 unmodified 运行。
• 使这些应用程序能够轻松使用现有的 Netflix 和 AWS 云基础设施和服务。
• 在相同的资源池上调度批处理作业和服务作业。
• 有效且可靠地管理云容量。
Titus 构建在 Apache Mesos8 之上，Mesos 是一个集群管理系统，可在多台机器上代理可用资源。 Mesos 使我们能够控制我们认为重要的方面，例如调度和容器执行，同时处理诸如哪些机器存在以及哪些资源可用等细节。此外，Mesos 已经在其他几家主要公司7,12,14大规模运行。其他开源容器管理系统，例如 Kubernetes10 和 Docker Swarm6（在 Titus 开发期间推出），提供了它们自己的调度和执行容器的方式。鉴于上述具体要求，我们认为我们将很快偏离它们的通用功能，从而限制它们的好处。
Titus 由一个复制的、leader 选举的调度器 Titus Master 组成，它处理将容器放置到大型 EC2 虚拟机池（称为 Titus Agent）上，后者管理每个容器的生命周期。 Zookeeper9 管理 leader 选举，Cassandra11 持久化 master 的数据。 Titus 架构如图 1 所示。
Titus 中的工作由作业规范描述，该规范详细说明要运行的内容（例如，容器镜像和入口点）、元数据（例如，作业的目的和所有者）以及运行它所需的资源，例如 CPU、内存或调度约束（例如，可用区平衡或主机亲和性）。作业规范被提交给 master，并由许多任务组成，这些任务代表正在运行的应用程序的单个实例。 master 将任务调度到 Titus agent 上，后者根据任务的作业规范启动容器。
为轻松采用容器而设计
大多数 Netflix 微服务和批处理应用程序都围绕 Netflix 云基础设施、AWS 服务或两者的一部分构建。 Netflix 云基础设施由各种系统组成，这些系统为在云中运行的 Netflix 应用程序提供核心功能。例如，Eureka18（一种服务发现系统）和 Ribbon21（一种 IPC 库）提供了连接服务的机制。 Atlas16（一种时间序列遥测系统）和 Edda17（一种云资源索引服务）提供了用于监控和分析服务的工具。
这些系统中的许多系统都以开源软件20 的形式提供。同样，许多 Netflix 应用程序使用 AWS 服务，例如 S3（简单存储服务）或 SQS（简单队列服务）。
为了避免要求使用这些服务的应用程序为了采用容器而进行更改，Titus 与许多 Netflix 云和 AWS 服务集成，允许容器化应用程序轻松访问和使用它们。使用这种方法，应用程序开发人员可以继续依赖这些现有系统，而无需采用替代但类似的基础设施。这与其他容器管理系统不同，后者要么提供自己的基础设施服务，要么使用新的、特定于容器的基础设施服务5。
与现有云集成
在某些情况下，通过 Titus 启用对 Netflix 云基础设施系统的访问非常简单。例如，许多基于 Java 的平台服务客户端仅需要 Titus 在容器中设置特定的环境变量。这样做会自动启用分布式配置服务15、实时数据管道系统27 等的使用。
其他集成需要对基础设施服务本身进行更改，以便能够与 Titus 控制平面（通常除了 EC2 之外）通信或理解容器级数据。例如，Eureka 客户端已更新为能够理解从 EC2 VM 以及 Titus 容器注册的服务。同样，健康检查轮询系统已更改为查询 Titus 并为容器以及 VM 提供健康检查轮询。实例上的 Atlas 遥测 agent 已更改为从 Titus agent 收集和发出容器级系统指标（例如，CPU 和内存使用率）。以前，它仅收集整个主机的指标。
除了使 Netflix 应用程序更容易在容器中运行之外，这些集成还降低了在 Netflix 中采用容器所需的学习曲线。用户和团队能够使用他们已经熟悉的工具和流程，无论他们使用的是 VM 还是容器。例如，一个具有现有 Atlas 遥测仪表板和警报的团队可以将他们的应用程序从 VM 迁移到容器，同时保持他们的遥测和运营系统不变。
与 Netflix 云基础设施集成还允许 Titus 开发团队不专注于重建现有的内部云组件。在几乎所有情况下，与现有 Netflix 服务集成的努力都远比实施或引入新的特定于容器的该服务版本容易得多。
我们没有在 Titus 中实施各种部署策略（例如 Red/Black 或滚动升级），而是选择利用 Spinnaker22，Netflix 的持续交付工具。 Spinnaker 提供了云提供商的概念，这使其能够跨 Titus 以及 EC2 编排应用程序部署。除了在 Titus 上提供熟悉的部署工具之外，Spinnaker 的使用还允许 Spinnaker 团队（专门从事持续交付）实施如何编排部署的逻辑，而 Titus 开发团队能够专注于容器调度和执行。
可以肯定的是，Netflix 云的某些方面要么工作方式不同，要么不适用于 Titus。然而，通过与现有的 Netflix 组件集成，而不是要求使用新的组件，Titus 提供的每个集成都逐渐降低了一些团队和用户的采用曲线。
启用 AWS 集成
使容器易于采用的另一个关键方面是启用 AWS 服务的使用。许多 Netflix 应用程序都围绕各种 AWS 服务（例如 S3 或 SQS）构建。使用 AWS 服务需要正确的 IAM（身份和访问管理）3 凭据才能授权服务调用。
对于在 EC2 VM 中运行的应用程序，身份和凭据信息由元数据服务4 通过元数据服务4 提供，该服务4 在众所周知的 IP 地址上可用。此元数据服务以 EC2 VM 的粒度提供凭据，这意味着同一 VM 上的容器化应用程序必须共享主机的 IAM 凭据（这违反了最小权限原则）或不使用 AWS 服务。
Titus 使用元数据服务代理，该代理在每个 agent VM 上运行，并仅为容器提供其特定的 IAM 凭据。 Titus 作业声明所需的 IAM 角色。当容器化应用程序向元数据服务 IP 发出 IAM 请求时，代理通过主机路由规则拦截这些请求，这些规则将这些请求重定向到它。
代理从 Titus 提供的任务配置信息中提取容器的 IAM 角色，然后使用主机的 IAM assume role 功能来获取特定的 IAM 凭据并将其返回给容器。 IAM assume role 允许主体的 IAM 角色（在本例中为主机的角色）临时承担另一个主体（在本例中为容器的角色）的身份能力。此方法使用与 EC2 VM 中使用的相同 IAM 角色为容器提供其 IAM 凭据。除了 IAM 角色之外，代理还为容器提供 Titus 实例身份信息，而不是 EC2 身份信息。 Eureka 客户端等客户端库使用此信息。
通用网络是关键
许多集成的重要的促成因素是通用网络基础设施。容器化应用程序与现有基础设施之间的无缝网络通信消除了许多集成和采用障碍。
容器联网的常见解决方案是提供覆盖网络，该网络在现有网络之上创建单独的网络。这种方法很有吸引力，因为它解耦了两个网络，并且不需要更改底层网络。但是，覆盖网络将容器的网络空间与现有网络隔离，并且需要网关或代理来连接它们。
另一种常见方法是从主机的 IP 为容器分配特定端口。虽然这允许容器的 IP 成为现有网络 IP 空间的一部分，但它允许容器仅使用它们必须预先知道的特定端口，限制了使用相同端口的容器的并置，并将主机的网络策略暴露给容器。此外，应用程序和基础设施必须以不同于处理 VM 网络（IP）的方式处理容器网络（端口）。由于许多 Netflix 系统都了解 IP，但不了解端口，因此将额外的端口数据改装到必要的系统中将是重要的。
Titus 通过将容器连接到与 VM 连接的相同 AWS 虚拟私有云 (VPC) 网络，为每个容器提供唯一的 IP 地址。使用通用 VPC 允许容器与 VM 共享相同的 IP 地址空间，并使用相同的网络策略和功能，例如 AWS SG（安全组）。这种方法避免了管理端口的需要，因为每个容器都获得自己的 IP 和完整的端口范围以及网络网关。
当启动请求可路由 IP 地址的容器时，Titus 会将 AWS ENI（弹性网络接口）2 附加到运行该容器的 agent VM。附加 ENI 会在 VM 上创建一个新的网络接口，可以从中分配多个 IP 地址。这些地址是从与 VPC 中的 VM 相同的 CIDR（无类别域间路由）范围分配的，这意味着容器和 VM 可以直接寻址彼此的 IP。通过 ENI 分配 IP 使 Titus 避免了管理可用的 VPC IP 或直接修改 VPC 路由表。
当 Titus 准备启动新容器时，它会为其创建一个网络命名空间，从 ENI 为其分配一个特定的 IP 地址，并使用 veth（虚拟以太网）接口将容器的网络命名空间连接到主机。主机上的路由规则将该 IP 的所有流量路由到 veth 接口，并且网络命名空间内的路由规则为容器配置分配的 IP。
容器与 VM 共享相同的 VPC 网络的另一个好处是它们使用通用的网络安全策略，例如 AWS 安全组，这些安全组提供虚拟防火墙1。 每个 ENI 都可以配置为使用一组 SG 防火墙规则，这些规则适用于进出接口的任何流量。 Titus 将容器请求的 SG 应用于与该容器关联的 ENI，从而允许对其流量强制执行 SG 防火墙规则。
可以附加到 VM 的 ENI 数量有限，并且可能少于 Titus 可以分配给它的容器数量。为了更有效地使用 ENI，Titus 允许容器共享同一个 ENI。然而，只有当容器使用相同的安全组配置时，这种共享才是可能的，因为 SG 只能为整个 ENI 配置。在这种情况下，每个容器都将具有唯一的 IP 地址，并且通用防火墙规则将应用于它们的流量。图 2 显示了共享 ENI 的示例。在此示例中，三个容器中的每一个都具有唯一的 IP 地址，这些地址是从附加到主机的 ENI 分配的。然而，容器 1 和容器 2 可以通过同一个 ENI 路由流量，因为它们都只使用安全组 X。
Titus Master 通过将 SG 和 ENI 视为两级资源来启用这种共享，以便它可以将容器调度到具有相同 SG 配置的现有 ENI 之后。 Titus 还通过 Linux 流量控制为每个容器提供有保证的网络带宽。它根据容器请求的带宽设置令牌桶速率。这些网络功能避免了迁移到容器的应用程序的更改，并使在容器或 VM 中运行的应用程序对外部服务透明。
拥有通用的网络基础设施简化了容器的采用。需要连接到应用程序的外部服务不必关心应用程序正在使用哪种技术。这种透明性使现有系统更易于与容器化应用程序协同工作，并使 VM 和容器的混合环境更易于管理。
支持批处理和服务工作负载
早期的 Netflix 容器用例涉及批处理作业和服务应用程序。这些工作负载的不同之处在于，批处理作业旨在运行到完成，并且运行时可能在几秒到几天之间，而服务旨在“永远运行”。与其使用两个不同的系统管理这两种不同类型的工作负载，不如使用容器隔离来共置这些作业，这可以提高组合集群利用率并减少运营负担。
由于这两种作业类型具有不同的生命周期和管理需求，因此 Titus Master 将作业管理的角色与任务放置的角色分开。作业管理处理每种作业类型的生命周期，例如批处理作业的最大运行时和重试策略或服务作业的扩展策略。任务放置将任务分配给集群中的空闲资源，并且只需要考虑任务所需的资源和调度约束，例如可用区平衡。
对于任务放置，Titus 使用 Fenzo19，这是一个用于 Mesos 框架的可扩展调度器库。 Fenzo 在 Netflix 构建，并且已经被一个名为 Mantis24 的内部流处理系统使用。 Fenzo 将任务分配给 Mesos 提供的资源报价，并支持各种可以配置和扩展的调度目标。
Titus 使用 Fenzo 的装箱算法与其 agent 自动扩展功能相结合，以根据工作负载需求动态地扩大和缩小 agent 池。自动扩展 agent 池允许 Titus 将空闲的、已购买的 AWS 预留实例让给其他内部系统，并限制使用 AWS 更昂贵的按需池。 Fenzo 支持适应度计算器的概念，该概念允许调整调度决策的质量。 Titus 使用此功能来权衡调度速度和分配质量。
虽然 Titus Master 是一个单体调度器，但这种解耦是一种有用的模式，因为它利用了双层调度器设计25 的某些方面。 Fenzo 充当集中式资源分配器，而作业管理器允许对不同作业类型进行解耦管理。这为每个作业管理器提供了用于任务放置和 agent 管理的一致策略，并且只需要它们专注于作业生命周期。其他调度器26 具有类似的关注点分离，但 Fenzo 提供了丰富的 API，允许作业管理器支持各种用例，并且可以扩展以支持具有特殊需求的作业类型。
构建具有单独作业管理器的单体调度器与其他基于 Mesos 的系统不同，在这些系统中，不同类型的工作由不同的 Mesos 框架管理。在这些情况下，每个框架都充当该作业类型的完整、独立的调度器。 Titus 被设计为 Mesos 集群上的唯一框架，这避免了资源锁定和多框架可能发生的资源可见性问题，并允许在可用完整集群状态的情况下进行任务放置。避免这些问题有助于 Titus Master 以更快的速度进行调度并做出更好的放置决策。
异构容量管理
通过 Titus 使用容器的好处之一是，它抽象化了应用程序在 VM 中执行的许多以机器为中心的管理。在许多情况下，用户可以告诉 Titus“运行此应用程序”，而无需担心容器在何处或在哪个实例类型上运行。但是，用户仍然希望围绕其应用程序是否或何时运行获得一些保证。当运行具有不同目标和优先级的应用程序时，这些保证尤其重要。例如，微服务希望知道它能够扩展其容器数量以响应流量增加，即使批处理作业可能通过在同一集群上启动数千个任务来消耗大量资源。
此外，在 EC2 VM 中运行的应用程序已经习惯了 AWS 的预留实例概念，该概念保证了提前购买的 VM 容量。为了在 VM 和容器之间实现更一致的容量概念，Titus 提供了层和容量组的概念。
Titus 目前提供两个层：一个层确保 Titus Agent VM 已启动并准备好运行容器，另一个层允许 agent 池随着工作负载的变化而扩展和缩小，如图 3 所示。两者之间的主要区别是启动容器的时间。第一个层称为关键层，如图中的实线边框所示。它使 Titus 能够立即启动容器，而无需等待 EC2 预置 VM。此层以启动延迟为代价优化，运行的 VM 可能比应用程序当前需要的更多。
第二个层称为灵活层，仅预置足够的 agent VM 来处理当前工作负载（尽管它确实保留了少量的空闲实例 headroom，以避免过度激进的向上和向下扩展）。在灵活层中扩展 agent VM 允许 Titus 消耗更少的资源，但当需要在容器启动之前预置 EC2 VM 时，它可能会给任务带来启动延迟。关键层通常由微服务使用，这些微服务需要其应用程序能够快速扩展以响应流量变化，或者由具有人为交互元素的批处理作业使用，例如，当用户期望从作业获得实时响应时。 agent 的数量根据需要向上和向下扩展，如图中的虚线边框所示。
容量组是每个层之上的逻辑概念，可保证应用程序或一组应用程序获得一定数量的专用容量。例如，微服务可能希望保证它将有能力扩展以匹配其峰值流量，或者批处理作业可能希望保证一定数量的任务吞吐量。在容量组之前，如果其他应用程序消耗了所有集群资源，则 Titus 上的应用程序可能会受到饥饿的影响（通常这些饥饿是由提交作业的脚本中的错误或不考虑其作业将消耗的容量量的用户引起的）。此外，容量组帮助用户思考和沟通他们预期的容量需求，这有助于指导 Titus 自己的容量规划。
结合容量组和层允许应用程序在成本（为应用程序预留可能未使用的 agent 资源）和可靠的任务执行（确保应用程序不会被另一个应用程序饿死）之间进行权衡。这些概念在某种程度上类似于 AWS 的预留实例和按需实例概念。提供类似的容量概念通过允许用户以类似于他们考虑 VM 容量的方式考虑容器容量来简化容器的采用。
管理容器采用
对于大多数公司来说，开始采用新技术是困难的，Netflix 也不例外。早期存在相互竞争的采用担忧：要么容器采用速度过快，并随着 Titus 的成熟而导致规模和可靠性问题，要么容器采用将仅限于少数用例，并且不值得投资。
尽管存在这些担忧并且缺乏内部支持，但一小部分团队已经开始采用容器并意识到好处。这些早期用户提供了容器正在解决实际问题的具体用例，因此最初的重点是他们的用例。我们假设这些早期采用者将展示容器和 Titus 的价值，同时还允许我们构建可推广用于未来用途的功能基础。希望这种方法能够让采用有机地发生，并减轻前面提到的担忧。
这些早期团队运行各种临时的批处理作业，并且由于以下几个原因，成为 Titus 的初始用户是有道理的。首先，他们的用例对 Titus 早期提供的有限的可用性和性能更具容忍度； Titus 中断不会危及 Netflix 客户体验。其次，这些团队已经在使用容器，因为他们的数据处理框架和语言使容器镜像成为一种简单的打包解决方案。第三，许多用户是数据科学家，简化的界面吸引了他们不想管理基础设施的愿望。其他团队也对 Titus 感兴趣，但被有意拒绝，因为他们不太适合。这些团队要么无法从容器中看到显着的好处，要么有 Titus 在此阶段无法轻松满足的要求。
早期用户推动了我们对 Netflix 和 AWS 集成、调度性能以及系统可用性的关注，这有助于其他早期采用者。随着我们在这些方面取得改进，我们开始致力于服务作业支持。早期的服务采用者包括多语言应用程序和那些快速开发迭代很重要的应用程序。这些用户推动了前面描述的调度器增强功能、服务常用的集成（例如自动金丝雀分析系统）以及更好的端到端开发人员体验。
Titus 目前每天启动大约 150,000 个容器，其 agent 池由跨多个 AWS 区域的数千个 EC2 VM 组成。随着使用量的增长，对运营的投资也在增加。这种关注提高了 Titus 的可靠性和可扩展性，并增强了内部团队对其的信心。因此，Titus 支持不断增长的各种内部用例。它为客户交互式流媒体体验、驱动内容推荐和购买决策的批处理作业以及帮助工作室和内容制作的应用程序提供支持。
未来的关注领域
到目前为止，Titus 专注于使 Netflix 应用程序能够使用容器的基本特性和功能。随着更多用例采用容器以及规模的增加，开发重点预计将发生转变。 Netflix 计划投资的关键领域示例包括：
多租户。虽然当前的容器技术提供了重要的进程隔离机制，但它们并不能完全消除嘈杂邻居干扰。共享 CPU 资源可能会导致上下文切换和缓存争用开销28,13，并且共享内核组件（例如，网络文件系统内核模块）并非都了解容器。我们计划在用户空间和内核级别改进 Titus agent 提供的隔离。
更可靠的调度。对于批处理和服务应用程序，有许多高级调度器功能可以提高其可靠性和效率。例如，Titus 目前在任务放置后不会重新调度任务。随着 agent 池的变化或其他任务完成，master 最好重新考虑任务的最佳放置，例如改善其在可用区之间的平衡。
更高的资源效率。除了更密集地打包 EC2 VM 之外，Titus 还可以通过更智能地使用资源来提高云使用率。例如，当分配了容量组但未使用时，Titus 可以在这些空闲资源上运行可抢占的最佳努力批处理作业，并在需要时将其让给预留的应用程序。
同样，Netflix 在少数内部用例23 之间代理其已购买但空闲的 EC2 预留实例。 Titus 可以通过低成本的临时 agent 池使更多内部团队更容易使用这些实例。
虽然只有一小部分 Netflix 内部应用程序使用 Titus，但我们相信我们的方法使 Netflix 能够快速采用容器并从中受益。尽管细节可能特定于 Netflix，但通过与现有基础设施集成并与合适的早期采用者合作来提供低摩擦容器采用的方法，对于任何希望采用容器的组织来说，都可能是一种成功的策略。
致谢
我们要感谢 Amit Joshi、Corin Dwyer、Fabio Kung、Sargun Dhillon、Tomasz Bak 和 Lorin Hochstein 对本文提供的有益意见。
参考文献
1. AWS EC2 Linux 实例安全组； http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html。
2. AWS 弹性网络接口； http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ElasticNetworkInterfaces.html。
3. AWS Identity and Access Management； https://aws.amazon.com/iam/。
4. AWS 实例元数据和用户数据； http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html。
5. 云原生计算基金会项目； https://www.cncf.io/projects/。
6. Docker Swarm； https://github.com/docker/swarm。
7. Harris, D. 2013. Airbnb 正在将自己打造成一家数据驱动型公司。 Gigaom; https://gigaom.com/2013/07/29/airbnb-is-engineering-itself-into-a-data-driven-company/。
8. Hindman, B., Konwinski, A., Zaharia, M., Ghodsi, A., Joseph, A., Katz, R., Shenker, S., Stoica, I. 2011. Mesos：数据中心细粒度资源共享平台。载于第 8 届 Usenix 网络系统设计与实现会议论文集：295-308。
9. Hunt, P., Konar, M., Junqueira, F. P., 和 Reed, B. 2010. Zookeeper
互联网规模系统的无等待协调。载于2010 年 USENIX 年度技术会议论文集，2010 年 6 月。
10. Kubernetes； https://kubernetes.ac.cn。
11. Lakshman, A. 和 Malik, P. 2009. Cassandra - 一种去中心化结构化存储系统。载于LADIS，2009 年 10 月。
12. Lester, D. 2015. 关于 Apache Aurora 的一切； https://blog.twitter.com/engineering/en_us/a/2015/all-about-apache-aurora.html。
13. Leverich, J., Kozyrakis, C. 2014. 调和高服务器利用率和亚毫秒级服务质量。载于欧洲计算机系统会议论文集。
14. Mesosphere. 2015. Apple 详细介绍了如何在 Mesos 上重建 Siri； https://mesosphere.com/blog/apple-details-j-a-r-v-i-s-the-mesos-framework-that-runs-siri/。
15. Netflix Archaius； https://github.com/Netflix/archaius。
16. Netflix Atlas； https://github.com/Netflix/atlas。
17. Netflix Edda； https://github.com/Netflix/edda。
18. Netflix Eureka； https://github.com/Netflix/eureka。
19. Netflix Fenzo； https://github.com/Netflix/Fenzo。
20. Netflix 开源软件中心； https://netflix.github.io/。
21. Netflix Ribbon； https://github.com/Netflix/ribbon。
22. Netflix Spinnaker； https://www.spinnaker.io/。
23. Park, A., Denlinger, D., Watson, C. 2015. 创建您自己的 EC2 现货市场。Netflix 技术博客； http://techblog.netflix.com/2015/09/creating-your-own-ec2-spot-market.html。
24. Schmaus, B., Carey, C., Joshi, N., Mahilani, N., Podila, S. 2016. 使用 Mantis 进行流处理。Netflix 技术博客； http://techblog.netflix.com/2016/03/stream-processing-with-mantis.html。
25. Schwarzkopf, M., Konwinski, A., Abd-El-Malek, M., Wilkes, J. 2013. Omega：用于大型计算集群的灵活、可扩展的调度器。载于第 8 届欧洲计算机系统会议论文集： 351-364。
26. Vavilapalli, V. K., Murthy, A. C. Douglas, C., Agarwal, S., Konar, M., Evans, R., Graves, T., Lowe, J., Shah, H., Seth, S., Saha, B., Curino, C., O'Malley, O., Radia, S., Reed, B., Baldeschwieler, E. 2013. Apache Hadoop YARN：又一个资源协商器。载于第 4 届云计算年度研讨会论文集，文章编号 5。
27. Wu, S., Wang, A., Daxini, M., Alekar, M., Xu, Z., Patel, J., Guraja, N., Bond, J., Zimmer, M., Bakas, P. 2016. Netflix 数据管道的演变。 Netflix 技术博客； https://techblog.netflix.com/2016/02/evolution-of-netflix-data-pipeline.html。
28. Zhang, X., Tune, E., Hagmann, R., Jnagal, R., Gokhale, V., Wilkes, J. 2013. CPI2：用于共享计算集群的 CPU 性能隔离。载于欧洲计算机系统会议论文集。
相关文章
Borg、Omega 和 Kubernetes
从十年来的三个容器管理系统中学到的经验教训
- Brendan Burns、Brian Grant、David Oppenheimer、Eric Brewer 和 John Wilkes
https://queue.org.cn/detail.cfm?id=2898444
使用容器对容器进行集群级日志记录
基于容器的云部署的日志记录挑战
- Satnam Singh
https://queue.org.cn/detail.cfm?id=2965647
容器推动迈向蜉蝣服务器
容器革命代表着对多任务系统思考方式的大规模转变。
- Chris Edwards
https://cacm.acm.org/magazines/2016/12/210377-containers-push-toward-the-mayfly-server/fulltext
Andrew Leung (@anwleung) 是 Netflix 的高级软件工程师，他在那里帮助设计、构建和运营 Titus。在加入 Netflix 之前，他曾在 NetApp、EMC 和多家初创公司从事分布式文件和存储系统工作。他于 2009 年获得加州大学圣克鲁兹分校博士学位。
Andrew Spyker (@aspyker) 管理 Titus 开发团队。他的职业生涯重点是中间件和基础设施的功能、性能和可扩展性工作。在帮助 Netflix 云平台之前，他曾担任 IBM WebSphere 软件和 IBM 云的首席性能工程师。
Tim Bozarth (@timbozarth) 是 Netflix 平台总监，专注于使 Netflix 工程师能够高效地大规模开发和集成他们的应用程序。他的职业生涯一直专注于构建系统，以优化 Netflix 和一系列初创公司的开发人员生产力和可扩展性。
版权所有 © 2017，所有者/作者持有。出版权已授权给 。
最初发表于 Queue vol. 15, no. 5—
在 数字图书馆 中评论本文
更多相关文章
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen - 在线事件处理
对跨异构存储技术的分布式事务的支持要么不存在，要么存在较差的操作和性能特征。相比之下，OLEP 越来越多地用于在此类设置中提供良好的性能和强大的 一致性保证。在数据系统中，日志通常用作内部实现细节。OLEP 方法有所不同：它使用事件日志而不是事务作为数据管理的主要应用程序编程模型。传统数据库仍然使用，但它们的写入来自日志，而不是直接来自应用程序。使用 OLEP 不仅仅是开发人员的实用主义，而且它还提供了许多优势。
Marius Eriksen - 大规模功能性
现代服务器软件在开发和运营方面要求很高：它必须始终在所有位置可用；它必须在几毫秒内回复用户请求；它必须快速响应容量需求；它必须处理大量数据甚至更多流量；它必须快速适应不断变化的产品需求；在许多情况下，它必须容纳一个庞大的工程组织，其众多工程师就像一个又大又乱的厨房里的谚语厨师。
Caitie McCaffrey - 分布式系统的验证
Leslie Lamport 以其在分布式系统方面的开创性工作而闻名，他曾说过：“分布式系统是指即使您不知道存在的计算机发生故障也会导致您自己的计算机无法使用的系统。” 鉴于这种黯淡的前景和大量可能的故障，您如何开始验证和确认您构建的分布式系统正在做正确的事情？
Philip Maddox - 测试分布式系统
分布式系统可能特别难以编程，原因有很多。它们可能难以设计、难以管理，而且最重要的是，难以测试。即使在最佳情况下，测试普通系统也可能很困难，而且无论测试人员多么勤奋，错误仍然可能通过。现在，将所有标准问题乘以在可能都在不同操作系统上的多个框上运行的多种语言编写的多个进程，并且有可能发生真正的灾难。
© 保留所有权利。