该篇文章不涉及他们商业模式和运营，只谈他们的网站架构和技术。
如果只用短短一到两个词来描述MySpace和Amzon两个公司的网站体系的话，
MySpace就是：仓促、快速成长
Amzon就是：稳定、多年积累
1、MySpace
Myspace的开发者们从一开始就不断重构他们的网站、数据存储系统，以期与自身的成长同步，目前，他们的网站月访问量已达到400亿，这个数字还在一直增加。绝大多数网站需要应对的流量都不及Myspace的一小部分，但对于我们这些希望迈入庞大在线市场的人，可以从其身上的成长过程中学到很多东西。
Myspace的网站架构当前已经经历了5个版本，每次都是用户达到一个里程碑后，必须做大量的调整优化，用Benedetto的话说“但我们始终跟不上形式的发展速度，我们需要重构重构再重构，一步步挪到今天”。我们从这句中可以体会到他们的仓促和略显狼狈。因为用户的激增和海量交互在其网站上，使得myspace曾经多次几个小时甚至12个小时网站关闭，服务器承受不住崩溃，用户打不开页面或者某个网站功能罢工的事情更是屡见不鲜。让我们了解一下他们的5个里程碑吧。
a、50万用户
最早myspace网站由一台数据库服务器和两台Web服务器构成，此后一段时间又加了几台web服务器。但在2004年早期，用户增加到50万时一台数据库服务器就显得力不从心了。
他们的解决方案：
他们设计了第一代架构，在此架构中他们运行3个SQL Server2000服务器，一个为主，所有的新数据都提交给他，然后再复制给其他两个数据库服务器。另外两台服务器用来给用户提供信息浏览，也就是只做数据读取。在一段时间内效果不错，只需要增加数据库服务器，扩大硬盘，就可以应对用户数和访问量的增加了。
b、100万-200万万用户
当达到这个数字时，myspace数据库服务器遇到了I/O瓶颈，即他们存取数据的速度跟不上了。而这时据他们第一个架构只要5个月。有人花5分钟都无法完成留言，很多用户认为myspace完蛋了。
他们的解决方案：
新的架构被快速提出来了，这一次他们把数据库架构按照分割模式设计，以网站功能分出多种，如登陆、现实用户资料、博客信息、等分门别类存储在不同的数据库服务器里。这种垂直分割策略利于多个数据库分担访问压力(天涯曾经就这么做过)。后来myspace从存储设备与数据库服务器直接交互的方式SAN（用高带宽和专门设计的网络将大量磁盘存储设备链接在一起，而数据库链接到SAN）。
c、300万用户
到300万用户时，这种架构开始也不行了，因为每个数据库都必须有每个用户表副本，意识是一个用户注册后，他的信息会分别存在每个数据库中，但这种做法有可能某台数据库服务器挂掉了，用户使用一些服务可能会有问题。另一个问题是比如博客信息增长太快，专门为他服务的数据库的压力过大，而其他一些功能很少被使用又在闲置。这就好像有人忙的要死，有人闲的要死。
他们的解决方案：
他们购买了更好更贵的服务器来解决管理更大数据库的问题。但专家预测他们即使昂贵专业的服务器到最后也会不堪重负，他们必须调整架构而不是掏钱买更好的服务器。于是他们的第三代架构出现了。分布式计算架构，他们分布众多服务器，但从逻辑上看成是一台服务器。拿数据库来说，不能再按功能拆分了，看成只有一个数据库服务器。数据库模型中维护一个用户表、博客信息表、等等同看作在一个数据库服务器中。
然后他们开始把用户按每百万一组分割，每一组的用户访问指定的数据库服务器。另外一个特殊服务器保存所有用户的账号和密码。他们的设计师说如果按照这种模式以更小粒度划分架构是可以进一步优化负荷负担的(50万用户为一组 或者更少)。
d、900万-1700万用户
myspace在这个时候把网站代码全部改为.net语言，事实证明网站跑的比以前快了很多、执行用户的请求消耗非常少的资源，后来他们把所有的程序都改成.net了。但问题到1000万时还是出来了。
用户注册量太快，按每100万分割数据库的策略不是那么完美，比如他们的第7台数据库服务器上线仅仅7天就被塞满了。主要原因是佛罗里达一个乐队的歌迷疯狂注册。而且某台数据库服务器可以在任何原因 任何时候遭遇特别大的负荷。他们的解决办法是人工把崩溃的数据库里的用户迁移走。但这不是一个好办法。
他们的解决方案：
myspace购买了3PAdata设备，他的牛逼之处是真正把所有的数据库看成一个整体。他会根据情况把负荷平均分配出去，比如当用户提交一个信息，他会看哪个数据区域空闲然后分配给他，然后会在其他多处地方留有副本，不会出现一台数据库服务器崩溃，而这台数据库里的信息没有办法读取的情况，这样做看起来好极了。
另外他们增加了缓存层，以前用户查询一个信息，就请求一次数据库，现在当一个用户请求数据库后，缓存层就会保留下来一个副本，当其他用户再访问时就不需要再请求数据库了，直接请求缓存就够了。
e、2600万用户
他们把服务器更换到运行64位的服务器，这样服务器上可最多挂上32G内存，这无疑有提升了网站性能，用户感觉这个网站开始稳定快起来了。但一个新问题意外出现了。他们放数据库服务中心的洛杉矶全市停电了。这导致整个系统停止运行长达12个小时。
他们的解决方案：实现了在地理上分布多个数据中心以防止洛杉矶事件再次出现，在几个重要城市的数据中心的部署可以防止某一处出现故障，整个系统照样提供服务，如果几个地方都出现故障，那么这就意味着国家出现了重大灾难，这种几率是非常低的。
MySpace的总结
如果您整体看来时，是不是也如我一样看的惊心动魄呢？有时候用户大批来了你没有做好准备迎接也是一个大问题呀。Bendetto最后说"我们犯过大错误，但到头来，我们做对的事情比做错的事情多，所以我们可以让myspace走到了今天，不然很难想想myspace可以活到现在。"
-------------------------------------------------------------
Amzon
Amzon网站架构和数据存储可以让我们放心的读，他不会和mypace一样让我们看的那么揪心了（Amzon毕竟走过了10几年，而myspace才3年多一些）。：）
Amzon的一组数据：
超过5500万活动顾客的账号和账单信息；
世界范围内超过100万个活动零售商；
构建一个页面所需要访问的服务API在100至150个；
每天数十亿的用户访问。
这是一组庞大的数字，如何管理这些数据，如何跟踪用户在网站上每一个动作信息、这需要很高难度的架构体系才可以支撑。
Amzon的架构经历了巨大的变化，从一开始的两层架构(web服务器-数据库服务器)，转向了分布式的、去中心化的服务器平台，提供许多不同的应用，多年来他们把主要精力放在数据库上，试图让容纳更多的商品数据，更多的客户数据，更多的订单数据。。。。。在这个过程中数据库被分成很多个小部分，围绕每个部分都会创建一个服务接口(API),并且该接口是访问数据库的唯一途径。最终数据库演变成一个非常庞大的共享资源。
他们的架构是松散耦合的，并且围绕着服务进行构建。面向服务的架构提供给他们隔离特性，一个服务可能有很多台数据库服务器，他们之间的数据是相通的，而对外他们的接口只有一个，外面是无法知道这个服务后面的数据组织是如何搭建的。
逐渐的Amazon拥有了上千台服务器，并有了越来越多的应用服务器。这些应用服务器从数据众多的服务（每个服务背后都有数据库或集群数据库）中聚合信息，然后生成我们所看到的Amazon.com的各个网站页面。
Amazon的各种服务如插件一样组成了一个开放的平台，因为这种机制使得他们的团队都是小规模的。
1、在Amazon，服务是独立的功能交互单元。它和其他服务界限分明。
2、如果有一个idea、或者一个问题，你可以组织一个8-10个人的团队，选择喜欢的技术实现方式来工作并最终增加一个服务或解决一个问题。这样的小组被成为two pizza teams，因为2个比萨就可以让团队所有人都吃饱了。
这样的架构体系，大家闭上眼体会一下，感觉会很玄妙，但这种模式确实一直支持Amzon走到了今天。
---------------------------------------------------------------
总结：
如果你的未来是伟大的，那么请做好适当的准备，不然当机会来临时，你可能会被机会压死。从以上的文字中我们应该要学到一些东西。
1、这个世界上没有100%正常运行的完美系统，事情问题总会出现，我们需要接受这一点。
2、更多的考虑一些可能预见的问题，灾难，如何快速的重启服务、快速的数据恢复、合适的分布数据和服务。
3、管理巨大的分布式系统的唯一方法是让所有的事情尽可能的简单、各个服务之间关联性更少一些。
4、要相信，真正有价值的应用绝不是买来的，跟在微软、Sun屁股后面的工程师只能永远做看似复杂的简单应用。
5、创新只能来自底层。最了解问题的人才是最有可能解决问题的人。任何一个拥有创新人才的组织必须容纳一定程度上的混乱。
6、独特的分布式海量存储机制和系统架构是类似Google、Amazon等的巨大核心核心竞争力。
OK！我想说的就这些。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yang3yang/archive/2009/10/20/4705562.aspx
