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和滿足了新的快速增長負載。