亚马逊的技术架构是怎么样的

还有这个：http://www.nedworks.org/~mark/presentations/san/Wikimedia%20architecture.pdf

Amazon的体系结构
Amazon从一个很小的网上书店发展成为现今世界上最大的网上书店中。他们开辟了让顾客来评估，审查和推荐商品的新方式。
平台

• inux
• orace
• C++
• Per
• Mason
• Java
• Jboss
• Servets

状态

• 超过5500万活动顾客帐号
• 世界范围内超过100万活动零售合作商
• 构建一个页面所需访问的服务介于100至150个之间

体系结构

• 我们说的可伸缩性到底意味着什么？对于一个服务来说，当我们增加为其分配的系统资源之后，它的性能增长能够与投入的资源按比例提升，我们就说这个服务具有可伸缩性。通常意义上的性能提升，意味着能够提供更多的服务单元，也可以为更大的工作单元提供服务，比如增长的数据集等。
• Amazon的架构经历了巨大的变化，从一开始时的两层架构，转向了分布式的、去中心化的服务平台，提供许多种不同的应用。
• 最开始只有一个应用来和后端交互，是用C++来完成的。
• 架构会随着时间而演进。多年来，Amazon将增容的主要精力放在后端的数据库上，试图让其容纳更多的商品数据，更多的客户数据，更多的订单数据，并让其支持多个国际站点。到2001年，前端应用很明显不能再做任何增容方面的努力了。数据库被分为很多个小部分，围绕每个部分会创建一个服务接口，并且该接口是访问数据的唯一途径。
• 数据库逐渐演变成共享资源，这样就很难再在全部业务的基础之上进行增容操作了。前端与后端处理的演进受到很大限制，因为他们被太多不同的团队和流程所共享了。
• 他们的架构是松散耦合的的，并且围绕着服务进行构建。面向服务的架构提供给他们的隔离特性，让他们能够快速、独立地完成许多软件组件的开发。
• 逐渐地，Amazon拥有了数百个服务，并有若干应用服务器，从服务中聚合信息。生成http://Amazon.com站点页面的应用就位于这样的一台应用服务器之上。提供web服务接口、顾客服务应用以及卖家接口的应用也都是类似的情况。
• 许多第三方的技术难以适用Amazon这种网站的规模，特别是通讯基础架构技术。它们在一定范围内工作的很好，但是如果范围再扩大的话，它们就不适用了。因此，Amazon只好自己开发相应的基础技术。
• 不在一种技术上"吊死"。Amazon在有的地方使用jboss/java,不过只是使用servets，并没有完全使用j2ee中所涉及到的技术。
• C++开发的程序被用来处理请求。Per/Mason开发的程序用来生成页面中的内容。
• Amazon不喜欢采用中间件技术，因为它看起来更像一种框架而不是一个工具。如果采用了某种中间件，那么就会被那种中间件所采用的软件模式所困扰。你也就只能选用他们的软件。如果你想采用不同的软件几乎是不可能的。你被困住了！经常发生的情况就是消息中间件，数据持久层中间件，Ajax等等。它们都太复杂了。如果中间件能够以更小的组件的方式提供，更像一个工具而不是框架，或许对我们的吸引力会更大一些。
• SOAP 相关的web解决方案看起来想再次解决所有分布式系统的问题。
• Amazon提供SOAP和REST这两种Web 服务。大概有30%的用户采用SOAP这种Web Services。他们看起来似乎是Java和.NET的用户，而且使用WSD来生成远程对象接口。大概有70%的用户使用REST。他们看起来似乎是PHP和PER的用户。
• 无论采用SOAP还是REST，开发人员都可以得到访问Amazon的对象接口。开发人员想要的是把工作完成，而不需要关心网线上传输的是什么东西。
• Amazon想要围绕他们的服务构建一个开放的社区。他们之所以选择Web Services是因为它的简单。事实上它是一个面向服务的体系架构。简单来说，你只有通过接口才能访问到需要的数据，这些接口是用WSD描述的，不过它们采用自己的封装和传输机制。
• 架构开发团队都是小规模团队，而且都是围绕不同的服务进行组织。
• 在Amazon服务是独立的功能交付单元。这也是Amazon如何组织他的内部团队的。
• 如果你有一个新的业务建议，或者想解决一个问题，你就可以组织一个团队。由于沟通上的成本，每个团队都限制到8~10个人。他们被称为two pizza teams。因为用两个比萨饼，就可以让团队成员每个人都吃饱了。
• 团队都是小规模的。他们被授权可以采取他们所中意的任何方式来解决一个问题或者增强一个服务。
• 例如，他们创建了这样一个团队，其功能是在一本书中查找特有的文字和短语。这个团队为那个功能创建了一个独立的服务接口，而且有权做任何他们认为需要做的事情。
• 部署
• 他们创建了一个特殊的基础设施，来完成对依赖性的管理和对完成服务的部署。
• 目标是让所有正确的服务可以在一个主机中部署。所有的应用代码、监控机制、许可证机制等都应该在一个“主机”中。
• 每个人都有一个自己的系统来解决这些问题。
• 部署进程的输出是一个虚拟机，你可以用EC2来运行他们。
• 为了验证新服务的效果，从客户的角度去看待服务，这样做是值得的。
• 从客户的角度去看待服务，聚焦于你想交付给用户的价值。
• 强迫开发人员将关注点放在交付给客户的价值上，而不是先考虑如何构建技术再考虑如何使用技术。
• 从用户将要看到的简要特性开始，再从客户考虑的角度检查你构建的服务是否有价值。
• 以最小化的设计来结束设计过程。如果想要构建一个很大的分布式系统，简单性是关键。
• 对于大型可伸缩系统来说状态管理是核心问题
• 内部而言，他们可以提供无限存储空间。
• 并不是所有的操作是有状态的。结账的步骤是有状态的。
• 通过分析最近点击过的页面的SessionID，这种服务可以为用户提供推荐商品建议。
• 他们追踪、保存着所有的数据，所以保持状态不是一个问题。有一些分离的状态需要为一个session来保持。提供的服务们会一直保留信息，所以你只要使用这些服务就可以了。
• Eric Brewers‘ CAP理论——或称为系统的三个属性
• 系统的三个属性：一致性，可用性，网络分区容忍度。
• 对于任何一个共享数据的系统都至少具备这三个属性中的两个。
• 网络分区容忍度：把节点分割成一些小的分组，它们可以看到其他的分组但是无法看到其他全部节点。
• 一致性：写入一个值然后再读出来，你得到的返回值应该和写入的是同一个值。在一个分区系统中有些情况并非如此。
• 可用性：并非总是可读或者可写。系统可能会告诉你无法写入数据因为需要保持数据的一致性。
• 为了可伸缩性，你必须对系统进行分区，因此针对特定的系统，你要在高一致性或者高可用性之间做出选择。你必须找到可用性和一致性的恰当重叠部分。
• 基于服务的需要来选择特定的实现方法。
• 对于结账的过程，你总是想让更多的物品放入顾客的购物车，因为这样可以产生收入。在这种情况下你需要选择高可用性。错误对顾客是隐藏的，过后才会被拿出来分析。
• 当一个顾客提交订单过来时，我们要将关注点更多的放在保持高一致性上。因为几个不同的服务——信用卡处服务、配送服务、报表功能等——在同时访问那些数据。

汲取的教训

• 为了构建真正的可伸缩的系统，你必须改变你的想法或者心态。混沌方法在概率意义上可能工作的很好。在传统的系统中我们展示的是一个完美的世界，没有什么东西会出现问题、停止运转，之后我们在这个完美的世界上构造复杂的算法。实际上，事情总是会出问题的，这就是你必须要接受的事实。例如，试着多想想如何快速完成服务器重启和如何快速恢复数据。合适的分布数据和服务，你可能向100%无故障又迈进了一步。创建可自愈的（sef-heaing）、自组织的（sef-organizing）系统架构。
• 创建一个没有分享的基础架构。对于开发和部署来说，基础架构也是共享资源，就像在逻辑层和数据层共享的资源一样，你也会遭遇到出问题的时候。可能会导致锁机制和屏蔽机制，并产生死锁。一个面向服务的架构，允许采取并行和分离的开发流程，这样可以使得功能特性的开发也具有“可伸缩性”，与系统的增长相匹配
• 将系统及其API同时开放，这样你会围绕着你的应用创建了一个生态系统。
• 管理巨大的分布式系统的唯一方法，就是让所有的事情尽可能的简单。保持事情简单的办法就是保证设计的时候没有隐藏的需求和隐藏的依赖关系。采用尽可能少的技术来解决你解决的问题。人为的创造一些不需要的复杂系统层次架构对公司并没有益处。
• 围绕服务进行组织可以提供敏捷性。你可以并行的做事情，因为输出结果是一个服务。这使得缩短了产品和服务投放到市场去的时间。需要创建一个基础架构来保证服务可以被很快的构建起来。
• 任何事情，在有真正的实现之前，就来了一堆炒作消息，这其中肯定存在着问题。
• 在内部使用服务品质协议（Service eve Agreement，简称SA）来管理服务。
• 任何人都可以很快的为他们的产品添加Web Services。以服务的形式来实现你的一部分产品，并开始使用这些服务。
• 由于性能，可靠性和成本控制的原因，可能需要自己来构建基础设施架构。自己构建这些基础架构即便Amazon关门了也不必说是某某公司的错误导致的。自己构建的系统可能没有其他的易用，不过相对使用第三方的东西来说，你可以更快地对自己构建的基础架构进行修补、调试和部署。
• 采用“‘方法’和‘目的’”这样的思辨方式，来区分好与坏。我曾参加过几次前Amazon员工做的演讲，从中发现，这是Amazon和其他公司很不一样的独特而有趣之处。其深层道理是，通过将选择的权利交给真正的顾客，来看哪种做法最合适，并基于这些测试来发现顾客的真正需要。Avinash Kaushik把这个叫做避免HiPPO（the highest paid peope ithe room，屋子里拿薪水最高的人）的影响。通过A/B测试和Web Anaytics等技术手段可以达成目的。如果你对应该做什么有疑问，先开发一些功能，让人们使用这些功能，再看哪一种变通使用方式能够带给你想要的结果。
• 创建一个节俭的环境。例如，Amazon就把门当桌子来用。
• 了解你需要什么。Amazon早期有一个很糟糕的经历，就是没有达成预期目标的推荐系统： “这不是我们所需要的图书推荐系统。Amazon需要的是一个可以基于少量分散的数据，例如一些顾客的评分和购买记录，就可以很好的工作的图书推荐系统。而且它的反应速度要足够快。这个系统也需要适应大量的数据和大量的图书类别。而且它还可以帮助读者发现一些他们真正需要却自己无法发现的图书需求。”
• 人性化的项目——人们跟随这个项目是因为他们对其感兴趣——可以激发更多的价值和创造力。不要低估因为兴趣而激发的力量。
• 在创建产品的过程中，让每个人都参与进来。在圣诞大采购来临之时，去仓库打包图书吧，这样才是团队精神。
• 创建一个可以用来测试的站点，测试通过之后才可以真正的向大众推出。
• 对于Web服务器使用的只读数据来说，一个健壮的、集群式的、冗余的、分布式文件系统是完美的。
• 如果更新没有成功的话，要有可以回滚到以前正常的状态的运作方式。必要的话开发一个工具。
• 转向更深入的基于服务的架构
• 面试的时候需要关注参加面试者的三个要点：热情，创造力和熟练程度。在Amazon，成功的最大特征就是对工作的热情。
• 要雇佣这样的员工，他们有着惊人的调试技术和系统知识，最重要的是，他们可以在高度压力的状况下，应对非常棘手的问题。
• 创新只能来自于底层。最了解问题的人才是最有可能解决问题的人。任何一个依赖于创新的组织必须可以容纳一定程度的混沌。忠诚和服从不是你的工具。
• 创新精神必须无处不在。
• 任何人都应该有机会去尝试，去学习，去实践。职位的变迁，服从，传统的习惯都不应该有多大的权利。创新的蓬勃发展，必须要有一套行之有效的考核办法。
• 拥抱创新。在整个公司员工的面前，Jeff Bezos会亲自颁发‘Just do it‘奖，一双旧的耐克鞋，给那些具有创新精神员工。
• 不要基于绩效给付薪酬。给予好的福利和高的薪酬，但是要让大部分人都能享受到。通过其他的方式来表达出对一些表现非常优异的员工的认可。‘按劳分配‘听起来不错，但是在一个大公司内是不可能做到公平的。采用一些非货币的奖励，例如一双旧的耐克鞋其实也是很好的。那也是一种用来表达感谢的方式，说明有人在关心他们。
• 迅速扩张。像Barnes& Nobe这样的大型对手紧跟在你的后面。Amazon曾经不是互联网上最大的书店，不是第二名，甚至也不是第三名。但是他们的远景规划和执行方式最终让他们笑到了最后。
• 在数据中心，员工花在解决基础设施问题上面的时间只有30%是和利润创造相关的。其他的70%的时间则是花在"繁重"的硬件采购、软件管理、负载均衡、维护、应对增容挑战等其他事情上。
• 严禁客户直接访问数据。这意味着你可以让你的服务具有可伸缩性，并在不影响客户的前提下，具有更好的可靠性。这有些类似于Googe的能力，他们能够通过对服务器栈的独立、分布的改进，来提升所有的应用。
• 创建统一的服务访问机制。这使得服务易于集成，还可以完成请求路由去中心化、分布请求追踪、以及其他一些高级的基础架构技术。
• 让世界上任何开发人员都能够通过Web服务接口，免费访问http://Amazon.com。这也是成功的一个重要因素。因为它引发的诸多创新，仅靠Amazon自己的队伍是无法想象出来或者无法实现的。
• 开发人员自己知道哪些工具用起来最顺手，什么样的工具最适合目前的工作。
• 不要在工程师身上强加过多的限制。为某些功能的完成提供一些激励措施，比如与监控系统的集成，或者与其他基础架构工具的集成等功能。但是对于其他的功能，要保证团队的独立性。
• 开发人员与艺术家类似，如果有足够的自由，他们就可以把工作做到最好，但是他们也需要好的工具。提供尽量多的支持工具，围绕着服务的开发，提供环境的支持，使得环境不会成为开发工作的阻碍。
• 谁构建，谁运行。这让开发人员与他们所开发的软件的日常运营工作相联系。也带给他们与顾客之间的日常联系。这种顾客反馈循环对于提升服务质量来说是至关重要的。
• 每隔两年，开发人员就应该与客户服务部门在一起待一段时间。在那里，他们可以听到真实的客服电话，回答客服电子邮件，并深刻领会他们作为技术人员所开发的东西造成的影响。
• 让大家聆听“来自顾客的声音”，内容是一个顾客讲述自己使用网站所产生的用户体验的真实故事。这可以让管理层和工程师们体会到，我们是在为实实在在的人们开发这些技术。通过客服统计数据，我们可以提早发现做错了哪些事情，或是发现哪些是客户的真实痛点。
• 就像Googe一样，Amazon的基础架构是他们的巨大核心竞争力。通过一些相对简单的底层服务，他们可以构建出非常复杂的应用。他们可以彼此独立地完成各个服务的增容，维护非并行系统的可用性，并在不需要修改大量系统配置的情况下，快速发布新的服务。

转自：http://www.zhihu.com/question/20105139

亚马逊的技术架构是怎么样的,布布扣,bubuko.com

亚马逊的技术架构是怎么样的

原文：http://www.cnblogs.com/olmlo/p/3855508.html