昨晚，一场大风暴席卷美国东部，掀翻了树木，切断了电力供应。亚马逊网络服务（AWS）在弗吉尼亚州的一个主要数据中心失去了电力。当数据中心失去电力时，数据中心通常会有备用发电机，但备份系统似乎有些故障，AWS的EC2北弗吉尼亚州也离线了。这使得Netflix、Pinterest、Instagram和其他依赖于亚马逊云托管服务的服务全部瘫痪。我对这起事件最喜欢的评论来自Phil Kaplan（@pud），他在推特上写道："云无法与云匹敌"，这让我想到了不同类型的"云"服务，它们对失败的不同敏感性，以及如何使它们更具弹性。积云、层云、卷云、雨云有很多不同的产品称自己为"云"服务。然而，这意味着不同的服务有很大的不同。例如，Salesforce.com网站是最早鼓吹云的好处的人之一。在他们的案例中，他们将自己与传统的客户关系管理（CRM）系统进行比较，后者要求您运行自己的数据库并维护自己的硬件。在Salesforce.com网站在这个例子中，"云"意味着你可以在别人的设备上运行一个专门的应用程序（CRM），并将其作为服务付费。对于他们的核心CRM产品，Salesforce.com网站在全球多个地方运行自己的硬件。然而，Salesforce.com网站购买了另一家名为Heroku的"云"服务提供商。Heroku最初是作为一个平台来运行为Ruby编程语言编写的应用程序的。随着时间的推移，它已经扩展到支持其他语言，包括Java，节点.js，Scala，Clojure和Python。哪里Salesforce.com网站的原始云服务允许您将其CRM应用程序作为服务运行，Heroku允许您从其托管平台运行任何应用程序。Salesforce.com网站运行在公司自己的服务器上，但Heroku运行在亚马逊的AWS服务之上。换言之，Heroku提供了一种云服务，使编写和部署自己的应用程序变得更容易，但他们使用其他人的基础设施来部署它。在所有人开始称所有这些"云"服务之前，分析师给了它们更具体的名称，这些名称以字母开头，总是以"aaS"结尾Salesforce.com网站是软件即服务（SaaS），Heroku是平台即服务（PaaS），AWS是基础设施即服务（IaaS）。我还要补充一个区别：到目前为止，我提到的三个云服务都是我称之为数据和应用（d&a）云服务的。在某种程度上，它们允许您存储数据和进程，而不必考虑底层硬件。它们可能都是云服务，但它们与我们在CloudFlare中构建的服务非常不同（稍后将详细介绍）。服务器一路下滑在印度教神话中，有一个故事讲述了世界是如何靠一只巨龟支撑的。史蒂芬·霍金的《时间简史》中有一个奇闻轶事，讲的是一位科学家给公众做了一次关于宇宙结构的讲座：讲座结束时，教室后面的一位小老太太站起来说："你告诉我们的都是胡说八道。"世界真的是一个平板，支撑在一只巨大的乌龟的背上。"科学家在回答"乌龟站在什么上面？""你很聪明，年轻人，非常聪明，"老太太说但一路上都是海龟！"

虽然很容易忘记这些服务提供的抽象，但在所有这些云之下是服务器、交换机和路由器。如果你使用Salesforce.com网站对于CRM和您的公司增加了大量新客户，您不需要考虑添加更多驱动器或服务器来扩大规模。相反，Salesforce.com网站处理跨其硬件增加容量的过程。如果您在像AWS的EC2这样的云服务之上开发，随着应用程序的扩展，您可以"启动"新实例以提供更多的计算能力。这些实例是物理服务器上容量的一小部分，可以与其他EC2用户共享。因为每个EC2客户只使用对于它们的应用来说，跨服务器的利用率非常高。当乌云散去的时候不可避免的是，组成这些云的硬件会时不时地出现故障。旋转硬盘崩溃，内存损坏，CPU过热，路由器脱落，或者有人断开了错误的电源电路，导致整个机架设备离线。当这些硬件出现故障时，不同的云服务将以不同的方式作出反应。

Salesforce.com网站运行自己的硬件和软件。他们创建了跨多个硬件系统复制应用程序本身的系统。如果一个系统发生故障，负载平衡器将切换到另一个硬件系统来处理请求。客户数据存储在Salesforce.com网站也被软件复制。但我不知道Salesforce.com网站的冗余策略，他们可以放心地使用RAID在存储阵列的多个磁盘之间复制数据，并在发生重大故障时备份到某些长期存储。它们还可能在在一个特定的数据中心内有多个存储阵列，并且可能在数据中心之间复制数据。复制数据相对容易。复制数据并保持同步是很困难的。如果地理位置不同，问题就更难解决。光速是非常快的，但它仍然需要一个光子在完美的条件下从旧金山到阿姆斯特丹往返近60米。在构成互联网的实际光纤和铜缆中传输速度较慢，如果考虑到互联网的实际性能，速度会慢得多。如果两个人在更新之间的延迟窗口期间更改两个位置的同一数据段，则会发生非常不可预测的坏事情。同步的挑战对于某些系统，复制数据比其他系统更容易。比较一下谷歌和推特。如果你在Google上搜索，你会找到公司众多地理分布的数据中心中的一个，得到一个结果集。其他人运行不同的搜索不同的数据中心得到的结果可能略有不同。谷歌并没有承诺每个人都会看到相同的搜索结果。因此，他们有一个相对直接的数据复制问题。构成Google索引的数据将在他们所有的设施中"最终保持一致"，但这不会损害底层应用程序。

另一方面，Twitter承诺你会看到你关注的人的实时更新。这就造成了一个更加困难的数据复制问题，并解释了为什么Twitter拥有一个更加集中的基础设施，并继续经历更多的扩展难题。Facebook也提供了一个有趣的案例研究。随着Facebook规模的扩大，他们不再强调时间轴的实时更新，以便更容易地扩展其基础设施。Twitter、Facebook、Google（他们新的重点放在需要更多数据同步的产品上），以及许多其他聪明人正在努力减轻数据复制和同步的问题，但光速只是如此之快，在某种程度上，你总会碰到物理定律。然而，关键是，选择单独在云中托管并不足以确保您的应用程序具有容错性。数据和应用层仍然难以扩展，即使使用像AWS这样的服务来创建弹性，仍然需要程序员使他们的应用服务器冗余，并尽可能和实际地复制他们的数据。前端层缩放虽然数据同步使数据和应用层的地理扩展变得困难，但是web应用程序堆栈中有一部分是大规模分布式扩展的自然候选：前端层。所有的web服务都有一个前端。它是服务的一部分，接收请求并将其交给应用程序以开始转换。用户请求的响应也从后端返回到应用程序层。与数据和应用层不同，前端层不需要关于应用程序的特定知识。这意味着它可以在地理位置上分布，而不需要特殊的应用程序逻辑或复杂的数据复制策略。前端层可以根据用户的特性帮助调整来自数据和应用层的响应。例如，前端层可以处理响应，而不是数据和应用层根据某人是在iPad上还是在桌面PC上使用internetexplorer来改变响应的表示。前端层还可以保护数据和应用层免受潜在威胁和攻击。事实上，如果您使用Anycast这样的协议来按地理位置路由请求，您就可以隔离攻击或任何网络问题，只对其产生影响