# 使用 Amazon 服务以 100 美元的价格构建无限可扩展的基础架构 > 原文： [http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html](http://highscalability.com/blog/2007/7/30/build-an-infinitely-scalable-infrastructure-for-100-using-am.html) 您是否真的可以使用亚马逊的存储，网格和排队服务平台以不到 100 美元的价格创建无限扩展的基础架构？ 看起来如此，至少对于正确的应用而言。 亚马逊将重点介绍了使用核心外部服务来构建下一代网站的“自带滚动式”与“按点连接”方法的未来之战。 他们的论点很强烈。 使用 Amazon 的平台，您可以快速构建基础架构，否则这些基础架构将需要花费很长的时间才能实现，要创造大量的资金，并且需要大量的人来实施和维护。 但是，亚马逊不提供 SLA，因此您可以将皇冠上的宝石与您真正信任吗？ Facebook 最近以一套更全面的服务超越了亚马逊的愿景。 未来的战斗正在进行中。 网站：http：//aws.amazon.com/ ## 信息来源 * [幻灯片：构建高度可扩展的 Web 应用程序](http://www.slideshare.net/iwmw/building-highly-scalable-web-applications)* [播客：技术：亚马逊网络服务](http://www.itconversations.com/shows/detail1728.html)* [亚马逊服务主页](http://aws.amazon.com/)。 ## 平台 * Amazon ECS（电子商务服务）* Amazon S3（简单存储服务）* Amazon SQS（简单排队服务）* Amazon EC2（网格服务）* 亚马逊网络搜索服务* 亚马逊弹性付款服务（Amazon FPS）* REST and SOAP Service Interfaces ## 里面有什么？ ### 为什么要使用外部服务？ * Amazon 的服务取代了应用程序堆栈中的盒子，电线和磁盘驱动器。* 亚马逊花了十年时间和超过 10 亿美元开发了世界一流的 Web 服务，每天都有数百万的客户使用。 也许您可以利用自己的网站体验？* 关注客户。 如果 Web 开发不是要提供客户价值，则为 70％。 这是关于建立和管理数据中心的。 您最好将精力花在客户身上，而不是浪费精力。* 更快上市。 缩放很难。 当您专注于增加用户价值时，让其他人担心 。* 针对峰值负载进行设计非常昂贵。 因此，将固定成本变成可变成本。 假设您要处理来自 slashdot 或 digg 的高流量，或者您有很高的季节性需求，那么拥有适当的基础结构来处理这些负载是一笔高固定成本。 您可以在其他地方更好地使用这笔钱。 创建一个可以自动和 临时扩展资源以应对高峰需求的基础架构是很有意义的。* 高可靠性和可用性。 专用服务可能比您可以创建的服务更可靠。 它说“可能”，因为亚马逊未提供 SLA，因此您将无法获得任何保证。 这个想法是，亚马逊足够便宜且可靠，因此很少有故障是可以接受的。 此外，SLA 通常会在出现问题时退还一些钱，它们 并不能真正保证任何事情。* 这是便宜的 CDN。 亚马逊的存储网络可以服务于相对便宜的内容交付网络。 在 [减少您的网站的带宽使用情况](http://www.codinghorror.com/blog/archives/000807.html)中讨论了此选项。 这个想法是，仅经常下载一个简单的 [favicon.ico](http://www.hanselman.com/blog/FavIconicoCanBeABandwidthHog.aspx) 文件就可以使用很大一部分带宽。 使用$ 3 /月的 S3 将 90％的带宽卸载到外部主机是一个不错的选择。 但是，没有 SLA 的 S3 不能被认为是正确的 CDN。 ### 亚马逊 ECS（电子商务服务） * 该服务公开了 Amazon 的产品数据和电子商务功能： 有关所有 Amazon.com 产品的详细产品信息，访问产品图像，与产品相关的所有客户评论等。* 亚马逊产品定价过高。* 我发现这项服务令人失望。 如果您想在 Amazon 之上建立商店，这似乎很棒，但是我没有找到将自己的产品添加到商店的方法，因此我认为它通常没有用。 ### Amazon S3（简单存储服务） * 该服务将数据存储在 Amazon 的存储网络中。* 每个 GPB 每月$ .15 的存储空间* $ .01（1000 至 10000 个请求）。* 每 GB 数据传输$ .10-$ .17。* 服务是：快速，可靠，可扩展，冗余，分散。* 您可以具有每个对象的 URL。 这意味着您可以直接使用 URL 引用图像或其他文件，因此可以在网页中使用。* 典型用途：CDN 和备份存储。* 存储分配到多个位置，因此您可以进行一定程度的地理分布。 ### Amazon SQS（简单排队服务） * 此服务提供用于存储消息的 Internet 规模排队服务。 分布式参与者将工作放在队列中，而将工作从队列中移出。* 每 1000 条邮件$ .10。* 每 GB 数据传输$ .10-$ .18。* 该服务是：可扩展，弹性，可靠，简单，安全。* 典型用途：集中式工作队列。 将作业放在队列中，不同的参与者可以弹出队列的工作并在获得 CPU 时间时对其进行处理。* 截至 2007 年，预期的邮件延迟为 2-10 秒。 这对于许多应用程序来说是可怕的，对于许多其他应用程序来说却并不坏。* 可扩展性的一部分。 有任何数量的生产者和消费者。 您不用担心。* Queues are spread across multiple machines and multiple data centers. ### Amazon EC2（网格服务） * 该服务可在云中提供可调整大小的计算能力。 它旨在使开发人员更容易进行 Web 规模的计算。* 基本上，您可以为 Linux 发行版创建 Xen 映像，然后将其上传到其“弹性计算云”中。 然后，您可以使用 API​​启动任意多个实例。* 典型用途：转码，音频工作，负载测试。* 对服务器的根级别访问以及对计算机的完全控制。* 可以按分钟放大和缩小。* 对于实时处理，一个批评是较慢的 CPU（1.75 Ghz Xeon）。 如果您的应用程序以线性比例编写，那么这可能不会成为问题。* EC2 实例不是持久性的，因此您无法在其中存储数据库。 您有一些本地存储，但是当实例消失时，它就会消失。* 启动和停止图像需要花费几分钟，因此并不是真正需要的图像。* You can add anything you want to an image. If you want a database you can add it in. ### GigaVox 媒体示例网络规模架构 * 您可以开始了解 Amazon 的服务如何协同工作。 假设您有大量的 MP2，希望将其转码为 MP3。 您将原始媒体存储到 S3 中，将工作请求放入 SQS 中，并使实例在 EC2 中运行以处理队列并执行转码，然后将结果存储回 S3 中。 这正是 GigaVox 所做的。* GigaVox 是一家播客公司。 -他们获取原始录音并将它们说出来的内容从 MP2 转换为 MP3。 还执行许多其他代码转换。 -然后，根据制作节目，将这些大块媒体组装在一起成为一种交付格式。 例如，旧的播客可以每晚更新最新的广告。 -大规模执行此操作将需要大量昂贵的资源。* 使用 Amazon 的服务，GigaVox 可以获得地理上的冗余和故障转移，从而获得相对便宜的 CPU，带宽和存储费用， 和带宽成本。 您没有盒子或电线。 无需管理数据中心。 而且您可以以较小的固定成本进行增长。* 消息在队列上带有时间戳。 如果消息在队列中等待的时间太长，则它们可以启动更多 EC2 映像。 您可以平衡成本。 您还可以在基于客户的优先级机制中分层。* 他们每个实例都有自己的消息队列，用于命令和控制。* 出于安全原因，他们通过 ftp 将文件上传到实例，而不是通过 S3。* 亚马逊云的所有带宽都是免费的。 这是使服务协同工作的重要业务考虑因素。* 另一组实例和队列负责组合交付的媒体。* 使 GigaVox 以较低的启动成本为客户提供价值。 ## 得到教训 * 建立或购买始终是一个艰难的决定。 如果某项服务无法正常工作，那么您可能会失去客户，并且您无能为力，其他人还会向其他人发送紧急电子邮件。 这是一种可怕的感觉。 但是，如果确实可行，那么您可能会领先于游戏。 如何选择？ 那会告诉:-) * 构建虚拟化层，以便您可以在其他提供商可用时切换到该提供商，或者可以用自己的服务替换它。 如果他们厌倦了提供服务或性能下降，这可以减少您对亚马逊的依赖。 * 作为一家使用 Amazon 服务的初创公司，这并不是什么大风险，因为您已经处于危险境地。 极低的启动成本可以缓解任何风险，而资金始终是初创企业的问题。 * 在许多情况下，购买自己的专用服务器可能仍然是更好的方法，因为您可以获得更多的控制权，更低的延迟，并且相同的硬件可用于多种用途。 * 软件即服务是一个强大而实用的想法。 它改变了您构建软件的方式。 它迫使您围绕界面对软件进行分层。 并且一旦您的软件由接口组成，您将拥有可以轻松更换的松散耦合的组件。 如果您想为客户提供 API，那么您还具有平台 API 的基础。 最高的开发水平将使用您提供给客户的相同 API 来构建服务。 * 松散耦合的，基于消息的体系结构与服务接口相结合，使您可以考虑抽象层的多个层次。 您不必费解，这使您可以释放使用大型行为块来构建应用程序的方式。 * 为异步交互界面设计 UI 带来了一些挑战。 可能需要一段时间才能执行操作，那么您如何与用户交互以进行处理呢？ * 我本能地怀疑亚马逊能否交付。 但是，如果您遇到的问题类型正确，则确实可以使用 Amazon 服务廉价地完成很多工作。 ## 也可以看看 * [Flickr](http://highscalability.com/flickr-architecture) 和 [YouTube](http://highscalability.com/youtube-architecture) 也处理服务级别 API。 * [在 Amazon EC2 和 Amazon S3 上运行 Hadoop MapReduce](http://developer.amazonwebservices.com/connect/entry.jspa?externalID=873&categoryID=112) 实用计算最终将成为现实且负担得起。 小公司可以使用 Amazon，Hadoop 和 Hbase 与巨头竞争吗？ 实际上，甚至 Yahoo 最近都宣布了对 Hadoop 的支持：<cite>“展望未来，并思考大规模计算的经济如何继续改善，不难想象，在 Hadoop 和基于 Hadoop 的基础架构如此普遍的时代 LAMP（Linux，Apache，MySQL，Perl / PHP / Python）堆栈有助于推动 Web 的先前发展。”</cite> 在此处阅读更多信息： [http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html](http://innowave.blogspot.com/2007/08/amazon-ec2-s3-hadoop-open-source.html) 没有“无限扩展”这样的东西。 完美的可伸缩性意味着，如果您将资源增加一倍，则无论从速度，容量还是所测量的任何方面，都将获得双倍的性能。 实际上，您拥有无限的资源并不能使您的应用程序无限扩展。 这只是意味着您可以忽略一些可伸缩性问题，例如收益递减。 “在 2006 年 4 月开始的将近 7 个小时中，Amazon 的 S3 存储服务只返回了服务不可用的消息。该事件在 2007 年 1 月再次发生，破坏了 Amazon 99.99％的正常运行时间目标。” （摘自 [http://flud.org/blog/2007/04/26/eradicating-service-outages-once-and-for-all/“](<a rel=) >彻底消除服务中断， 它还提出了一种用于*真正*可扩展和不受干扰的系统的替代架构。） 单独使用 Amazon 应用程序如何扩展 500GB MySQL 数据库？ 我知道这不一定是您在这里所说的，但是对于大多数 Web 应用程序而言，扩展意味着更多的 Web /应用程序服务器和更多的数据库功能。 我看到在 Amazon 上解决此问题的一种解决方案是每 10 分钟备份一次 MySQL 数据库。 这可能适用于 50mb 的数据库，但适用于 10GB 的数据库，更不用说 50-100GB 的数据库了？ 然后，当您的数据库集群出现故障时，您如何向您的用户解释说，您选择使用 Amazon“无限扩展”的最后几个小时丢失了价值数小时的数据？ 只是好奇-我会很乐意以某种方式解决这个问题。 这仍然是早期技术-仍然太丰富和太慢。 当平均带宽突破 10mb / s，而每次使用的价格又下降了一个数量级时，我们将面临一场真正的革命。 在此之前，这些服务的市场有限。 本地存储是您要查找的选项，现已可用（截至本周）。 然后，您可以将本地副本备份到 s3。 请记住，您不会为每个备份存储 10GB，而是存储更改增量，因此，实际上增量比您表示的要多得多。 您可以构建按地理位置分布的多集群环境，并且构建涉及轮循（m / m / m-环形拓扑）或 m / s / s 甚至 m / m（ m / s / s 和 m / s / su 形拓扑）。 这些技术还处于起步阶段。 由于缺乏云故障转移，目前唯一不可能的情况是服务故障。 在 Amazon 的情况下，使 SOAP 服务终止并不意味着您的服务（必定）终止，而是意味着您无法按需扩展等，并且您不能进行更改，直到 SOAP 服务恢复为止。 由于 s3 复制，目前针对 Amazon 的现有解决方案可能内置 20-40 秒的延迟（s3 的性能可能会有所不同），但是本地存储可以在本地磁盘上排队，然后从那里进行备份 ，减少问题的影响（即使服务崩溃，本地存储也将保持不变）。 希望能有所帮助。 它可以进行架构设计，而这个问题不再是秀场停止。 很明显，您不是财务专家。 当您超越“带宽/存储”比较，进入云计算的总运营成本时，我的分析一直显示高性能站点的总体成本降低了 5-7 倍（这是 Sun Microsystems VS Amazon 上的 A / B ，而且我相信 Sun 是最有效的解决方案，因为它们具有很高的 CPU 密度），而在最坏的情况下，我看到的是 2 比 1 的降低。 第二个问题不受个人开发人员的考虑，但是对于使用基础结构的公司来说，它的主要问题是调配的速度。 云将应用程序的配置从数天，数周或数月转移到数小时，数分钟和数秒。 而且，从本质上讲，它们将为 SaaS 和其他企业技术提供复杂的应用程序（由于成本优势，所谓的“企业云”将兴起）。 IBM，VMWare，XEN，Microsoft，Google 和 Amazon 知道它还没有为“ Enterprise”做好准备，但是它很快就会成熟。 考虑 Forrester 报告（ [http://tinyurl.com/6s5qyc）](http://tinyurl.com/6s5qyc),)，其中显示： 云计算是否已为企业准备就绪？ “还没有，但是这种破坏性的创新正在迅速成熟” 技术的成熟度是一个问题（安全性，可用性等），但是它将得到解决。 并期待*内部*云计算的兴起，这将改变竞争环境，价格将不可避免地下降，随着解决方案的成熟，对价格敏感度较低且有很多意料之外的麻烦的客户将进入市场。