2013年5月3日
第11卷，第4期

毫无疑问：您正在构建分布式系统

构建分布式系统需要有条不紊地处理需求。

马克·卡维奇

分布式系统难以理解、设计、构建和运行。与单机相比，它们在设计中引入了指数级更多的变量，使得应用程序问题的根本原因更难被发现。应该说，如果一个应用程序没有有意义的 SLA（服务级别协议），并且可以容忍长时间的停机和/或性能下降，那么入门门槛就会大大降低。然而，大多数现代应用程序都期望用户具有弹性，并且 SLA 通常以“几个 9”来衡量（例如，每月 99.9% 或 99.99% 的可用性）。每增加一个 9 都变得越来越难实现。

更复杂的是，分布式故障通常会表现为间歇性错误或性能下降（通常称为棕色停电）。这些故障模式比完全故障更耗时来诊断。例如，Joyent 运营着多个分布式系统，作为其云计算基础设施的一部分。在这样一个系统中——一个高可用的分布式键/值存储——Joyent 最近经历了瞬态应用程序超时。对于大多数用户来说，系统运行正常，并在其延迟 SLA 的范围内响应。然而，5-10% 的请求超过了预定义的应用程序超时时间。这些故障在开发或测试环境中无法重现，并且经常会在几分钟到几小时内“消失”。对此问题进行故障排除以找到根本原因，需要对数据存储 API (node.js)、系统内部使用的 RDBMS（关系数据库管理系统）(PostgreSQL)、操作系统以及依赖于键/值系统的最终用户应用程序进行广泛的系统分析。最终，根本问题在于导致过度锁定的应用程序语义，但确定根本原因需要大量的数据收集和关联，并消耗了不同专业领域工程师的许多工作时间。

对于从事分布式系统工作的工程师来说，整个前言是相当普遍的知识，示例应用程序的降级是操作大型系统时出现问题的典型情况。然而，当前的计算趋势正在将更多的组织和应用程序带入分布式计算领域，这与几年前的情况大不相同。组织需要构建分布式系统的原因有很多，但这里有两个例子

消费者网站/API 或多租户企业应用程序的需求简单地超过了任何一台机器的计算能力。
企业将现有的应用程序（例如三层系统）迁移到云服务提供商，以节省硬件/数据中心成本。

第一个例子在当今几乎所有面向互联网的公司中都很典型。多年来，这已被广泛讨论，并且肯定是分布式系统研究和创新的温床，然而，这并不是一个已解决的问题。任何上线应用程序仍然需要评估自身的需求和期望的 SLA，并相应地进行设计以适应其系统；没有蓝图。任何成功的新应用程序的使用模式可能与之前的应用程序不同，充其量需要正确应用已知的扩展技术，最坏的情况则需要全新的解决方案来满足其需求。

鉴于当前将现有业务应用程序迁移到云端以节省数据中心成本、开发时间等的趋势，第二个例子越来越普遍。在许多情况下，这些应用程序一直在隔离或低利用率环境中的专用系统上运行。简单地将它们放入通常饱和的环境中，比以往任何时候都更频繁地引发故障，或者它们的设计就是如此。在这些情况下，不可告人的秘密是，在迁移到云环境时必须重写应用程序；要围绕应用程序将要运行的环境进行设计，就需要将其构建为分布式系统。

这两个例子在它们需要分布式解决方案的原因方面处于两个极端，但它们都迫使系统设计人员解决相同的问题。更糟糕的是，大多数成功的现实世界分布式系统主要由那些经历过广泛的学术指导或只是“艰难地走过来”的从业人员构建。虽然许多讨论、文献和演示都集中在诸如 Paxos、³ Dynamo、⁵ 或 MapReduce⁴ 等流行技术上——所有这些技术确实值得关注——但构建大型分布式系统的现实情况是，许多“传统”问题仍未通过现成的解决方案解决，无论是商业解决方案还是开源解决方案。

本文简要介绍了构建真实世界分布式系统的现实情况。其目的既不是提供工具包，也不是为任何特定问题提供任何特定解决方案，也不是劝阻新的构建者构建和操作分布式系统。相反，目标只是强调现实情况，并审视构建分布式系统所需的基础知识。这源于一种趋势，即在希望和祈祷的基础上构建此类系统。太多应用程序是通过将分布式数据库系统与某种形式的应用程序串联起来构建的，并寄希望于最好的结果。相反——与所有形式的工程一样——需要一种有条不紊的、数据驱动的方法，本文的目标是提供关于使用这种方法的有用技巧。

虽然将“云”与分布式系统区分开来很重要，但出于实际原因，大多数新的分布式系统都是在云中构建的——通常是公共云——因此本文的其余部分都假设了这种环境。此外，本文专门关注在线 Web 服务（曾经被称为 OLTP——在线事务处理——应用程序），而不是批处理、信息检索等，后者属于完全不同的问题领域。最后，本文利用一个假设的——但并非完全虚构的——应用程序，以便在开发生命周期的每个阶段提供具体的示例和指导。

分布式系统架构设计

适用于分布式系统架构的最常见术语之一是 SOA（面向服务的架构）。虽然 SOA 可能会让人联想到 CORBA（公共对象请求代理体系结构）代理和 WS-* 标准的不愉快回忆，但松散耦合服务的核心思想——每个服务都服务于一个小功能并彼此独立工作——是可靠的，它们是弹性分布式系统的基础。与上一代相比，服务是新的进程；它们是系统中任何离散功能的正确抽象级别。

构建面向服务架构的第一步是识别构成应用程序整体业务目标的每个功能，并将这些功能映射到具有独立故障边界、扩展域和数据工作负载的离散服务中。对于标识的每个服务，您必须考虑以下项目

地理位置。该系统将是全球性的，还是将在每个区域的“孤岛”中运行？
数据隔离。该系统将提供单租户还是多租户模型？
SLA。必须定义可用性、延迟、吞吐量、一致性和持久性保证。
安全。必须考虑 IAAA（身份、身份验证、授权和审计）、数据机密性和隐私。
使用情况跟踪。了解系统的使用情况对于系统的日常操作以及容量规划至关重要。¹ 它也可能用于对系统使用情况进行计费和/或治理（配额/速率限制）。
部署和配置管理。如何部署系统的更新？

这不是操作分布式系统的完整列表（当然也不是运营基于分布式系统的业务的需求列表，这会带来更多的复杂性）；相反，这是一个在定义分布式系统中的服务时要解决的项目列表。此外，请注意，所有“标准”软件工程问题，例如版本控制、升级、支持等，仍然必须考虑在内，但这里的重点纯粹是分布式系统中给定服务的核心（但不一定唯一）方面。

考虑以下假设的应用程序：一种简单的 Web 服务，用于调整图像大小。从表面上看，这似乎是一个微不足道的问题，因为图像大小调整应该是无状态的事情，而只是请求现有操作系统和库或命令来执行图像处理。然而，即使是最基本的服务，如果您希望以任何规模运行它，也会存在大量陷阱。虽然此类服务的业务价值可能值得怀疑，但它将适合我们在此处建模围绕此实用程序的分布式系统的目的，因为存在足够的复杂性来保证相当多的移动部件——并且服务越复杂，它就越难。

示例系统：图像大小调整服务

现在让我们从业务角度定义示例 Web 服务的特征。由于该服务将简单地调整图像大小，因此系统需要摄取图像、转换它们，并尽快地将它们提供给客户——响应时间对于交互式用户代理（即 Web 浏览器）来说是可以接受的。考虑到大小调整将实时完成，并且为了简化本文，我们假设图像会立即下载，并且它们的长期存储不在本系统的范围内。客户需要能够安全地识别自己（他们这样做的方案不在本文的范围之内，但我们可以假设他们有某种方法可以将凭据映射到身份）。该服务应提供基于使用量的定价模型，因此它需要跟踪每个图像（对于每个请求）的几个维度，例如图像的大小和转换图像所需的 CPU 时间。最后，让我们假设系统运行的每个数据中心都与其他所有数据中心隔离，没有跨数据中心通信。

就采用而言，让我们随便在墙上扔飞镖，假设用户数量上限为 100,000，并且在单个区域中每秒最大请求数为 10,000（但此数字将在每个区域中可用）。业务需要系统在一个月内提供 99.9% 的可用性，并且对于小于 1 兆字节的图像，第 99 个百分位数的延迟应小于 500 毫秒。

虽然这是一个人为设计的示例，需求列表非常短——实际上，真实的系统将具有质量更高的定义——但我们已经可以识别出该系统的几个不同功能，并将它们映射到离散服务中。

分解为服务

如前所述，初始步骤是将“业务系统”分解为离散服务。乍一看，图像大小调整服务似乎只需要几台机器和一些低门槛的方式来在它们之间分配大小调整。在进一步讨论之前，让我们做一些粗略的计算，看看这是否成立。

回想一下，目标是支持每秒 10,000 次大小调整。为了本文的目的，让我们限制输入格式的范围，并假设平均输入大小为每张图像 256 KB，以便系统可以每 CPU 内核每秒处理 10 次转换。考虑到现代 CPU 架构，我们可以选择一个具有 32 个内核的系统（以及足够的 DRAM/IOPS 容量，因此不必担心为此示例的目的而触及其他边界）。显然，这样的系统可以支持每秒 320 次转换，因此为了支持每秒 10,000 张图像的目标，业务至少需要 32 台图像处理服务器的集群才能满足这个数字。为了保持 20% 的浪涌余量，还需要额外的七台机器。为了指向一个漂亮的偶数（并且因为这无论如何都是记事本数学），满足这些目标的粗略数字将是 40 个系统。随着业务的增长，或者如果平均转换时间增加，它将需要更多的系统，因此假设 40 是下限。重点是，此图像服务需要足够的系统，以至于它需要真正的分布式堆栈来运行它。

既然我们已经确认分布式系统是必要的，那么高级图像需求可以映射到离散服务中。我将首先根据我构建分布式系统的经验提出一个架构，尽管有很多替代方法可以做到这一点。选择的理由将在初始规范之后进行；实际上，得出这样的架构将是一个更迭代的过程。

图 1 中的图表将系统分解为几个粗略的服务

面向客户的 API（即 REST 或 representational state transfer 服务器）。
用于将请求发送到计算服务器的分布式消息队列。
权威的身份管理系统，与高性能身份验证“缓存”耦合。
用于运营、计费等的使用情况聚合集群。

当然，还有其他分解系统的方法，但上述示例是一个很好的起点；特别是，它为故障模式、扩展和一致性提供了关注点分离，我们将在迭代组件时详细说明。

图像 API 详细信息

从外向内开始，让我们详细检查图像 API 层。首先，必须指出一个关键点：API 服务器应该是无状态的。您应该努力使分布式系统中的尽可能多的部分无状态。状态始终是所有方面最困难的问题出现的地方，因此如果可以避免保持状态，则应该这样做。

地理位置。 由于需求是在单个区域中运行，因此 API 服务器仅为单个区域提供系统访问权限。
数据隔离。 API 服务器是无状态的，但值得指出的是，为了跨大量客户提供每秒 10,000 次大小调整，系统需要是多租户的。任何给定时间跨客户的差异意味着我们将无法构建专用系统。
SLA 可用性。 可用性是软件/系统或数据中心/网络可以提供的最差数字。由于业务希望系统提供 99.9% 的可用性，因此让我们将此层的目标设置为给定月份 99.99% 的可用性，这允许每月 4.5 分钟的停机时间。此数字是从数据中心边缘测量的，因为系统无法控制客户端网络连接。
SLA 延迟。 API 服务器中任何请求的延迟是每个依赖系统的延迟之和。因此，它必须尽可能低：个位数毫秒到（小）十毫秒，在第 99 个百分位数。
SLA 吞吐量。 如前所述，系统必须支持每秒 10,000 个请求。考虑到非幼稚的实现，我们应该能够在一台给定服务器上支持每秒 5,000 个请求（这个数字纯粹是从实践经验中得出的）。保持 20% 的余量目标，系统需要三台服务器来处理此流量。
SLA 一致性和持久性。 API 层是无状态的。
IAAA。 每个客户都需要他或她自己的身份/凭据。用户不得访问彼此的输入或输出图像（回想一下，我们不提供长期存储，共享在其中才有意义）。必须保存每个大小调整请求的记录。
使用情况跟踪。 我们希望“计量”每个客户的所有请求，以及请求参数——在实现 API 时，我们需要确保系统捕获有关请求的所有维度以传递下去。
部署和配置管理。 系统运营的目标是以一种方式管理系统的所有部署和配置。我们可以暂时搁置这个问题，稍后再讨论。

我们已经确定需要多个 API 服务器，因此必须跨所有 API 服务器管理流量负载平衡。由于有大量的现有技术¹⁰ 和已知的解决方案来解决这个问题，因此对于这个特定方面，我将简明扼要，只是指出必须解决这个问题。解决方案通常涉及轮询 DNS（域名系统）记录到公共 IP 地址的某种组合，其中这些 IP 地址是多个负载均衡器，由诸如 CARP（公共地址冗余协议）之类的协议或涉及 L2/L3（第 2 层/第 3 层）IP 地址接管的类似解决方案解析。

最后，值得指出的是，API 层肯定需要自定义实现。它的语义与业务紧密相关，以至于在自建还是购买的权衡中，实际上别无选择，只能自建。然而，负载平衡提供了许多开源和商业选择，因此这是一个很好的起点。 API 的专门方面可能需要我们自己构建，但从一开始就假设如此是不明智的。

消息传递

API 服务器和图像处理服务器在规模上存在差异，因此需要一种调度机制来将图像传递到可用的转码服务器。有许多方法可以实现这一点，但鉴于单个系统可以调度自己的内核，相对明显的起点是使用分布式消息队列。消息队列可以在接收用户请求的 API 服务器上本地暂存图像，并将就绪消息推送到队列中。这具有提供第一遍调度机制（FIFO，先进先出）的优点，并允许在系统过于繁忙时用户调整大小时间的平稳延迟降级。但是，应该再次声明，与分布式系统中的所有组件一样，消息队列并非没有权衡。特别是，消息队列通常被视为既高可用又一致，但正如 CAP 定理（意味着一致性、可用性和分区容错性）所说，我们不能两者兼得。

一般来说，消息队列优先考虑一致性而不是可用性；大多数开源和商业消息队列都将优先考虑一致性，并在某种主动/备用模式下运行，其中备用模式获得从队列中推送和弹出的消息的（希望是）同步副本。虽然这可能是正确的常见选择，但这确实意味着示例系统必须自动化停机时间，因为备用系统的升级和更新复制拓扑结构并非易事。在讨论该解决方案的外观之前，让我们再次回顾一下需求

地理位置。 这不适用。我们将为每个部署运行一个消息队列。
数据隔离。 多租户——每个部署都有一个逻辑消息队列。
SLA 可用性。 系统需要提供 99.9% 的可用性，并且由于我们假设我们不会从头开始编写新的消息队列，因此我们需要自动化故障转移以尽可能减少此数字。
SLA 延迟。 非排队情况下的延迟（显然，如果消费者读取速度慢，延迟会增加）需要尽可能小。目标是平均亚毫秒延迟，当然对于第 99 个百分位数的请求，延迟为个位数毫秒。幸运的是，大多数消息队列都能够提供这一点，因为它们是内存中的。
SLA 吞吐量。 由于我们正在双向使用消息队列，因此系统需要支持每秒 20,000 个请求（24,000 个带 20% 的余量）。支持此数量所需的系统数量取决于消息队列实现的选择。
SLA 一致性和持久性。 如前所述，队列必须保证 FIFO 语义，因此我们必须具有强一致性保证。
IAAA。 这不适用。
使用情况跟踪。 虽然我们对运营指标感兴趣，但这不适用。
部署和配置管理。 必须自动化故障转移以满足可用性 SLA。

自动化故障转移

为了自动化故障转移，系统需要一个领导者选举机制。虽然关于领导者选举有很多文献，并且多年来出现了许多算法，但我们希望有一个分布式共识协议（例如 Paxos）到位。最终，我们需要可靠地执行领导者选举和故障转移，并且无论网络状态如何，系统都必须依赖权威系统。诸如 Paxos 之类的算法保证所有参与者都将达到相同的状态，并且只要实际操纵拓扑的基础设施依赖于共识协议，拓扑更改的正确排序就得到保证，即使它们可能比期望的时间更长（分布式共识协议不能保证参与者何时达到一个值，只是他们最终会达到）。虽然系统可能会经历比预期更长的停机时间，直到所有参与者都获得正确的值，但时间（希望）将少于我们依赖手动操作来管理此过程的时间。

请注意，实际上这并非易事；许多经验丰富的工程师和管理员认为，最好进行手动故障转移并忍受发生故障时的停机时间增加，因为此过程必须是完美的，否则会冒更大的问题风险（例如，数据损坏、不正确的拓扑结构等）。此外，许多消息队列和数据库系统确实提供了指导和一些可能足够好的故障转移机制，但这些系统中的大多数都不（并且无法）保证在真正的网络分区中正确的拓扑结构，并可能导致“脑裂”场景。因此，如果您的系统必须支持严格的可用性 SLA 并且您需要强一致性，那么就别无选择了。

图像处理服务器

值得庆幸的是，我们以这样一种方式设计了示例系统，即实际的转换服务器是独立的（模消息队列）。因此，对于它们，没有什么需要涵盖的内容是其他地方没有涵盖的。

平台组件

在上述系统中，只有一部分需求实际上支持图像大小调整的核心问题定义。除了图像需求之外，系统还必须支持身份验证/授权和使用情况收集（运行业务还需要更多组件，但为了本文的目的，我们将省略它们）。此外，为了避免重复，本节仅介绍架构看起来像这样的原因的重点，而不是继续逐步介绍每个类别。

身份和身份验证。示例服务需要一个身份管理系统，该系统支持身份验证、授权和用户管理。客户管理发生的频率将远低于 Web 服务请求（如果不是，则该服务将倒闭）。因此，业务希望服务的身份验证请求数量比管理请求多几个数量级。此外，由于这是一个关键功能，但不会为服务增加价值，因此延迟应尽可能低。鉴于这两个陈述，我们可以看到扩展身份验证系统对于跟上服务请求是必要的——如果正确完成，身份验证通常是不可缓存的。

虽然身份验证事件本身是不可缓存的，但是，服务身份验证请求所需的数据是可缓存的，因此我们仍然可以将此系统视为基本上是只读的。这种观察结果允许将“数据平面”与“管理平面”解耦，并独立扩展它们。权衡是您最终得到两个独立的系统，并且在任何此类情况下，它们之间的一致性必然是异步/最终的。实际上，这意味着在客户创建/更新与此数据在数据平面中的可用性之间引入延迟。此技术决策（CAP 中的 A）确实会影响业务，因为新的/更新的客户可能无法立即使用该系统。根据业务需求，系统可能需要为数据复制维护积极的 SLA。

使用情况收集。使用情况收集是身份验证的直接反问题；它是高度写入密集型的，并且数据读取频率很低——通常只读取一次——通常用于处理计费信息（诸如数据仓库之类的业务分析不在本文的范围之内）。此外，计量数据的一致性并不重要，因为唯一的消费者是（通常）内部工具。关于持久性，可以做出一些重要的权衡；在聚合为最终的客户可见的核算之前，任何单个记录或记录组都没有价值。因此，您可以适当地分离持久性 SLA。计量的困难方面是需要处理比请求更多的记录。系统需要存储比仅仅请求更多的轴的使用情况数据，通常需要存储很长时间——为了合规性、客户服务等——并且必须为此数据的任何合理时间切片提供可接受的读取延迟。就本示例而言，我们描述的是使用情况记录捕获和聚合，而不是计费或业务分析。

鉴于这些需求，合理的架构方法是在每个接收客户请求的 API 服务器上执行使用情况记录的本地分组，然后在时间/大小边界之前将这些记录发送到可写扩展且最终一致的暂存系统。一旦记录存储在那里，就期望具有高持久性，因此 dynamo 风格的键/值系统将是此层的不错选择。我们可以定期对此数据运行聚合批处理作业。 MapReduce 系统或类似的分布式批处理系统作为起点是有意义的。数据必须保留很长时间——长达数年——因此使用批处理系统提供了一个聚合数据的机会，并将原始记录沿着客户边界存储，以便以后更容易检索。然后可以将此数据高度压缩并发送到长期、缓慢的存储，例如（最好是）低成本冗余磁盘驱动器或磁带备份。

考虑到略有不同的需求，可以考虑替代方案。例如，如果实时了解使用情况数据很重要，那么相反，使用发布/订阅系统将批处理甚至每个唯一的使用情况记录路由到一些分区聚合系统集群将是合理的，这些系统集群保持“实时”计数。权衡是，随着时间的推移，这种系统的扩展成本更高，因为它需要几乎与 API 请求线性扩展。

架构总结

以下是关于架构的一些关键要点

在故障域、扩展和数据工作负载 (r/w) 的边界上将业务应用程序分解为离散服务。
使尽可能多的东西无状态。
在处理状态时，深入了解 CAP、延迟、吞吐量和持久性要求。

本文的其余部分简要介绍了此类系统的其余生命周期。

实施

现在我们已经介绍了图像处理服务的初始架构——这应该可以作为初步尝试——让我们谈谈实施此类系统中的一些误解。不会提供关于操作系统、语言、框架等的意见——只是一小组可能有用的指导原则。

当一位新工程师着手实施此处描述的此类系统时，典型的第一种方法是立即调查可用的软件——通常是开源的——并将其“粘合”在一起。希望在经历了架构设计此类系统的旋风之旅后，您会认识到这种方法是不明智的。虽然它可能在开发规模上起作用，但每个系统都是由编写它的工程师在一组假设下实现的。这些假设可能与您的分布式系统的要求一致，也可能不一致，但重点是，您有责任了解技术所做的假设及其权衡，然后评估此软件是否在您的环境中工作。常见的情况是某些软件将与您的假设对齐，而某些软件则不会。

对于您需要开发自己的软件来解决系统问题的情况，下一步应该是评估该领域的现有技术。通常可以在某些现有技术中找到解决方案——通常比人们预期的要早——但实现此解决方案的系统的假设与您的假设不同。在这种情况下，将系统的优点分解为第一性原理，并在这些原理的基础上重建。例如，在本文描述的身份验证系统中，考虑到协议的假设和现有的 LDAP 系统复制模型，现有的 LDAP（轻量级目录访问协议）解决方案可能不是正确的选择，但我们当然可以重用信息管理和身份验证机制的许多思想，并以一种可以为我们的环境扩展的方式实现这些基本原语。

作为另一个示例，如果我们需要实施或使用存储解决方案，那么迄今为止的许多现成解决方案都涉及某种类型的 DFS（分布式文件系统）或 SAN（存储区域网络），无论是 NFS（文件）、iSCSI（块）还是其他一些协议的形式。但正如前面所述，这些系统都在 CAP 定理中选择了 C，此外，通常无法扩展超过单个节点的容量。相反，许多应用程序所需的基本原语都存在于现代对象存储中，但具有不同的权衡（例如，没有部分更新），这使得这些存储系统可以更好地处理某些应用程序的分布式扩展。

无论您是能够利用现有组件还是构建自己的组件，所有这些组件都需要考虑如何大规模管理生产部署。我不会在这里深入探讨细节，但仅指出应该考虑配置管理解决方案，并且需要一个可以有效管理许多系统的部署/回滚和状态跟踪的系统。

验证/测试

分布式系统的测试和验证非常困难——通常与最初创建系统一样困难甚至更困难。这是因为分布式系统具有如此多的变量，以至于几乎不可能隔离地控制所有变量；因此，在大多数情况下，系统必须经过经验验证，而不是在理论上被证明是正确的。特别是，网络中的完全中断相对不常见，但短暂的服务降级非常有可能发生。这种降级通常会导致软件的行为与开发过程中遇到的行为不同，从而使系统软件成为最可能的故障原因。因此，分布式系统中故障的首要原因毫无疑问是海森堡错误——瞬态错误，通常可以重复但难以重现，并且依赖于系统中发生的某些事件序列。⁷

分布式系统的验证涉及许多方面，当然需要通过系统驱动足够的负载，以了解它在何处“倾覆”，以便可以进行智能容量规划和监控。然而，更重要的是，必须定期引入故障和降级状态；故障会并且将会发生，并且必须从每个组件中移除其依赖项，以了解系统是否做出适当的反应（即使这意味着向客户返回错误），以及系统是否在依赖项恢复时恢复。 Netflix Chaos Monkey² 是此类方法的最佳公开参考之一；对其测试和生产系统进行自动化故障/降级被认为是其业务运营必不可少的。

运营

最后但同样重要的是分布式系统的运维。为了运行本文描述的系统，我们必须能够捕获和分析硬件和操作系统、网络以及应用软件的各个方面——简而言之，正如格言所说，“凡是运行的，皆可度量”。这主要有两个方面：实时监控以响应故障，以及分析——包括实时的和历史的——使运维人员、工程师和分析师能够理解系统和趋势。

正如到目前为止可能已经显而易见的，大型分布式系统可以为运维数据生成的数据量可能，而且很可能将超过实际服务于业务功能的数据量。如此规模数据的存储和处理可能需要其自身的分布式系统来跟上，这实际上又将我们带回了本文的开头：您将需要一个分布式系统来运维和管理您的分布式系统。

PaaS 和应用外包

最后要考虑的是最近 PaaS（平台即服务）的采用，例如 Google App Engine⁶ 或 Heroku⁸。这些服务已经变得非常流行，因为它们减少了将垂直应用程序推向市场的工程工作，例如传统的 MVC（模型-视图-控制器）Web 应用程序。到现在为止，应该很明显，没有灵丹妙药，在没有尽职调查的情况下就将系统交给第三方是不明智的。PaaS 系统确实适用于许多应用程序——实际上非常好——但同样，前提是您的系统需求与 PaaS 提供商的功能集和权衡相一致；前者相对容易评估，但后者可能很困难或不可能。例如，参考 Rap Genius⁹ 最近公开披露的关于 Heroku 路由权衡的信息。忽略所有法律方面，遇到的问题最终是应用程序延迟的严重下降，这是由适合平台需求而不是租户需求的实施权衡造成的。业务可能仍然正确地选择了 PaaS，但关键是，要找到这个问题的根本原因非常困难，并且业务在最糟糕的时候遇到了这个问题：在生产负载下，随着应用程序的扩展。

结论

众所周知，分布式系统难以实施和运维。尽管如此，随着越来越多的工程师开始运行现代 Web 或移动应用程序，或者只是将现有的企业应用程序迁移到云服务提供商，他们发现自己正在创建分布式应用程序。

如果没有在成功和失败的系统上工作的实践经验，大多数工程师会采取“但愿它能工作”的方法，并尝试将现成的软件（无论是开源的还是商业的）拼凑在一起，但通常无法构建一个弹性、高性能的系统。实际上，构建分布式系统需要一种有条不紊的方法来处理需求，包括故障域、延迟、吞吐量、持久性、一致性以及业务应用程序在应用程序各个方面所需的 SLA。

参考文献

1. Allspaw, J. 2008. The Art of Capacity Planning. O'Reilly Media; http://shop.oreilly.com/product/9780596518585.do.

2. Bennett, C., Tseitlin, A. 2012. Netflix: Chaos Monkey released into the wild. Netflix Tech Blog; http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html.

3. Chandra, T., Griesemer, R., Redstone, J. 2007. Paxos made live. In Proceedings of the 26^th Annual Symposium on Principles of Distributed Computing: 398-407; http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/paxos_made_live.pdf.

4. Dean, J., Ghemawat, S. 2004. MapReduce: simplified data processing on large clusters. In Proceedings of 6^th Symposium on Operating Systems Design and Implementation; http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/mapreduce-osdi04.pdf.

5. DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P, and Vogels, W. 2007. Dynamo: Amazon's highly available key-value store. In Proceedings of the 21st Symposium on Operating System Principles; http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf.

6. Google App Engine. Google Developers; https://developers.google.com/appengine/.

7. Gray, J. 1985. Why do computers stop and what can be done about it? Tandem Technical Report 85.7; http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6561.

8. Heroku Cloud Application Platform; http://www.heroku.com/.

9. Somers, J. Heroku's ugly secret; http://rapgenius.com/James-somers-herokus-ugly-secret-lyrics.

10. Tarreau, W. 2006. Make applications scalable with load balancing; http://1wt.eu/articles/2006_lb/.

喜欢它，讨厌它？请告诉我们

[email protected]

Mark Cavage 是 Joyent 的一名软件工程师，主要从事分布式系统软件工作，并维护多个开源工具包，如 ldapjs 和 restify。他之前曾在 Amazon Web Services 担任高级软件工程师，领导身份和访问管理团队。

最初发表于 Queue 第 11 卷，第 4 期—
在数字图书馆中评论这篇文章

更多相关文章

Marc Brooker, Ankush Desai - AWS 的系统正确性实践
构建可靠和安全的软件需要一系列方法来推理系统正确性。除了行业标准测试方法（如单元测试和集成测试）外，AWS 还采用了模型检查、模糊测试、基于属性的测试、故障注入测试、确定性模拟、基于事件的模拟以及执行跟踪的运行时验证。形式化方法一直是开发过程的重要组成部分——也许最重要的是，形式化规范作为测试预言机，为 AWS 的许多测试实践提供了正确的答案。正确性测试和形式化方法仍然是 AWS 的关键投资领域，这些领域的投资已经看到了出色的回报，加速了这一进程。

Achilles Benetopoulos - 数据中心计算机的中间表示
我们已经达到了分布式计算无处不在的程度。内存中的应用程序数据大小正在超过单台机器的容量，因此需要将其分区到集群中；在线服务具有高可用性要求，只有通过将系统部署为多个冗余组件的集合才能满足这些要求；高持久性要求只能通过数据复制来满足，有时甚至跨越广阔的地理距离。

David R. Morrison - 模拟：分布式系统中未被充分利用的工具
模拟在人工智能系统的兴起中发挥着巨大的作用：我们需要一种高效、快速且经济高效的方式来训练 AI 代理在我们的基础设施中运行，而模拟绝对提供了这种能力。

Matt Fata, Philippe-Joseph Arida, Patrick Hahn, Betsy Beyer - 从企业到云端：Google 的虚拟桌面
超过四分之一的 Google 员工使用内部数据中心托管的虚拟桌面。这种本地产品位于企业网络中，允许用户开发代码、访问内部资源以及从世界任何地方远程使用 GUI 工具。其中最显著的特点是，虚拟桌面实例可以根据手头的任务进行调整大小，具有持久的用户存储，并且可以在公司数据中心之间移动以跟随出差的 Google 员工。直到最近，我们的虚拟桌面还是使用名为 Ganeti 的自研开源虚拟集群管理系统，托管在 Google 公司网络上可商购的硬件上。如今，这项重要且对 Google 至关重要的工作负载在 GCP（Google Compute Platform）上运行。