MySpace：.Net架构网站的王者

MySpace的成功对于.Net社区的开发人员来说无疑是个福音。它让很多.Net追随者吃下了一颗定心丸，也不断吸引了更多的追随者,让我们这些追随者都坚信使用.Net能够做出世界上最牛x的网站。如果没有MySpace, 当我们面对 Java,  LAMP fans挑衅时候，我们该如何反击呢？哑口无言还是掩面逃窜。现在rails就缺乏一个”MySpace”,  twitter.com目前还不能让我们完全诚服rails架构。

MySpace从03年底上线，但注册用户数量早在06年就已经达到了1亿。它仅用了3年就达到了这个级别，这点连facebook也自叹不如了。MySpace的主意最初来自Intermix的Chris DeWolfe和Tom Anderson，可能是受到Friendster最初的成功刺激，加上对Friendster某些功能的不满意，他们开始花了三个月时间开发出一个和Friendster功能类似的网站。MySpace最初的战略并没有以独立制作乐队和围绕音乐的社会网络为目标。有关音乐的主题是以用户为中心的网站发展过程中自然发展出来的。有趣的是，在最初上线和开始推广后的6到9个月，用户增长并不成功。MySpace最初的推广手段是在Intermix的员工（约250人）中进行有奖竞赛，让员工们邀请他们的朋友注册。这产生了一定效果，但用户数很有限。接下来，他们利用电子邮件列表进行邮件推广。这有一些影响，但基本上是失败的。这是因为电子邮件推广不能象已经存在的小组或组织那样吸引能对网站产生忠实度的用户。于是MySpace开始进行线下推广，对洛杉矶地区的Club、乐队、和各种派对进行赞助。这些努力逐渐给MySpace造成影响。更重要的是吸引了很多小的线下社区（即小组）来使用MySpace。100到1000人之间的小社区开始产生雪球式的病毒增长，并吸引更多的个人用户加入。最初用户建立起来后，MySpace开始进一步利用Intermax的渠道和媒体关系扇风助燃。合作伙伴的推广结合上已有的较强用户基础，使得MySpace从最初的成功走向腾飞。如果没有利用传统的推广手段，MySpace恐怕不会有我们今天看到的高速增长。

为什么MySpace能如此成功，有人总结出下面几点关键因素：

·         给用户更多自由设计他们的MySpace主页，让用户能高度地表达自我和与朋友交流。

·         缩短开发周期，使产品迅速适应用户要求。

·         最初的用户积累依靠三种手段的结合：病毒式增长、非网络广告、网络传播合作伙伴。

·         有关产品和研发政策的决策，要考虑到网站的负载能力

OK! 上面把MySpace.com的由来大概说了一下，这对于很多处于创业中的朋友可能有所帮助。大体情况介绍完了，我们就来仔细分析MySpace技术细节。MySpace初期是使用Perl+Apache+MySQL架构的，后来被Intermix内部直接枪毙了，改用ColdFusion+Windows+Microsoft SQL Server, 因为当时Intermix内部的大多数开发人员更为熟悉ColdFusion。ColdFusion对我来说也是传说中的东东，最开始听说好像还是上大学研究adobe三剑客看到的。实际上MySpace是在2005年早期，账户达到9百万后才开始使用.Net Framework来重新实现，效果可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。 最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。

                在2004年早期，MySpace用户数增长到50万后，当时只有两台Web服务器和一个数据库服务器，后面这台数据库服务器已经已开始汗流浃背，然后重构了数据库的架构，采用类似MySQL的master-slave replication架构，让两台slave数据库服务器来负责read的负载，同时同步master机器最新的更新。但是数月过后，此时注册数已经达到1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。那台master机器已经扛不住了。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”。这一次的数据库架构按照垂直分割(Vertical Partitioning)模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。在面对Scale up和Scale out选择时候，MySpace当时的决策竟然是选用Scale up,果然是有钱yin啊。应该是想规避需要大量重写原来软件，以保证系统能在分布式服务器上运行的风险。不过它的scale up experience还是值得研究研究。对于某些场景来讲scale up或许是个更加好的解决方案。我们这么多年来一直也享受着scale up带来的好处，个人也感觉不久前还在用256现在是动不动2G,4G,xxG了，CPU也基本上是hyper-threaded, dual-core, xx-core呵呵。后来MySpace也认识到了高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。” 因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。这里做的horizontal partitioning也就是我写过的文章<<.Net架构网站遇到大表该怎么办？>>阐述的情况。好像我的规模比此时MySpace的规模还大点。嘿嘿，得意的笑。注意此时MySpace还不是使用.Net架构，估计是用ColdFusion扛不住了，看到.Net有那么多的优点，忍不住就切换到.Net Platform上了。哎，一个把持不住….？然而结果证实他们的尝试是值得了，也成功化解了迁移带来的巨大risk和满足了新的快速增长负载。

                通过上面一大段我们对MySpace的前期技术发展也有了一个大概的了解，同时也能学习到了一些针对高负载网站常见的几个方面的解决方案。我们能够明白Scale up和scale out的优缺点，Horizontal Partition和vertical Partition的作用，以及后台数据库和web server的load balance。作为一个技术人员，如果职业生涯能够经历一个网站从几个用户到数千万到数亿用户使用，也不枉费人世走着一遭，有点夸张了J。

                哎，上面水来水去都不是俺们哥们.Net框架的功劳，欢呼个啥呢？别介，高手啥的一般都应该在剧末才粉末登场对吧。.Net也是，MySpace team估计已经感觉到他们熟悉的ColdFusion很难抗住如此快速增长的负载，而选择.Net方案，而不是那个啥java,呵呵。由此才可以突出俺们哥们.Net的牛x,管它多少用户，来一百万消灭一百万，来一千万消灭。。。不好意思，哥们吹的有点过了。。。那MySpace是怎么利用.Net来搞定它的数亿用户的负载的呢？ MySpace是在2005年早期，用户数达到9百万后才开始使用.Net Framework来重新实现，上文已经讲了切换到.Net后立杆见影的效果，但是当用户数达到1千万时，MySpace再次遭遇存储瓶颈问题。不过可不是.Net扛不住，而是后台机器负载不够均衡，导致某些机器过载了。具体原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。Faint, MySpace到这个规模才想起来用Cache,真的有点sx了。增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。既然承认错误了，就不打Benedetto的pp了。后来在2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。 更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。看来MySpace还是比较喜欢用scale up的解决方案。也对，反正有$，多花点无所谓。后来在…... 历史车轮还会继续向前推进，MySpace也会不断遇到新的挑战，虽然这些挑战我们可能一辈子都不可能遇到，但是作为一个.Net追随者，应该时刻追随着这个王者的脚步，因为他是我们的领袖，他应该是我们心中的信仰….(自己也感觉有点发毛，呵呵)

                诚然，MySpace对于.Net技术的发展毋庸置疑是起了不少推动作用。因为他遇到了很多微软自身都没有遇到的问题，它给.Net提供了一个不断增长的高负载的实验平台，来一个一个检验微软的产品和技术。微软在克服一个一个难题后，在下一代产品launch时候把这些问题fix后加入新产品，这样我们这些终端客户实际上也间接的享受到了MySpace给我们带来的.Net技术promotion。MySpace应该是微软的金牌合作伙伴，在www.asp.net上Who is using ASP.NET?第一个就是MySpace。微软估计开心极了，有MySpace这样的巨无霸帮他向整个业界证明了.Net的牛x。很期望将来在中国能够看到像MySpace这样的网站，至少应该有一些像douban使用python这样的互联网产品。一枝独秀有时不是比百花齐放更美，不是吗？最后，如果您想投入或者已经投入.Net的门下，那么您一定要熟记下上面的关于MySpace的关键数字，至少能够做到脱稿讲5分钟。下次，面对小弟们请教或者Jxxa fans挑衅时候，不用我说，你应该知道该怎么做了。MySpace对我们来说应该不仅仅是个互联网巨无霸……