# 亚马逊建筑 > 原文： [http://highscalability.com/blog/2007/9/18/amazon-architecture.html](http://highscalability.com/blog/2007/9/18/amazon-architecture.html) *这是基于乔亚希姆·罗德（Joachim Rohde）对亚马逊 CTO 采访的发现而提供的非常有用的亚马逊更新。 您将了解 Amazon 如何围绕服务组织团队，构建可扩展系统的 CAP 定理，他们如何部署软件等等。 还包括了“ ACM 队列”文章中的许多新功能。* 亚马逊从一个很小的在线书店发展成为地球上最大的商店之一。 他们做到了这一点，同时开创了对产品进行评分，评论和推荐的有趣新方法。 格雷格·林登（Greg Linden）在一系列博客文章中分享的是 Amazon 的出生困境 网站：http：//amazon.com ## 信息来源 * [早期亚马逊作家，格雷格·林登](http://glinden.blogspot.com/2006/05/early-amazon-end.html)* [Linux 如何为 Amazon 节省了数百万美元](http://news.com.com/2100-1001-275155.html)* [专访 Werner Vogels](http://www.se-radio.net/index.php?post_id=157593) -亚马逊的 CTO* 异步体系结构-Chris Loosley 的 Werner Vogels 演讲的精彩[摘要](http://www.webperformancematters.com/journal/2007/8/21/asynchronous-architectures-4.html)* [向亚马逊技术平台学习](http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=388)-与 Werner Vogels 的对话* [Werner Vogels 的 Weblog](http://www.allthingsdistributed.com) -构建可扩展且强大的分布式系统 ## 平台 * 的 Linux* 甲骨文* C ++* 佩尔* 石匠* 爪哇* 博斯* Servlets ## 统计资料 * 超过 5500 万活跃客户帐户。* 全球超过 100 万活跃零售合作伙伴。* 访问 100-150 之间的服务以构建页面。 ## 架构 * 我们对可伸缩性的真正含义是什么？ 如果我们在系统中增加资源时以与添加资源成比例的方式提高性能，则该服务被称为可伸缩的。 通常，提高性能意味着要服务更多的工作单元，但是也可以处理更大的工作单元，例如数据集增长时。 * 亚马逊所做的重大体系结构更改是从两层的整体架构转变为可服务于许多不同应用程序的完全分布式，去中心化的服务平台。* 作为一个与后端通信的应用程序启动。 用 C ++编写。* 它成长了。 多年来，亚马逊的扩展工作一直致力于使后端数据库进行扩展，以容纳更多物品，更多客户，更多订单并支持多个国际站点。 在 2001 年，很明显前端应用程序无法再扩展。 数据库被分成几个小部分，并围绕每个部分创建了一个服务接口，这是访问数据的唯一方法。* 数据库成为共享资源，这使得很难扩展整个业务。 前端和后端流程的发展受到限制，因为它们被许多不同的团队和流程共享。* 它们的体系结构是松散耦合的，并围绕服务构建。 面向服务的体系结构为他们提供了隔离，使他们可以快速，独立地构建许多软件组件。* 聚集了数百个服务和大量应用程序服务器，这些服务服务器汇总了来自服务的信息。 呈现 Amazon.com 网页的应用程序就是这样一种应用程序服务器。 服务 Web 服务接口的应用程序，客户服务应用程序和卖方接口也是如此。* 许多第三方技术很难扩展到亚马逊的规模。 特别是通讯基础设施技术。 它们会在一定规模下正常工作，然后失败。 因此，他们被迫建立自己的。* 不拘泥于一种特定的方法。 在某些地方，他们使用 jboss / java，但仅使用 servlet，而不使用 J2EE 堆栈的其余部分。* C ++用于处理请求。 Perl / Mason 用于构建内容。* 亚马逊不喜欢中间件，因为中间件往往是框架而不是工具。 如果您使用中间件软件包，则会锁定他们选择的软件模式。 您将只能使用他们的软件。 因此，如果您想使用其他软件包，则将无法使用。 你被困住了。 一个事件循环，用于消息传递，数据持久性， AJAX 等。太复杂了。 如果中间件可以在较小的组件中使用，而更多的是作为工具而不是框架使用，那么他们会更感兴趣。* SOAP Web 堆栈似乎想再次解决所有相同的分布式系统问题。* 同时提供 SOAP 和 REST Web 服务。 30％使用 SOAP。 这些通常是 Java 和.NET 用户，并使用 WSDL 文件生成远程对象接口。 70％的人使用 REST。 这些往往是 PHP 或 PERL 用户。* 在 SOAP 或 REST 中，开发人员都可以获取到 Amazon 的对象接口。 开发人员只想完成工作。 他们不在乎导线上的内容。* 亚马逊希望围绕他们的服务建立一个开放的社区。 选择 Web 服务是因为它很简单。 但是帽子只在外围。 在内部，它是一种面向服务的体系结构。 您只能通过界面访问数据。 WSDL 中对此进行了描述，但是它们使用了自己的封装和传输机制。* 团队很小，并且围绕服务 进行组织-服务是在 Amazon 内部提供功能的独立单位。 这也是亚马逊在团队内部进行组织的方式。 -如果您有一个新的业务构想或问题，您想组成一个团队来解决。 由于沟通困难，团队人数不得超过 8-10 人。 他们被称为两个披萨队。 您可以养活两个比萨饼的人数。 -团队很小。 他们被授予权限并有权以他们认为合适的方式解决问题，即服务。 -例如，他们创建了一个小组，以在书中查找文本唯一的短语。 该团队为此功能构建了一个单独的服务接口，他们有权执行所需的操作。 -广泛的 A / B 测试用于集成新服务。 他们看到了影响并进行了广泛的测量。* 部署 -他们创建用于管理依赖关系和进行部署的特殊基础结构。 -目标是将所有合适的服务部署在一个盒子上。 所有应用程序代码，监视，许可等都应放在包装盒中。 -每个人都有一个解决这些问题的本地系统。 -部署过程的输出是虚拟机。 您可以使用 EC2 来运行它们。* 从客户后方进行工作以验证是否值得进行一项新服务 -从客户后方进行工作。 专注于您想要为客户交付 的价值。 -迫使开发人员专注于交付给客户的价值，而不是先构建技术然后再去思考如何使用它。 -从新闻稿开始，介绍用户将看到的功能并向后工作以检查您是否正在构建有价值的东西。 -最终以尽可能最小的设计完成。 如果您确实要构建大型分布式系统，那么简单是关键。* 状态管理是大规模系统 的核心问题-内部，它们可以提供无限的存储空间。 -并不是所有的操作都是有状态的。 结帐步骤是有状态的。 -最近点击的网页服务具有基于会话 ID 的建议。 -无论如何，他们都会跟踪所有事情，因此保持状态无关紧要。 会话几乎不需要保留单独的状态。 服务将已经保留了信息，因此您只需要使用服务即可。* Eric Brewer 的 CAP 定理或系统的三个属性 -系统的三个属性：一致性，可用性，对网络分区的容忍度。 -对于任何共享数据系统，这三个属性中最多可以有两个。 -可分区性：将节点分为几个小组，可以看到其他小组，但看不到所有人。 -一致性：写入一个值，然后读取该值，您将获得相同的值。 在分区系统中，存在不正确的窗口。 -可用性：可能并不总是能够写入或读取。 系统会说您不能写，因为它想保持系统的一致性。 -要扩展，您必须进行分区，因此您只能为特定系统选择高一致性或高可用性。 您必须找到可用性和一致性的正确重叠。 -根据服务需求选择特定的方法。 -对于结帐流程，您始终希望兑现将商品添加到购物车的请求，因为它可以产生收益。 在这种情况下，您选择高可用性。 对客户隐藏错误，并在以后进行分类。 -当客户提交订单时，您希望保持一致性，因为多项服务（信用卡处理，运输和处理，报告）正在同时访问数据。 ## 得到教训 * 您必须改变思路，才能构建真正可扩展的系统。 以概率的方式处理混乱，事情会顺利进行。 在传统系统中，我们提供了一个完美的世界，在这个完美的世界上一切都没有失败，然后我们在这个完美的世界上构建了复杂的算法（协议技术）。 相反，将其视为理所当然的东西会失败，这是 现实，请接受它。 例如，使用快速重启和快速恢复方法进行更多操作。 随着数据和服务的良好传播，您可能会接近 100％。 创建自我修复，自我组织的熄灯操作。 * 创建一个没有共享的基础架构。 基础架构可以成为开发和部署的共享资源，其缺点与逻辑层和数据层中的共享资源相同。 它可能导致锁定和阻塞以及死锁。 面向服务的体系结构允许创建并行且隔离的开发流程，以扩展功能开发以适应您的增长。 * 使用 API​​打开系统，您将在应用程序周围创建一个生态系统。 * 管理大型分布式系统的唯一方法是使事情尽可能简单。 通过确保设计中没有隐藏的需求和隐藏的依赖关系，使事情变得简单。 将技术减少到解决您所遇到的问题所需的最低限度。 这无助于公司创建人为的和不必要的复杂性层。 * 围绕服务进行组织可提供敏捷性。 您可以并行执行的操作是因为输出是服务。 这样可以加快上市时间。 创建一个基础结构，以允许快速构建服务。 * 在实际实现之前，任何会引起炒作的问题都存在问题 * 在内部使用 SLA 来管理服务。 * 任何人都可以非常快速地将 Web 服务添加到其产品中。 只需将产品的一部分作为服务实施并开始使用即可。 * 出于性能，可靠性和成本控制的原因，构建自己的基础架构。 通过自己构建它，您不必说您倒闭，因为这是 X 公司的错。 您的软件可能不比其他软件更可靠，但是与第三者合作时，您可以更快地进行修复，调试和部署。 * 用度量和客观辩论将好与坏分开。 我去过前亚马逊的几场演讲，而这正是亚马逊给我的印象，与其他公司截然不同。 他们根深蒂固的道德操守是让真正的客户有选择的余地，看看哪个最有效，并根据这些测试做出决策。 [Avinash Kaushik](http://highscalability.com/blog-occam-s-razor-avinash-kaushik) 称这摆脱了 HiPPO（房间中收入最高的人）的影响。 这是通过 A / B 测试和 Web Analytics 等技术完成的。 如果您对应该如何编写代码有疑问，请让人们使用它，然后看看哪种选择可以为您提供所需的结果。 * 营造节俭文化。 例如，亚马逊使用书桌门。 * 知道你需要什么。 亚马逊在一个早期的推荐系统上经历了糟糕的经历，但并没有奏效：“这不是亚马逊所需要的。在亚马逊上进行书推荐需要使用稀疏数据，只需进行几次评级或购买即可。它必须要快。 该系统需要扩展到大量的客户和庞大的目录，还需要增强发现能力，使目录中深处的书籍无法被读者自己找到。” * 人们感兴趣的旁人项目通常是您获得最大价值和创新的项目。 永远不要低估您最感兴趣的地方徘徊的力量。 * 让每个人都参与制作狗粮。 在圣诞节高峰期间，请进仓库并整理书籍。 那是团队合作。 * 创建一个登台站点，在发布到野外之前，您可以在其中进行全面的测试。 * 一个健壮的，集群的，复制的，分布式文件系统非常适合 Web 服务器使用的只读数据。 * 如果更新不起作用，有一种方法可以回滚。 如有必要，编写工具。 * 切换到基于深度服务的体系结构（http://webservices.sys-con.com/read/262024.htm）。 * 在面试中寻找三件事：热情，创造力，能力。 对 Amazon.com 成功的最大预测是热情。 * 雇用鲍勃。 知道他们的东西，拥有令人难以置信的调试技能和系统知识的人，最重要的是，他们拥有一头石头就能解决仅凭跳进就可以想象到的最严重的高压问题。* 创新只能来自底层。 那些最接近问题的人最有可能解决问题。 任何依赖创新的组织都必须拥抱混乱。 忠诚和服从不是您的工具。 * 创意必须无处不在。 * 每个人都必须能够进行实验，学习和迭代。 职位，服从和传统不应该拥有任何权力。 为了使创新蓬勃发展，必须衡量。 * 拥抱创新。 在整个公司的面前，杰夫·贝佐斯（Jeff Bezos）会将一双耐克旧鞋授予“勇于创新”的人，以表彰他们的创新精神。 * 不要为性能付出代价。 给予良好的待遇和高薪，但保持平稳。 以其他方式认可出色的工作。 绩效工资听起来不错，但是在大型组织中几乎不可能做到。 使用非金钱奖励，例如旧鞋子。 这是说谢谢的方式，有人在乎。 * 快速变大。 像巴恩斯（Barnes）和诺贝尔（Nobel）这样的大人物在你的尾巴上。 亚马逊甚至不是网络上的第一，第二，甚至第三本书店，但最终他们的愿景和驱动力胜出了。 * 在数据中心，只有 30％的员工时间花费在与价值创造相关的基础架构问题上，其余 70％专门用于应对硬件采购，软件管理，负载平衡，维护，可扩展性挑战以及 以此类推。 * 禁止客户端直接访问数据库。 这意味着您可以在不涉及客户的情况下扩大服务范围并提高可靠性。 这很像 Google 能够独立地在其堆栈中分发改进以使所有应用程序受益的能力。 * 创建一个统一的服务访问机制。 这使得服务易于聚合，分散请求路由，分布式请求跟踪以及其他高级基础结构技术。 * 通过 Web 服务接口向世界上任何开发人员免费提供 Amazon.com 也是一项重大成功，因为它推动了许多创新，他们无法想到或自己建立。 * 开发人员自己最清楚哪些工具使它们最高效，哪些工具最适合工作。 * 不要对工程师施加太多限制。 为某些事情提供激励，例如与监视系统和其他基础结构工具集成。 但对于其余部分，允许团队尽可能独立地运作。 * 开发人员就像艺术家。 只要有自由，他们就可以发挥出自己最好的作品，但是他们需要好的工具。 有许多具有自助性质的支持工具。 为服务开发周围的环境提供支持，而该环境永远不会妨碍开发本身。 * 您构建它，然后运行它。 这使开发人员可以接触到他们软件的日常操作。 它还使他们与客户进行日常联系。 客户反馈回路对于提高服务质量至关重要。 * 开发人员应每两年花一些时间在客户服务上。 他们实际上将收听客户服务电话，接听客户服务电子邮件，并真正了解他们作为技术人员所做的各种事情的影响。 * 使用“客户的声音”，这是客户关于您网站体验的某些特定部分的真实故事。 这可以帮助经理和工程师了解我们为实际人员构建这些技术的事实。 如果您做错了什么或对客户而言真正的痛点是什么，则客户服务统计数据可以作为早期指示。 * 像 Google 一样，Amazon 的基础设施具有巨大的竞争优势。 他们可以利用相对简单的原始服务来构建非常复杂的应用程序。 他们可以独立扩展业务规模，保持无与伦比的系统可用性，并快速引入新服务，而无需进行大量重新配置。 亚马逊的首席技术官沃纳·沃格斯（Werner Vogels）谈到了 SE-Radio 的技术细节。 您可以在[下找到播客，网址为 http://www.se-radio.net/index.php?post_id=157593](http://www.se-radio.net/index.php?post_id=157593) 有趣的一集。 那是一次很好的采访。 谢谢。 我将尽快添加新信息。 亚马逊使用 Perl 和 Mason。 请参阅： [http://www.masonhq.com/?MasonPoweredSites](http://www.masonhq.com/?MasonPoweredSites) 如我所见，他们减少了 c ++部分并转移到 j2ee？ 除非您是经理，否则我不确定您怎么能弄错那个错误，但是即使那样，某些工程师还是会在星期日之前教您。 感谢您抓住这一点。 我听了几次，有时我只是写我听到的内容，而不是我的意思。 我实际上在以下位置给出了可扩展性的详细定义： [http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html“](<a rel=) >有关可扩展性的信息 我个人喜欢 [http://www.acmqueue.com/modules.php?name=内容& pa =显示页& pid = 388“](<a rel=) > ACM Queue 中的采访最适合 高层视野 -维尔纳 似乎他们使用 Java 来完成通常用 Perl 完成的工作。 >使用非货币奖励，例如旧鞋。 这是 >说谢谢的一种方式，有人在乎。 有一次我愚蠢到参加亚马逊全公司会议，而不是将其视为免费的入睡日，我看到贝索斯给了一个男人一双鞋子。 我当时想：“这个家伙造了宇宙飞船，他把臭旧的网球鞋给高成就者？他们不喜欢打他吗？自尊心在哪里？” 但是我想这就是为什么我是前亚马逊人的原因。 当我放弃他们时，薪水提高了 20％，而且没有传呼机职责。 见，杰夫。 这是我一段时间以来最愚蠢的读物之一。 一家聪明的公司为什么会花钱在员工的“奖励”上，这对除了您从中获得奖励的人以外的任何人都没有帮助？ 当亚马逊表现出色时，他们就会获得真正的高成就，而且股价在 90 美元左右，我知道他们的感觉还不错。 我的猜测是他们想拥抱杰夫。 成就不佳的人很可能会对此表示不满，然后去其他地方，他们在亚马逊工作的事实很可能有助于这项工作，就像我确定的那样。 而且，看来您离开并没有对亚马逊造成太大的伤害:) 以前的 Nikies 面向成就卓越的人的事情听起来像是给 IBM 员工的（愚蠢的）文凭。如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金，或者..不愿意参加巡航。 便秘的旧鞋子..多么可爱:)） >而且，看来您离开并未对亚马逊造成太大的伤害:) 哦，我敢肯定，没有我，amzn 很好。 但是亚马逊员工的半衰期约为 18 个月，所以认为在那工作很糟糕的不只是我。 想一想，如果不必每 18 个月更换一半的员工，amzn 的运营效率就会提高多少。 我确信这将对其股价产生影响。 :) >如果公司 >表现不错，并且股票价格在 90 美元左右，亚马逊的真正成就就会得到回报，我知道他们对 >感觉很好。 我的猜测是他们想拥抱杰夫。 当然，现在股价飞涨，我为那里的人感到高兴，他们为此赚了很多钱。 但是 amzn 按照市场标准支付工资，并依靠股票来提高工资。 我对你的薪水赌博并不酷。 算上我过去几年的全部收入...如果我的所有 amzn 赠款都以每笔$ 90 支付，如果我呆在那里，我可能会多赚$ 15-25K。 但是，2.5 万美元的保费（或每年 625 万美元，因为需要花费 4 年的归属时间）并不足以让我进入亚马逊，考虑到要换取这笔保费，我需要工作 10- 每周多 30 小时。 我认为基于权益的补偿是针对傻瓜的。 用权益补偿来换取巨大的每周工作量需求是……更大的吸盘。 我目前的公司为我提供了真正的现金红利和额外的带薪休假，以使他们表现良好。 我要把它接在笨拙的旧鞋子上！ 钱用来说话； 像 bulsh * t 这样的鞋子，是用来走路的。 作为对您的文章的深入研究的副作用，我将其翻译为德语： [http://habacht.blogspot.com/2007/10/amazon-architecture.html](http://habacht.blogspot.com/2007/10/amazon-architecture.html) 为什么？ perl 是用于文本处理的常用工具：） java 不仅限于 perl 由于谦虚，我倾向于说 Java 并不适合所有传统的业务术语。 效率，投资回报。 我今天经营一家公司，并且相信我，从长远来看，Java 并不是设计大型&关键应用程序的最终选择。 只有伪专家和伪 IT 经理才将 Java 视为明天编程问题的第一个答案。 我建议您检查 J2EE 后面的语言/框架环境。 以 Perl 6 为例。 我在开玩笑 ？ 并不是的。 我们的最后一个 Web 服务完全使用 Perl 和 Ruby 中的接口进行了完全设计。 开明的用户想知道它是否是 struts + hibernate + weblogic + oracle（可能带有 SAP R / 3 连接器）。 现在的现实已经大不相同：我们必须考虑纯粹的业务。 Java 的？ 好的，我今天将检查 Sun 的博客。 我也爱 Java。 真的很有趣，喜欢阅读。 但是，我觉得如果您真的想感谢一个成就卓越的人，请给他们加薪或奖金！ 那就是我最欣赏的，毕竟我们是为了钱而工作。 大部分内容非常有用（特别是我同意的部分；） 梅森对我来说是新的！ 非常好的帖子。 [http://evandro.net/“](<a rel=) > Evandro [http://www.poker73.com/”](<a rel=) >坐下&转到 Very informative for the most part (specially the parts I agree with ;) 您能否解释一下“ DOM”的含义 那是一篇关于亚马逊建筑大师的好书。 在下周对亚马逊的采访中肯定会有所帮助。 亚马逊是一家伟大的公司。 真的启发了我。 [http://www.csscatwalk.com“](<a rel=) style =” color：#FFFFFF;“ > CSS 画廊 谢谢！ 非常感谢您提供如此详细的信息。 它无疑帮助我了解了有关构建可扩展网站的更多事实。 That was a nice read about amazon architecutre. Would definitely help during the interview with amazon next week. 大多数情况下非常有用