AWS(Amazon Web Service) 开始于 2006 年 3 月 14 日 Amazon S3 的发布，距今已有十年时间。回首过去十年，我们在构建和运营 AWS 云计算服务中积累了大量的经验教训——这些服务不仅需要确保安全性、可用性和可扩展性，同时还要以尽可能低廉的成本提供可预测的性能。考虑到 AWS 是世界范围内构建和运营此类服务的开拓者，这些经验教训对我们的业务来说至关重要。正如我们多次重申的，“经验不存在压缩算法”。考虑到 AWS拥有每月超过一百万的活跃用户，而这些用户也许会为数以亿计的自家客户提供服务。因此，积累上述经验教训的机会在 AWS 比比皆是， 在这些经验教训中，我挑选了一些分享给大家，希望对各位也能有所帮助。

　　1.构建可持续演进的系统

　　从做 AWS 的第一天开始，我们就清楚地认识到，我们在做的这套软件不是一劳永逸的。现在可以用的软件，一年之后很可能将不再适用。我们的预期是，随着(用户)数量级的增加一或两次，我们都需要重新检视和适当修改我们已有的架构，以便解决扩展性的问题。

　　但是我们无法采取过去常用的通过检修停机进行系统升级的方式来实现上述目标，因为世界各地诸多业务都依赖着我们平台所提供的7 x 24 小时的可用性。因此，我们需要构建一个在引入新的软件构件时不会引起服务瘫痪的架构。Amazon 杰出的工程师 Marvin Theimer 有一次开玩笑说，Amazon S3 这项服务的持续演进用开飞机来形容最为贴切。我们最开始开的是一架单引擎的赛斯纳，一段时间后升级成一架波音 737，之后又换成了一支波音 747 小队，而现在更像是由空中巨无霸空客 A380 组成的一支大型机队。自始至终，我们一边通过空中加油确保飞机的正常飞行，一边在万米高空上将 AWS 的用户从一架旧飞机挪到另一架新的上面去。同时，AWS 的用户对此毫不知情。

　　2. 预料到不可预料的情况

　　故障是注定的;随着时间的流逝，一切终将归于失败：从路由器到硬盘，从操作系统到存储单元损坏的TCP数据包，从瞬时误差到永久失效，无论你用的是最高质量的硬件还是最低成本的组件，这都是理所当然的。

　　在服务规模变得很大之后，这个问题愈加地凸显：举例来说，当Amazon S3 服务处理万亿级存储交易时，即使误差概率极小的事件也将成为现实。在设计和构建阶段，这些故障场景中的一部分事先会被考虑到，但更多的则是未知数。

　　因此，我们需要构建的是将故障视为自然发生的系统，即使我们并不知道故障是什么。这个系统应该要做到，即使在“后院已经着火”的情况下依然可以继续运行。重要的是在不需要引起整个系统宕机的情况下就能管理好受影响的局部组件。对此，我们已经发展出一套控制故障发生影响范围的基本技能，以期系统的总体健康状态得以维持。

　　3. 提供基元而非框架

　　很快我们开始发现，用户大都喜欢在 AWS 提供的服务上持续构建和演进自己的业务系统。在摆脱了传统 IT 硬件和数据中心的束缚之后，他们开始以一种全新、有趣的、之前从未出现过的使用模式开发自己的系统。也正是因为如此，为了满足用户多样的需求，我们的架构需要保持高度的灵活性。

　　关于这一点，最重要的机制之一就是，我们提供给用户的是一系列基元和工具，用户可以选择他们喜欢的方式来使用AWS云服务，而不是由我们提供一个大而全的统一的框架。这个机制给我们的用户带来了巨大的成功，甚至 AWS 自身后续的一些服务也用上了这套机制，就像我们的普通用户一样。

　　同样重要的一点是，我们很难在用户还没开始使用一个服务之前，就准确预知到对用户而言该服务需要优先考虑的问题。这也是为什么所有的新服务最初都会以最小的功能集发布，然后借助用户的反馈，再对该服务进行后续的扩展。

　　4. 自动化是关键

　　开发一个需要持续维护的软件服务和开发一个最终交付给客户的软件有着巨大的差异，管理一个像 AWS 这种规模的系统，需要一种完全不同的观念，才能确保满足用户对可用性、性能以及可扩展性的要求。

　　实现这个目标的一个主要的机制，就是避免容易产生误差的手工操作，尽可能地将管理工作自动化。为此，我们需要构建一套可以控制主要功能的管理 API。在这方面，我们同时也对自己的用户给予帮助。通过将应用分解成一个个独立的模块，每个模块都有自己的管理 API，你可以很方便地定义自动化规则来进行大规模的维护。判断自动化做的是不是到位，可以思考一下你是不是还需要使用SSH登陆到某台服务器进行运维操作?如果答案是 yes，说明你的自动化做得还不够好。

　　5. API 定义要严谨，因为一旦上线就无法更改

　　我们在 Amazon 零售项目中已经接受过类似的教训，但对于 AWS 这种以 API 为中心的服务，这个原则变得更加重要。一旦用户开始用我们的 API 开发他们的应用和系统，我们就不可能再对这些 API 进行变更了。因为 API 的任何改动都会影响到用户已有的项目。因此我们充分意识到，在 API 给到用户之前，我们只有一次将 API 做对的机会。