十年经验积累 AWS CTO十条云经验分享

　　【 云计算】 2006 年 3 月 AWS Amazon S3 正式发布，回首过去，至今已过十年。作为Amazon AWS的CTO，沃纳·威格尔(Werner Vogels) 一直是行业内最受关注的技术导师。近期他发表了个人博客，在博客中，他根据个人经历与十年AWS运营体会，总结了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 做对的机会。

　　6. 监控你的资源使用情况

　　当你为一项服务确定计费模式的时候，请务必确保你有一份关于该服务的资源成本和运营的数据。对于边际成本很低的业务尤其如此。作为服务提供 商，AWS 需要对服务成本保持足够的敏感，以便我们能清楚地认识到我们是否承担得起某项服务，同时也能够定位到一些可以通过提高运营效率而进一步降低成本的地方，并借此降低服务价格，最终惠及用户。

　　举一个例子，早期的时候，我们对于 Amazon S3 服务所用到的资源成本并不是很清晰。我们当时假定，存储和带宽应该是我们首要考虑的收费点;后来运行了一段时间之后，我们才意识到，请求数量跟存储与带宽同 等重要。如果某个用户有大量的小文件要存储，这种情况下，即使是百万量级的请求，都不会占用太多的存储和带宽资源。最终我们做了调整，将请求数量也纳入了计费模型，以便 AWS 在收支上可以保证这项服务的可持续性。

　　7. 从头开始建立安全机制

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!