架构学习笔记—Amazon

谁也没想到，之前一个小小的网上书店，现在居然成了全球商品品种最多的网上零售商和全球第2大互联网公司，它叫Amazon。相信很多朋友都知道Amazon，那就不多作介绍了，下面我们主要来探讨一下Amazon的网站架构方面的话题。另外，本文很多内容也是来自互联网，如有侵权方面的内容请留言，我会及时处理。

一、平台以及状态

Linux、oracle、C++、Perl、Mason、Java、Jboss、Servlets

--超过5500万活动顾客帐号

--世界范围内超过100万活动零售合作商

--构建一个页面所需访问的服务介于100至150个之间

二、架构概述

l  我们说的可伸缩性到底意味着什么？对于一个服务来说，当我们增加为其分配的系统资源之后，它的性能增长能够与投入的资源按比例提升，我们就说这个服务具有可伸缩性。通常意义上的性能提升，意味着能够提供更多的服务单元，也可以为更大的工作单元提供服务，比如增长的数据集等。

l  Amazon的架构经历了巨大的变化，从一开始时的两层架构，转向了分布式的、去中心化的服务平台，提供许多种不同的应用。

l  最开始只有一个应用来和后端交互，是用C++来完成的。

l  架构会随着时间而演进。多年来，Amazon将增容的主要精力放在后端的数据库上，试图让其容纳更多的商品数据，更多的客户数据，更多的订单数据，并让其支持多个国际站点。到2001年，前端应用很明显不能再做任何增容方面的努力了。数据库被分为很多个小部分，围绕每个部分会创建一个服务接口，并且该接口是访问数据的唯一途径。

l  数据库逐渐演变成共享资源，这样就很难再在全部业务的基础之上进行增容操作了。前端与后端处理的演进受到很大限制，因为他们被太多不同的团队和流程所共享了。

l  他们的架构是松散耦合的的，并且围绕着服务进行构建。面向服务的架构提供给他们的隔离特性，让他们能够快速、独立地完成许多软件组件的开发。

l  逐渐地，Amazon拥有了数百个服务，并有若干应用服务器，从服务中聚合信息。生成Amazon.com站点页面的应用就位于这样的一台应用服务器之上。提供web服务接口、顾客服务应用以及卖家接口的应用也都是类似的情况。

l  许多第三方的技术难以适用Amazon这种网站的规模，特别是通讯基础架构技术。它们在一定范围内工作的很好，但是如果范围再扩大的话，它们就不适用了。因此，Amazon只好自己开发相应的基础技术。

l  不在一种技术上"吊死"。Amazon在有的地方使用jboss/java,不过只是使用servlets，并没有完全使用j2ee中所涉及到的技术。

l  C++开发的程序被用来处理请求。Perl/Mason开发的程序用来生成页面中的内容。

l  Amazon不喜欢采用中间件技术，因为它看起来更像一种框架而不是一个工具。如果采用了某种中间件，那么就会被那种中间件所采用的软件模式所困扰。你也就只能选用他们的软件。如果你想采用不同的软件几乎是不可能的。你被困住了！经常发生的情况就是消息中间件，数据持久层中间件，Ajax等等。它们都太复杂了。如果中间件能够以更小的组件的方式提供，更像一个工具而不是框架，或许对我们的吸引力会更大一些。

l  SOAP 相关的web解决方案看起来想再次解决所有分布式系统的问题。

l  Amazon提供SOAP和REST这两种Web 服务。大概有30%的用户采用SOAP这种Web Services。他们看起来似乎是Java和.NET的用户，而且使用WSDL来生成远程对象接口。大概有70%的用户使用REST。他们看起来似乎是 PHP和PERL的用户。

l  无论采用SOAP还是REST，开发人员都可以得到访问Amazon的对象接口。开发人员想要的是把工作完成，而不需要关心网线上传输的是什么东西。

l  Amazon想要围绕他们的服务构建一个开放的社区。他们之所以选择Web Services是因为它的简单。事实上它是一个面向服务的体系架构。简单来说，你只有通过接口才能访问到需要的数据，这些接口是用WSDL描述的，不过它们采用自己的封装和传输机制。

l  架构开发团队都是小规模团队，而且都是围绕不同的服务进行组织。

--  在Amazon服务是独立的功能交付单元。这也是Amazon如何组织他的内部团队的。

--  如果你有一个新的业务建议，或者想解决一个问题，你就可以组织一个团队。由于沟通上的成本，每个团队都限制到8~10个人。他们被称为two pizza teams。因为用两个比萨饼，就可以让团队成员每个人都吃饱了。

--  团队都是小规模的。他们被授权可以采取他们所中意的任何方式来解决一个问题或者增强一个服务。

--  例如，他们创建了这样一个团队，其功能是在一本书中查找特有的文字和短语。这个团队为那个功能创建了一个独立的服务接口，而且有权做任何他们认为需要做的事情。

l  部署

--  他们创建了一个特殊的基础设施，来完成对依赖性的管理和对完成服务的部署。

--  目标是让所有正确的服务可以在一个主机中部署。所有的应用代码、监控机制、许可证机制等都应该在一个“主机”中。

--  每个人都有一个自己的系统来解决这些问题。

--  部署进程的输出是一个虚拟机，你可以用EC2来运行他们。

l  为了验证新服务的效果，从客户的角度去看待服务，这样做是值得的。

--  从客户的角度去看待服务，聚焦于你想交付给用户的价值。

--  强迫开发人员将关注点放在交付给客户的价值上，而不是先考虑如何构建技术再考虑如何使用技术。

--  从用户将要看到的简要特性开始，再从客户考虑的角度检查你构建的服务是否有价值。

--  以最小化的设计来结束设计过程。如果想要构建一个很大的分布式系统，简单性是关键。

l  对于大型可伸缩系统来说状态管理是核心问题

--  内部而言，他们可以提供无限存储空间。

--  并不是所有的操作是有状态的。结账的步骤是有状态的。

--  通过分析最近点击过的页面的SessionID，这种服务可以为用户提供推荐商品建议。

--  他们追踪、保存着所有的数据，所以保持状态不是一个问题。有一些分离的状态需要为一个session来保持。提供的服务们会一直保留信息，所以你只要使用这些服务就可以了。

l  Eric Brewers' CAP理论——或称为系统的三个属性

--  系统的三个属性：一致性，可用性，网络分区容忍度。

--  对于任何一个共享数据的系统都至少具备这三个属性中的两个。

--  网络分区容忍度：把节点分割成一些小的分组，它们可以看到其他的分组但是无法看到其他全部节点。

--  一致性：写入一个值然后再读出来，你得到的返回值应该和写入的是同一个值。在一个分区系统中有些情况并非如此。

--  可用性：并非总是可读或者可写。系统可能会告诉你无法写入数据因为需要保持数据的一致性。

--  为了可伸缩性，你必须对系统进行分区，因此针对特定的系统，你要在高一致性或者高可用性之间做出选择。你必须找到可用性和一致性的恰当重叠部分。

--  基于服务的需要来选择特定的实现方法。

--  对于结账的过程，你总是想让更多的物品放入顾客的购物车，因为这样可以产生收入。在这种情况下你需要选择高可用性。错误对顾客是隐藏的，过后才会被拿出来分析。

--  当一个顾客提交订单过来时，我们要将关注点更多的放在保持高一致性上。因为几个不同的服务——信用卡处服务、配送服务、报表功能等——在同时访问那些数据。

上段文字引自：http://www.yaosansi.com/post/1147.html

下面是一张Amazon的Dynamo Key-Value存储架构图：

Dynamo是亚马逊的key-value模式的存储平台，可用性和扩展性都很好，性能也不错：读写访问中99.9%的响应时间都在300ms内。

按分布式系统常用的哈希算法切分数据，分放在不同的node上。Read操作时，也是根据key的哈希值寻找对应的node。Dynamo使用了 Consistent Hashing算法，node对应的不再是一个确定的hash值，而是一个hash值范围，key的hash值落在这个范围内，则顺时针沿ring找，碰到的第一个node即为所需。

Dynamo对Consistent Hashing算法的改进在于：它放在环上作为一个node的是一组机器（而不是memcached把一台机器作为node），这一组机器是通过同步机制保证数据一致的。

有关Dynamo的更多信息请参看：http://baike.baidu.com/view/2982765.html?fromTaglist

Amazon的云架构图如下：

以下是运行原理：

工作启动器——工作从网站或其它软件子系统进入，在队列服务中排队等候处理。工作不一定非是大请求，可以是整个管线中独立的一小部分。不要把状态保存到工作执行器里。把需要做的事打包进工作请求，放回到队列服务中等候处理。 
规划服务——它是亚马逊的基础设施，允许实例根据工作负载自动伸缩。这是与自有的虚拟服务器（VPS）或典型的数据中心方案主要的不同之处。它有一套启停AMIS的API，以及自动配置、运行VM的机制。 
工作执行器——它们从队列中取出工作，完成具体处理。对SmugMug来说，工作结果存储在S3之上，但你也可以存储在自己的数据库、SimpleDB或其它地方。 
队列服务——队列存储工作执行器要接受的工作。SmugMug建立了自己的队列服务，你也可以直接使用亚马逊的SQS，用起来同样简单。创建一个可伸缩、分布式、高性能、高可用的队列服务并非易事，所以你可以考虑一下“Flickr——先完成必不可少的工作，其它的放进队列”中推荐的大量队列产品。 
控制器——该组件监控工作流相关的大量变量，并以最优化一小组参数为目标，决定需要多少EC2实例。按需增减实例。 
每家供应商都有他们自己的解决方案，预计以后还会出现不同的解决方案。各家的云都还没有得到充分的探究，目前都正在缓慢而稳步地推敲着云的架构解决方案。

好了，有关Amazon架构就介绍到这里，希望能给路过的朋友一点启发，谢谢阅读！

补充：摘自http://www.itivy.com/ivy/archive/2011/8/16/the-architecture-of-amazon.html