亚马逊CTO对过去十年的经验总结.pdfVIP

AWS（AmazonWebService）开始于2006年3月14日Amazon

S3的发布，距今已有十年时间。回首过去十年，我们在构建和运营AWS云计

算服务中积累了大量的经验教训——这些服务不仅需要确保安全性、可用性和

可扩展性，同时还要以尽可能低廉的成本提供可预测的性能。考虑到AWS是

世界范围内构建和运营此类服务的开拓者，这些经验教训对我们的业务来说至关

重要。正如我们多次重申的，“经验不存在压缩算法”。考虑到AWS拥有每月

超过一百万的活跃用户，而这些用户也许会为数以亿计的自家客户提供服务。因

此，积累上述经验教训的机会在AWS比比皆是，在这些经验教训中，我挑选

了一些分享给大家，希望对各位也能有所帮助。

1.构建可持续演进的系统从做AWS的第一天开始，我们就清楚地认识到，

我们在做的这套软件不是一劳永逸的。现在可以用的软件，一年之后很可能将不

再适用。我们的预期是，随着（用户）数量级的增加一或两次，我们都需要重新

检视和适当修改我们已有的架构，以便解决扩展性的问题。但是我们无法采取过

去常用的通过检修停机进行系统升级的方式来实现上述目标，因为世界各地诸多

业务都依赖着我们平台所提供的7x24小时的可用性。因此，我们需要构建一

个在引入新的软件构件时不会引起服务瘫痪的架构。Amazon杰出的工程

师MarvinTheimer有一次开玩笑说，AmazonS3这项服务的持续演进用开

飞机来形容最为贴切。我们最开始开的是一架单引擎的赛斯纳，一段时间后升级

成一架波音737，之后又换成了一支波音747小队，而现在更像是由空中巨无

霸空客A380组成的一支大型机队。自始至终，我们一边通过空中加油确保飞

机的正常飞行，一边在万米高空上将AWS的用户从一架旧飞机挪到另一架新

的上面去。同时，AWS的用户对此毫不知情。

2.预料到不可预料的情况故障是注定的；随着时间的流逝，一切终将归于

失败：从路由器到硬盘，从操作系统到存储单元损坏的TCP数据包，从瞬时误

差到永久失效，无论你用的是最高质量的硬件还是最低成本的组件，这都是理所

当然的。

在服务规模变得很大之后，这个问题愈加地凸显：举例来说，当Amazon

S3服务处理万亿级存储交易时，即使误差概率极小的事件也将成为现实。在设

计和构建阶段，这些故障场景中的一部分事先会被考虑到，但更多的则是未知数。

因此，我们需要构建的是将故障视为自然发生的系统，即使我们并不知道故障是

什么。这个系统应该要做到，即使在“后院已经着火”的情况下依然可以继续运

行。重要的是在不需要引起整个系统宕机的情况下就能管理好受影响的局部组

件。对此，我们已经发展出一套控制故障发生影响范围的基本技能，以期系统的

总体健康状态得以维持。

3.提供基元而非框架很快我们开始发现，用户大都喜欢在AWS提供的服

务上持续构建和演进自己的业务系统。在摆脱了传统IT硬件和数据中心的束缚

之后，他们开始以一种全新、有趣的、之前从未出现过的使用模式开发自己的系

统。也正是因为如此，为了满足用户多样的需求，我们的架构需要保持高度的灵

活性。

关于这一点，最重要的机制之一就是，我们提供给用户的是一系列基元和工具，

用户可以选择他们喜欢的方式来使用AWS云服务，而不是由我们提供一个大而

全的统一的框架。这个机制给我们的用户带来了巨大的成功，甚至AWS自身

后续的一些服务也用上了这套机制，就像我们的普通用户一样。

同样重要的一点是，我们很难在用户还没开始使用一个服务之前，就准确预知

到对用户而言该服务需要优先考虑的问题。这也是为什么所有的新服务最初都会

以最小的功能集发布，然后借助用户的反馈，