Amazon的体系结构经历了巨大的变化，从最初的两层体系结构到提供许多不同应用的分布式分散服务平台。
起初，只有一个应用程序与后端交互，这是用C++完成的。
体系结构将随着时间的推移而发展。多年来，亚马逊一直将其容量扩展重点放在后端数据库上，试图使其容纳更多商品数据、更多客户数据和更多订单数据，并使其支持多个国际站点。到2001年，前端应用程序显然无法再努力增加容量。数据库分为许多小部分。围绕每个部件创建一个服务接口，该接口是访问数据的唯一方式。
数据库已逐渐演变为共享资源，因此很难在所有业务的基础上增加容量。前端和后端处理的发展受到很大限制，因为它们被太多不同的团队和流程共享。他们的体系结构是松散耦合的，并围绕服务构建。面向服务的体系结构提供的隔离使他们能够快速、独立地完成许多软件组件的开发。
逐渐地，Amazon拥有数百个服务和多个应用程序服务器来聚合服务中的信息。生成http://Amazon.com 站点页面的应用程序位于这样的应用程序服务器上。对于提供web服务接口、客户服务应用程序和卖方接口的应用程序也是如此。
许多第三方技术难以适应亚马逊等网站的规模，尤其是通信基础设施技术。它们在一定范围内工作良好，但如果范围扩大，它们将不适用。因此，亚马逊必须开发自己的基本技术。不要“挂”在技术上。Amazon在某些地方使用JBoss/Java，但它只使用服务器，没有充分利用J2EE中涉及的技术。用C++开发的程序用于处理请求。per/Mason开发的程序用于生成页面中的内容。
Amazon不喜欢中间件技术，因为它看起来更像一个框架，而不是一个工具。如果使用中间件，它将受到该中间件所采用的软件模式的困扰。你只能使用他们的软件。如果你想使用不同的软件，这几乎是不可能的。你被困住了！消息中间件、数据持久层中间件、Ajax等经常出现。它们都太复杂了。如果中间件可以以更小的组件的形式提供，并且更像是一个工具而不是一个框架，那幺它可能对我们更有吸引力。
与Soap相关的web解决方案似乎希望再次解决分布式系统的所有问题。
Amazon同时提供soap和RESTWeb服务。大约30%的用户将soap用作web服务。它们似乎是Java和Java。Net用户，并使用WSD生成远程对象接口。大约70%的用户使用rest。它们似乎是PHP和每个用户。
无论是使用soap还是rest，开发人员都可以获得访问Amazon的对象接口。开发人员希望完成这项工作，而不必担心网络电缆上传输的内容。
亚马逊希望围绕他们的服务建立一个开放的社区。他们选择web服务是因为它的简单性。事实上，它是一个面向服务的体系结构。简而言之，只能通过接口访问所需的数据。这些接口由WSD描述，但它们采用自己的封装和传输机制。
架构（Architecture）开发团队是小型团队，围绕不同的服务组织。在亚马逊，服务是独立的功能交付单元。这就是亚马逊组织内部团队的方式。
如果你有一个新的商业计划书或者想解决一个问题，你可以组织一个团队。由于沟通成本，每个团队的人数限制为8~10人。他们被称为两支比萨饼队。因为有了两个比萨饼，团队中的每个人都可以吃饱。
团队规模很小。他们被授权以任何他们喜欢的方式解决问题或改进服务。
例如，他们创建了一个团队，其职能是在书中查找独特的单词和短语。团队已经为该功能创建了一个单独的服务接口，并且有权执行他们认为需要执行的任何操作。
部署
他们创建了一个特殊的基础设施来管理依赖关系和部署服务。
目标是所有正确的服务都可以部署在一台主机上。所有应用程序代码、监控机制、许可机制等应位于一个“主机”中。
每个人都有自己的系统来解决这些问题。
部署过程的输出是一个虚拟机，可以使用EC2运行它们。
为了验证新服务的效果，值得从客户的角度来审视服务。
从客户的角度来看服务
为了验证新服务的效果，值得从客户的角度来审视服务。
从客户的角度看服务，关注希望向用户提供的价值。
迫使开发人员关注交付给客户的价值，而不是首先考虑如何构建技术，然后再考虑如何使用技术。
从用户将看到的简要功能开始，然后从客户的角度检查您构建的服务是否有价值。
以最小化的设计结束设计过程。如果您想构建一个大型分布式系统，简单性是关键。
对于大规模可扩展系统，状态管理是核心问题。
在内部，它们可以提供无限的存储空间。
并非所有操作都是有状态的。结束步骤是有状态的。
通过分析最近单击的页面的会话ID，此服务可以向用户提供推荐产品和建议。
它们跟踪并存储所有数据，因此维护状态不是问题。有一些单独的状态需要为会话维护。所提供的服务将始终保留信息，因此您只需要使用这些服务。
Eric brewers的cap理论——或系统的三个属性
系统的三个属性：一致性、可用性、网络分区容差。
对于任何共享数据的系统，它至少具有这三个属性中的两个。
网络分区容差：将节点划分为小组。它们可以看到其他组，但无法看到所有其他节点。
一致性：写入一个值，然后读取它。得到的返回值应该与您写入的值相同。分区系统中并非如此。
可用性：不总是可读写的。系统可能会告诉您无法写入数据，因为您需要保持数据一致性。
对于可伸缩性，必须对系统进行分区，因此对于特定的系统，您必须在高一致性或高可用性之间进行选择。在可用性和一致性之间找到正确的重叠。
根据服务的需要选择特定的实现方法。
对于结账过程，您总是希望在客户的购物车中放置更多的商品，因为这可以产生收入。在这种情况下，您需要选择高可用性。错误是对客户隐藏的，稍后将进行分析。
当客户提交订单时，我们应该更加注重保持高一致性。因为有几种不同的服务——信用卡服务、分销服务、报告功能等——可以同时访问这些数据。
