大型網站架構之:MySpace的體系架構一（轉載）

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE大型網站架構之:MySpace的體系架構(一)

MySpace.com有著6500萬的訂閱者，是因特網上增長最快的網站之一，每天還有260，000新使用者註冊。它經常因為效能問題而受指責，MySpace不得不處理其他網站很少碰到的或大或小的一些問題。它們是怎麼做的呢？
站點：

平臺

•ASP.NET2.0

•Windows

•IIS

•SQLServer

 

內部執行情況？

•MySpace每天處理15億的頁面頁面檢視，白天處理230萬併發的使用者

•會員使用者里程碑

-500,000使用者：簡單的磕磕絆絆的體系結構

-1百萬使用者：痛苦的垂直分割解決伸縮性

-3百萬使用者：Scale-Out勝過Scale-Up（按比例增加）

-9百萬使用者：站點遷移到ASP.NET，增加虛擬儲存

-2600萬使用者：MySpace擁有了64位技術

 

•500,000個帳號對於兩個web伺服器和一個資料庫來說負擔太大了

•100-200萬個帳號

-他們使用了一種資料庫體系結構，圍繞著垂直分割的概念，提供不同服務比如介面登入，使用者資料和部落格等的網站的各部分都有單獨的資料庫。

-垂直分割方案有助於分開資料庫讀和寫的工作量，並且當使用者需要一個新特徵時，MySpace將會加入一個新的線上資料庫來支援它。

-MySpace從直接使用附著於它的資料庫的伺服器的儲存裝置轉換到一個儲存區域網路（SAN），裡面大量的磁碟儲存裝置由一個高速，專用網路聯絡到一塊，同時資料庫連線到SAN。到SAN的改變提高了效能，正常執行時間和可靠性。

•300萬個帳號

-垂直分割解決方案並沒有持續很長時間因為它們重複了一些水平的資訊像跨過所有垂直片的使用者帳號。有這麼多的重複它會使系統變慢，肯定要失敗。

-個人應用比如Web站點子部分上的部落格將會增長到對於單獨一個資料庫伺服器來說太大的程度

-在邏輯上重組所有核心資料到一個資料庫裡

-把它的使用者基本資訊分成100萬帳號一個的塊，然後把所有有鍵的資料放到SQLServer不同例項的這些帳號中

•900萬-1700萬帳號

-遷移到ASP.NET後，使用了比先前的體系結構更少的資源。150個伺服器執行新的程式碼就能夠做原來246個伺服器做的同樣的工作。

-再看看儲存瓶頸。實施SAN解決了原來的一些效能問題，但是現在Web站點的需求開始間歇性地超過了SAN的I/O能力-它從磁碟儲存讀寫的速度

-使用每個資料庫100萬個帳號的分開方式達到了極限，因為這已經超過了極限；

-遷移到一個虛擬儲存體系結構，那裡整個SAN被當作一個大的儲存池來對待，不需要特定的磁碟為特定的應用服務。現在MySpace在裝置上從相對新的SAN廠商，3PARdata方面已經標準化了。增加了一個快取記憶體層—伺服器放在Web伺服器和資料庫伺服器之間，它唯一的工作就是捕獲記憶體中頻繁訪問的資料物件的副本，然後把它們用於Web應用，不需要資料庫查詢。

•2600萬帳號

-遷移到64位SQLserver以解決它們的記憶體瓶頸問題。它們的標準資料庫伺服器配置使用64GB的RAM。

Myspace的經驗能夠說明什麼？

•你可以使用微軟的技術構建大型網站。

•從一開始就應該使用快取。

•快取記憶體是一個更好的地方儲存臨時資料，比如Web站點上跟蹤一個特定使用者的會話產生的臨時檔案，就不再需要記錄到資料庫裡，

•嵌入OS特徵來檢測拒絕服務攻擊會產生無法解釋的錯誤

•把資料分佈到地理位置不同的資料中心，以免發生斷電事故。

•從開始就考慮使用虛擬儲存/簇檔案系統。它能讓你大量並行IO訪問，而且不需要任何重組就能夠增加所需要的磁碟。

 

MySpace網站架構的變遷

MySpace經歷了六個里程碑的過程。

在每個里程碑，站點負擔都會超過底層系統部分元件的最大載荷，特別是資料庫和儲存系統。接著，功能出現問題，使用者失聲尖叫。最後，技術團隊必須為此修訂系統策略。

雖然自2005年早期，站點賬戶數超過7百萬後，系統架構到目前為止保持了相對穩定，但MySpace仍然在為SQLServer支援的同時連線數等方面繼續攻堅，Benedetto（技術總監）說，"我們已經儘可能把事情做到最好"。

1.里程碑一：50萬賬戶

按Benedetto的說法，MySpace最初的系統很小，只有兩臺Web伺服器和一個資料庫伺服器。那時使用的是Dell雙CPU、4G記憶體的系統。

單個資料庫就意味著所有資料都儲存在一個地方，再由兩臺Web伺服器分擔處理使用者請求的工作量。但就像MySpace後來的幾次底層系統修訂時的情況一樣，三伺服器架構很快不堪重負。此後一個時期內，MySpace基本是透過添置更多Web伺服器來對付使用者暴增問題的。

但到在2004年早期，MySpace使用者數增長到50萬後，資料庫伺服器也已開始汗流浹背。

但和Web伺服器不同，增加資料庫可沒那麼簡單。如果一個站點由多個資料庫支援，設計者必須考慮的是，如何在保證資料一致性的前提下，讓多個資料庫分擔壓力。

在第二代架構中，MySpace執行在3個SQLServer資料庫伺服器上：一個為主，所有的新資料都向它提交，然後由它複製到其他兩個；另兩個全力向使用者供給資料，用以在部落格和個人資料欄顯示。這種方式在一段時間內效果很好。只要增加資料庫伺服器，加大硬碟，就可以應對使用者數和訪問量的增加。

2.里程碑二：1-2百萬賬戶MySpace

註冊數到達1百萬至2百萬區間後，資料庫伺服器開始受制於I/O容量--即它們存取資料的速度。

而當時才是2004年中，距離上次資料庫系統調整不過數月。使用者的提交請求被阻塞，就像千人樂迷要擠進只能容納幾百人的夜總會，站點開始遭遇"主要矛盾"，Benedetto說，這意味著MySpace永遠都會輕度落後於使用者需求。"有人花5分鐘都無法完成留言，因此使用者總是抱怨說網站已經完蛋了。"他補充道。

這一次的資料庫架構按照垂直分割模式設計，不同的資料庫服務於站點的不同功能，如登入、使用者資料和部落格。於是，站點的擴充套件性問題看似又可以告一段落了，可以歇一陣子。

垂直分割策略利於多個資料庫分擔訪問壓力，當使用者要求增加新功能時，MySpace將投入新的資料庫予以支援它。賬戶到達2百萬後，MySpace還從儲存裝置與資料庫伺服器直接互動的方式切換到SAN（StorageAreaNetwork，儲存區域網路）--用高頻寬、專門設計的網路將大量磁碟儲存裝置連線在一起，而資料庫連線到SAN。這項措施極大提升了系統效能、正常執行時間和可靠性，Benedetto說。

3.里程碑三：3百萬賬戶

當使用者繼續增加到3百萬後，垂直分割策略也開始難以為繼。儘管站點的各個應用被設計得高度獨立，但有些資訊必須共享。在這個架構裡，每個資料庫必須有各自的使用者表副本--MySpace授權使用者的電子花名冊。這就意味著一個使用者註冊時，該條賬戶記錄必須在9個不同資料庫上分別建立。但在個別情況下，如果其中某臺資料庫伺服器臨時不可到達，對應事務就會失敗，從而造成賬戶非完全建立，最終導致此使用者的該項服務無效。

另外一個問題是，個別應用如部落格增長太快，那麼專門為它服務的資料庫就有巨大壓力。2004年中，MySpace面臨Web開發者稱之為"向上擴充套件"對"向外擴充套件"（譯者注：ScaleUp和ScaleOut，也稱硬體擴充套件和軟體擴充套件）的抉擇--要麼擴充套件到更大更強、也更昂貴的伺服器上，要麼部署大量相對便宜的伺服器來分擔資料庫壓力。一般來說，大型站點傾向於向外擴充套件，因為這將讓它們得以保留透過增加伺服器以提升系統能力的後路。

但成功地向外擴充套件架構必須解決複雜的分散式計算問題，大型站點如Google、Yahoo和Amazon.com，都必須自行研發大量相關技術。以Google為例，它構建了自己的分散式檔案系統。

另外，向外擴充套件策略還需要大量重寫原來軟體，以保證系統能在分散式伺服器上執行。"搞不好，開發人員的所有工作都將白費"，Benedetto說。

因此，MySpace首先將重點放在了向上擴充套件上，花費了大約1個半月時間研究升級到32CPU伺服器以管理更大資料庫的問題。Benedetto說，"那時候，這個方案看似可能解決一切問題。"如穩定性，更棒的是對現有軟體幾乎沒有改動要求。

糟糕的是，高階伺服器極其昂貴，是購置同樣處理能力和記憶體速度的多臺伺服器總和的很多倍。而且，站點架構師預測，從長期來看，即便是巨型資料庫，最後也會不堪重負，Benedetto說，"換句話講，只要增長趨勢存在，我們最後無論如何都要走上向外擴充套件的道路。"

因此，MySpace最終將目光移到分散式計算架構--它在物理上分佈的眾多伺服器，整體必須邏輯上等同於單臺機器。拿資料庫來說，就不能再像過去那樣將應用拆分，再以不同資料庫分別支援，而必須將整個站點看作一個應用。現在，資料庫模型裡只有一個使用者表，支援部落格、個人資料和其他核心功能的資料都儲存在相同資料庫。

既然所有的核心資料邏輯上都組織到一個資料庫，那麼MySpace必須找到新的辦法以分擔負荷--顯然，執行在普通硬體上的單個資料庫伺服器是無能為力的。這次，不再按站點功能和應用分割資料庫，MySpace開始將它的使用者按每百萬一組分割，然後將各組的全部資料分別存入獨立的SQLServer例項。目前，MySpace的每臺資料庫伺服器實際執行兩個SQLServer例項，也就是說每臺伺服器服務大約2百萬使用者。Benedetto指出，以後還可以按照這種模式以更小粒度劃分架構，從而最佳化負荷分擔。

當然，還是有一個特殊資料庫儲存了所有賬戶的名稱和密碼。使用者登入後，儲存了他們其他資料的資料庫再接管服務。特殊資料庫的使用者表雖然龐大，但它只負責使用者登入，功能單一，所以負荷還是比較容易控制的。

4.里程碑四：

9百萬到1千7百萬賬戶2005年早期，賬戶達到9百萬後，MySpace開始用Microsoft的C#編寫ASP.NET程式。C#是C語言的最新派生語言，吸收了C++和Java的優點，依託於Microsoft.NET框架（Microsoft為軟體元件化和分散式計算而設計的模型架構）。ASP.NET則由編寫Web站點指令碼的ASP技術演化而來，是Microsoft目前主推的Web站點程式設計環境。

可以說是立竿見影，MySpace馬上就發現ASP.NET程式執行更有效率，與ColdFusion相比，完成同樣任務需消耗的處理器能力更小。據技術總監Whitcomb說，新程式碼需要150臺伺服器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，效能上升的另一個原因可能是在變換軟體平臺，並用新語言重寫程式碼的過程中，程式設計師複審並最佳化了一些功能流程。

最終，MySpace開始大規模遷移到ASP.NET。即便剩餘的少部分ColdFusion程式碼，也從Cold-Fusion伺服器搬到了ASP.NET，因為他們得到了BlueDragon.NET（喬治亞州阿爾法利塔NewAtlantaCommunications公司的產品，它能將ColdFusion程式碼自動重新編譯到Microsoft平臺）的幫助。

賬戶達到1千萬時，MySpace再次遭遇儲存瓶頸問題。SAN的引入解決了早期一些效能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量--即它從磁碟儲存系統讀寫資料的極限速度。

原因之一是每資料庫1百萬賬戶的分割策略，通常情況下的確可以將壓力均分到各臺伺服器，但現實並非一成不變。比如第七臺賬戶資料庫上線後，僅僅7天就被塞滿了，主要原因是佛羅里達一個樂隊的歌迷瘋狂註冊。

某個資料庫可能因為任何原因，在任何時候遭遇主要負荷，這時，SAN中繫結到該資料庫的磁碟儲存裝置簇就可能過載。"SAN讓磁碟I/O能力大幅提升了，但將它們繫結到特定資料庫的做法是錯誤的。"Benedetto說。

最初，MySpace透過定期重新分配SAN中資料，以讓其更為均衡的方法基本解決了這個問題，但這是一個人工過程，"大概需要兩個人全職工作。"Benedetto說。長期解決方案是遷移到虛擬儲存體系上，這樣，整個SAN被當作一個巨型儲存池，不再要求每個磁碟為特定應用服務。MySpace目前採用了一種新型SAN裝置--來自加利福尼亞州弗裡蒙特的3PARdata。

在3PAR的系統裡，仍能在邏輯上按容量劃分資料儲存，但它不再被繫結到特定磁碟或磁碟簇，而是散佈於大量磁碟。這就使均分資料訪問負荷成為可能。當資料庫需要寫入一組資料時，任何空閒磁碟都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經過載的磁碟陣列處。而且，因為多個磁碟都有資料副本，讀取資料時，也不會使SAN的任何元件過載。

當2005年春天賬戶數達到1千7百萬時，MySpace又啟用了新的策略以減輕儲存系統壓力，即增加資料快取層--位於Web伺服器和資料庫伺服器之間，其唯一職能是在記憶體中建立被頻繁請求資料物件的副本，如此一來，不訪問資料庫也可以向Web應用供給資料。

換句話說，100個使用者請求同一份資料，以前需要查詢資料庫100次，而現在只需1次，其餘都可從快取資料中獲得。當然如果頁面變化，快取的資料必須從記憶體擦除，然後重新從資料庫獲取--但在此之前，資料庫的壓力已經大大減輕，整個站點的效能得到提升。

快取區還為那些不需要記入資料庫的資料提供了驛站，比如為跟蹤使用者會話而建立的臨時檔案--Benedetto坦言他需要在這方面補課，"我是資料庫儲存狂熱分子，因此我總是想著將萬事萬物都存到資料庫。"但將像會話跟蹤這類的資料也存到資料庫，站點將陷入泥沼。

增加快取伺服器是"一開始就應該做的事情，但我們成長太快，以致於沒有時間坐下來好好研究這件事情。"Benedetto補充道。

5.里程碑五：

2千6百萬賬戶2005年中期，服務賬戶數達到2千6百萬時，MySpace切換到了還處於beta測試的SQLServer2005。轉換何太急？主流看法是2005版支援64位處理器。但Benedetto說，"這不是主要原因，儘管這也很重要；主要還是因為我們對記憶體的渴求。"支援64位的資料庫可以管理更多記憶體。

更多記憶體就意味著更高的效能和更大的容量。原來執行32位版本的SQLServer伺服器，能同時使用的記憶體最多隻有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQLServer2005和64位WindowsServer2003後，MySpace每臺伺服器配備了32G記憶體，後於2006年再次將配置標準提升到64G。

意外錯誤

如果沒有對系統架構的歷次修改與升級，MySpace根本不可能走到今天。但是，為什麼系統還經常吃撐著了？很多使用者抱怨的"意外錯誤"是怎麼引起的呢？

原因之一是MySpace對Microsoft的Web技術的應用已經進入連Microsoft自己也才剛剛開始探索的領域。比如11月，超出SQLServer最大同時連線數，MySpace系統崩潰。Benedetto說，這類可能引發系統崩潰的情況大概三天才會出現一次，但仍然過於頻繁了，以致惹人惱怒。一旦資料庫罷工，"無論這種情況什麼時候發生，未快取的資料都不能從SQLServer獲得，那麼你就必然看到一個'意外錯誤'提示。"他解釋說。

去年夏天，MySpace的Windows2003多次自動停止服務。後來發現是作業系統一個內建功能惹的禍--預防分散式拒絕服務攻擊（駭客使用很多客戶機向伺服器發起大量連線請求，以致伺服器癱瘓）。MySpace和其他很多頂級大站點一樣，肯定會經常遭受攻擊，但它應該從網路級而不是依靠Windows本身的功能來解決問題--否則，大量MySpace合法使用者連線時也會引起伺服器反擊。"我們花了大約一個月時間尋找Windows2003伺服器自動停止的原因。"Benedetto說。最後，透過Microsoft的幫助，他們才知道該怎麼通知伺服器："別開槍，是友軍。"

緊接著是在去年7月某個週日晚上，MySpace總部所在地洛杉磯停電，造成整個系統停運12小時。大型Web站點通常要在地理上分佈配置多個資料中心以預防單點故障。本來，MySpace還有其他兩個資料中心以應對突發事件，但Web伺服器都依賴於部署在洛杉磯的SAN。沒有洛杉磯的SAN，Web伺服器除了懇求你耐心等待，不能提供任何服務。Benedetto說，主資料中心的可靠性透過下列措施保證：可接入兩張不同電網，另有後備電源和一臺儲備有30天燃料的發電機。但在這次事故中，不僅兩張電網失效，而且在切換到備份電源的過程中，操作員燒掉了主動力線路。2007年中，MySpace在另兩個後備站點上也建設了SAN。這對分擔負荷大有幫助--正常情況下，每個SAN都能負擔三分之一的資料訪問量。而在緊急情況下，任何一個站點都可以獨立支撐整個服務，Benedetto說。MySpace仍然在為提高穩定性奮鬥，雖然很多使用者表示了足夠信任且能原諒偶現的錯誤頁面。"作為開發人員，我憎惡Bug，它太氣人了。"DanTanner這個31歲的德克薩斯軟體工程師說，他透過MySpace重新聯絡到了高中和大學同學。"不過，MySpace對我們的用處很大，因此我們可以原諒偶發的故障和錯誤。"Tanner說，如果站點某天出現故障甚至崩潰，恢復以後他還是會繼續使用。

這就是為什麼Drew在論壇裡咆哮時，大部分使用者都告訴他應該保持平靜，如果等幾分鐘，問題就會解決的原因。Drew無法平靜，他寫道，"我已經兩次給MySpace發郵件，而它說一小時前還是正常的，現在出了點問題……完全是一堆廢話。"另一個使用者回覆說，"畢竟它是免費的。"Benedetto坦承100%的可靠性不是他的目標。"它不是銀行，而是一個免費的服務。"他說。

換句話說，MySpace的偶發故障可能造成某人最後更新的個人資料丟失，但並不意味著網站弄丟了使用者的錢財。"關鍵是要認識到，與保證站點效能相比，丟失少許資料的故障是可接受的。"Benedetto說。所以，MySpace甘冒丟失2分鐘到2小時內任意點資料的危險，在SQLServer配置裡延長了"checkpoint"操作--它將待更新資料永久記錄到磁碟--的間隔時間，因為這樣做可以加快資料庫的執行。Benedetto說，同樣，開發人員還經常在幾個小時內就完成構思、編碼、測試和釋出全過程。這有引入Bug的風險，但這樣做可以更快實現新功能。而且，因為進行大規模真實測試不具可行性，他們的測試通常是在僅以部分活躍使用者為物件，且使用者對軟體新功能和改進不知就裡的情況下進行的。因為事實上不可能做真實的載入測試，他們做的測試通常都是針對站點。"我們犯過大量錯誤，"Benedetto說，"但到頭來，我認為我們做對的還是比做錯的多。"