MySpace：.Net架构网站的王者
MySpace的成功对于.Net社区的开发人员来说无疑是个福音。它让很多.Net追随者吃下了一颗定心丸，也不断吸引了更多的追随者,让我们这些追随者都坚信使用.Net能够做出世界上最牛x的网站。如果没有MySpace,当我们面对 Java, LAMP fans挑衅时候，我们该如何反击呢？哑口无言还是掩面逃窜。现在rails就缺乏一个”MySpace”, twitter.com目前还不能让我们完全诚服rails架构。
MySpace从03年底上线，但注册用户数量早在06年就已经达到了1亿。它仅用了3年就达到了这个级别，这点连facebook也自叹不如了。MySpace的主意最初来自Intermix的ChrisDeWolfe和TomAnderson，可能是受到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和满足了新的快速增长负载。
