Amazon CTO：我在打造AWS的10年里学到的10条经验

Amazon CTO：我在打造AWS的10年里学到的10条经验（转）

 

Amazon 的 CEO Jeff Bezos 前几天在致股东的信中表示 ，亚马逊云服务 AWS 目前已经有超过 100 万的用户，2016年 的营收也将突破 100 亿美元。Amazon 的 AWS 服务是在 2006年3月 推出，距今已有整整 10年 的时间了。AWS 最早推出的云服务是简单储存服务 Simple Storage Service (S3)，后来又陆续推出了 Amazon 弹性计算网云 Elastic Compute Cloud （EC2）、亚马逊简单数据库（Amazon SimpleDB）、亚马逊简单队列服务（Amazon Simple Queue Service）以及 Amazon CloudFront 等云服务。目前，成千上万的创业公司在 AWS 的数据中心和服务基础上构建了自己的在线业务。不仅大量小公司依赖于 Amazon AWS 的云计算服务，很多诸如 Adobe、GE、Netflix 和 Pinterest 这样的大公司也都在使用 Amazon 的 AWS 服务。

 

在 Amazon 的 AWS 服务上线 10 周年之际，推动 AWS 服务发展的核心人物、Amazon 的 CTO Werner Vogels 在本文中专门总结和分享了他在 AWS 上线运营 10年 过程中的学到的 10 条经验，希望对大家有所启发和借鉴。

 

1. 从第一天开始，就要打造一个可以持续演化的系统

 

从第一天开始，我们就非常清楚地认识到，我们所开发的这套软件是一个一定需要持续改进的软件，现在开发的软件可能并不是一年以后运行的软件。我们当时是这样预期的，随着数量级的增加，我们就需要去重新检视和修改我们已有的架构，确保能够解决扩展性的问题。

 

然而，由于全世界不同地方的很多公司都依赖着我们平台所提供的 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。此外，AWS 也能够帮助用户同样实现这个目标。通过把你的应用分解成一个个基本的构建模块，每个模块都有自己的管理 API，这样你就可以利用自动化规则进行大规模可靠、可预测的的运营。自动化工作究竟做得如何，有个很简单的检验方法就是看你是不是还需要 SSH 登陆到服务器进行操作，如果需要的话，说明你的自动化的工作还有待加强。

 

5. API 是永恒的，一旦上线便无法变更

 

其实之前在 Amazon 零售业务中已经吸取了类似的经验和教训了。然而对于 AWS 这种以 API 为中心的服务而言，“API 是永恒的” 这个原则显然就变得更为重要了。一旦用户开始使用我们的 API 开发他们的应用和系统后，我们就不可能再去对那些这些 API 做任何变动了，因为变动 API 会严重影响到用户的业务。我们已经意识到，设计 API 是一个非常重要的任务，必须要一次性成功。

 

6. 关注和了解自己的资源使用情况

 

在你为一项服务制定合适的计费模式的时候，一定要确保你有一份关于这项服务的各项成本和运营费用的详细数据，当你运营一个业务量大、利润率低的业务时更需要如此。AWS 作为一个服务提供商，我们必须对服务成本非常了如指掌，这样我们就能清楚地了解基于这一成本，我们是否能够承担得起为用户提供这项服务。此外，我们还可以借此找到那些可以通过提高运营效率而降低成本的一些方法，并通过这种方法进一步降低服务价格，从而让用户从中受益。

 

举例说明一下，在我们发展早期，我们一开始对 Amazon S3 服务所需要的资源成本其实并不是非常清楚。我们当时是这样设想的，存储和宽带成本是我们首先需要考虑的收费点。不过后来在 Amazon S3 运行了一段时间之后我们开始意识到，请求数量其实和存储与带宽是一样重要的。如果有用户有大量的小文件，在这种情况下，即使这个用户请求上百万次，其实都不会占用太多的存储和带宽资源，占最多资源的其实是请求数量。因此我们必须对收费模型进行调整，将请求数量也放进了资源成本中去，这样才能确保 AWS 有一个可以持续发展的业务。

 

7. 从一开始就要将安全问题考虑进去

 

保护用户的安全是一个你永远都要排在第一位的优先级问题，在 AWS 当然也是这样，这无论从运营的角度来看，还是从工具和机制的角度来看都是如此。因此，我们在安全方面的投入将一直是我们的第一大投入。

 

我们很快就学会的一个方法是，为了打造更加安全的服务，这就要求我们在服务设计的最初阶段就将安全问题考虑进去。安全团队的工作不是在一项服务开发完成之后再去检查验证它的安全性问题到底如何。安全团队应该在开发工作开始后的第一天就参与到产品开发中去，确保安全问题在刚开始开发时就被考虑进去，而且贯穿于整个项目的开发的全过程。在任何涉及安全的问题时，你都不能做任何妥协。

 

8. 数据加密太重要

 

数据加密是让用户确保他们对谁能获取自己的数据拥有绝对控制权的一个关键机制。在 10年 以前，用于数据加密的相关的工具和服务的使用体验非常差，直到 AWS 开始运营后的最初几年里，我们慢慢知道了如何最好地将数据加密功能整合进我们的服务里。

 

Amazon S3 最初提供的是服务器端的加密。如果你想检查我们数据中心的任何磁盘，你是无法访问到任何数据的。后来，我们陆续推出了 Amazon CloudHSM 和 Amazon Key Management Service，这些服务允许用户利用自己的加密秘钥对数据进行加密，这样就不需要 AWS 再去帮助用户去管理他们的加密密钥了。

 

如今，在 AWS 所有新推出的服务中，对数据加密的支持已经在服务的原型设计阶段就被整合进去了。例如在 Amazon Redshift 这项服务里，每一个数据模块都是通过一个随机的密钥进行加密的，而所有这些随机密钥最后又都是由一个主密钥进行加密的。用户是可以自己自主定义这个主密钥的，这样就保证了用户自己是唯一能够加密和访问这些关键业务数据或个人隐私信息的人。

 

数据加密在我们的业务中一直都是一个优先级比较高的工作。我们会持续不断地对数据加密改进，让数据加密能够更方便地使用，这样用户能更好地保护自己和自己的客户。

 

9. 网络的重要性

 

AWS 业务已经支撑了很多不同种类的负载，从大容量事务处理到大规模视频转码，从高性能并行计算到巨大的网站流量等等，所有这些负载对网络都有非常独特的需求。

 

在数据中心布局和运维的创新方面，AWS 已经开发出了一种独特的新技术，这让我们能够提供更加灵活的网络基础设施去满足不同用户的不同负载的需求。我们在这个过程总学习到，为了能够让用户实现自身的目标，我们必须开发自己的网络硬件解决方案。这也让我们能够满足我们一些定制化的需求，例如，为了确保最高等级的安全性，我们可以在网络上将不同的用户彼此隔离开来。

 

另一个 AWS 通过自己设计的网络硬件和软件解决方案去进一步帮助用户改善性能的例子就是解决虚拟机之间的网络访问。因为网络访问是一个共享的资源，用户之前经常会遇到网路拥堵的问题。AWS 后来开发了能够支持单根 IO 虚拟化技术的 NIC，它能够让我们给每个虚拟机虚拟出自己的 NIC，这个做法有效降低了网络延迟两倍以上。

 

10. 不设守门人

 

为了给用户提供一个更加广阔和深度的服务平台，AWS 团队陆续开发和提供了越来越多的服务和功能。不过 AWS 远不限于我们目前已经提供过的这些功能和服务，我们的很多合作伙伴基于 AWS 提供的服务进一步扩大和丰富了整个 AWS 生态系统。

 

比如，我们的合作伙伴 Stripe 利用我们的服务提供的支付服务，以及 Twilio 利用 AWS 服务提供的网络电话业务等。我们的很多用户基于 AWS 服务开发出自己的平台，以解决各自垂直领域的一些问题。例如飞利浦开发了用于健康数据管理的数字平台 Healthsuite Digital Platform，Ohpen 在 AWS 基础上开发了一个零售银行平台，Eagle Genomics 开发了基因处理平台，这样的例子还有很多。

 

在 AWS 平台上，我们是不设守门人（gatekeeper）的，因此我们不会告诉我们的合作伙伴他们在 AWS 平台上什么可以做、什么不可以做。“没有守门人” 这一点能够激发更多、更好地创新。

 

本文编译自：http://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html ，如若转载，请注明出处：http://36kr.com/p/5045714.html