從MySpace的六次重構(gòu)經(jīng)歷,來認識分布式系統(tǒng)到底該如何創(chuàng)建
1
頂一下收藏作者：
Roster | 推薦人：
草根幫主(信譽值:85372)在2007-7-27 12:發(fā)布，已有 108人閱讀過：
這
是我在網(wǎng)上無意中看到的一篇文章,介紹了myspace的六次重構(gòu),對于做海量用戶系統(tǒng)的朋友來說,應(yīng)該能從中受到很多啟發(fā).
在每個里程碑，站點負擔(dān)都會超過底層系統(tǒng)部分組件的最大載荷，特別是數(shù)據(jù)庫和存儲系統(tǒng)。接著，功能出現(xiàn)問題，用戶失聲尖叫。最后，技術(shù)團隊必須為此修訂系統(tǒng)策略。
雖然自2005年早期，站點賬戶數(shù)超過7百萬后，系統(tǒng)架構(gòu)到目前為止保持了相對穩(wěn)定，但MySpace仍然在為SQL Server支持的同時連接數(shù)等方面繼續(xù)攻堅，Benedetto說，"我們已經(jīng)盡可能把事情做到最好"。
里程碑一：50萬賬戶
按Benedetto 的說法，MySpace最初的系統(tǒng)很小，只有兩臺Web服務(wù)器和一個數(shù)據(jù)庫服務(wù)器。那時使用的是Dell雙CPU、4G內(nèi)存的系統(tǒng)。
單個數(shù)據(jù)庫就意味著所有數(shù)據(jù)都存儲在一個地方，再由兩臺Web服務(wù)器分擔(dān)處理用戶請求的工作量。但就像MySpace后來的幾次底層系統(tǒng)修訂時的情況一樣，三服務(wù)器架構(gòu)很快不堪重負。此后一個時期內(nèi)，MySpace基本是通過添置更多Web服務(wù)器來對付用戶暴增問題的。
但到在2004年早期，MySpace用戶數(shù)增長到50萬后，數(shù)據(jù)庫服務(wù)器也已開始汗流浹背。
但和Web服務(wù)器不同，增加數(shù)據(jù)庫可沒那么簡單。如果一個站點由多個數(shù)據(jù)庫支持，設(shè)計者必須考慮的是，如何在保證數(shù)據(jù)一致性的前提下，讓多個數(shù)據(jù)庫分擔(dān)壓力。
在第二代架構(gòu)中，MySpace運行在3個SQL Server數(shù)據(jù)庫服務(wù)器上——一個為主，所有的新數(shù)據(jù)都向它提交，然后由它復(fù)制到其他兩個；另兩個全力向用戶供給數(shù)據(jù)，用以在博客和個人資料欄顯示。這種方式在一段時間內(nèi)效果很好——只要增加數(shù)據(jù)庫服務(wù)器，加大硬盤，就可以應(yīng)對用戶數(shù)和訪問量的增加。
里程碑二：1-2百萬賬戶
MySpace注冊數(shù)到達1百萬至2百萬區(qū)間后，數(shù)據(jù)庫服務(wù)器開始受制于I/O容量——即它們存取數(shù)據(jù)的速度。而當(dāng)時才是2004年中，距離上次數(shù)據(jù)庫系統(tǒng)調(diào)整不過數(shù)月。用戶的提交請求被阻塞，就像千人樂迷要擠進只能容納幾百人的夜總會，站點開始遭遇"主要矛盾"，Benedetto說，這意味著MySpace永遠都會輕度落后于用戶需求。
"有人花5分鐘都無法完成留言，因此用戶總是抱怨說網(wǎng)站已經(jīng)完蛋了。"他補充道。
這一次的數(shù)據(jù)庫架構(gòu)按照垂直分割模式設(shè)計，不同的數(shù)據(jù)庫服務(wù)于站點的不同功能，如登錄、用戶資料和博客。于是，站點的擴展性問題看似又可以告一段落了，可以歇一陣子。
垂直分割策略利于多個數(shù)據(jù)庫分擔(dān)訪問壓力，當(dāng)用戶要求增加新功能時，MySpace將投入新的數(shù)據(jù)庫予以支持它。賬戶到達2百萬后，MySpace還從存儲設(shè)備與數(shù)據(jù)庫服務(wù)器直接交互的方式切換到SAN（Storage Area Network，存儲區(qū)域網(wǎng)絡(luò)）——用高帶寬、專門設(shè)計的網(wǎng)絡(luò)將大量磁盤存儲設(shè)備連接在一起，而數(shù)據(jù)庫連接到SAN。這項措施極大提升了系統(tǒng)性能、正常運行時間和可靠性，Benedetto說。
里程碑三：3百萬賬戶
當(dāng)用戶繼續(xù)增加到3百萬后，垂直分割策略也開始難以為繼。盡管站點的各個應(yīng)用被設(shè)計得高度獨立，但有些信息必須共享。在這個架構(gòu)里，每個數(shù)據(jù)庫必須有各自的用戶表副本——MySpace授權(quán)用戶的電子花名冊。這就意味著一個用戶注冊時，該條賬戶記錄必須在9個不同數(shù)據(jù)庫上分別創(chuàng)建。但在個別情況下，如果其中某臺數(shù)據(jù)庫服務(wù)器臨時不可到達，對應(yīng)事務(wù)就會失敗，從而造成賬戶非完全創(chuàng)建，最終導(dǎo)致此用戶的該項服務(wù)無效。
另外一個問題是，個別應(yīng)用如博客增長太快，那么專門為它服務(wù)的數(shù)據(jù)庫就有巨大壓力。
2004年中，MySpace面臨Web開發(fā)者稱之為"向上擴展"對"向外擴展"（譯者注：Scale Up和Scale Out，也稱硬件擴展和軟件擴展）的抉擇——要么擴展到更大更強、也更昂貴的服務(wù)器上，要么部署大量相對便宜的服務(wù)器來分擔(dān)數(shù)據(jù)庫壓力。一般來說，大型站點傾向于向外擴展，因為這將讓它們得以保留通過增加服務(wù)器以提升系統(tǒng)能力的后路。
但成功地向外擴展架構(gòu)必須解決復(fù)雜的分布式計算問題，大型站點如Google、Yahoo和Amazon.com，都必須自行研發(fā)大量相關(guān)技術(shù)。以Google為例，它構(gòu)建了自己的分布式文件系統(tǒng)。
另外，向外擴展策略還需要大量重寫原來軟件，以保證系統(tǒng)能在分布式服務(wù)器上運行。"搞不好，開發(fā)人員的所有工作都將白費"，Benedetto說。
因此，MySpace首先將重點放在了向上擴展上，花費了大約1個半月時間研究升級到32CPU服務(wù)器以管理更大數(shù)據(jù)庫的問題。Benedetto說，"那時候，這個方案看似可能解決一切問題。"如穩(wěn)定性，更棒的是對現(xiàn)有軟件幾乎沒有改動要求。
糟糕的是，高端服務(wù)器極其昂貴，是購置同樣處理能力和內(nèi)存速度的多臺服務(wù)器總和的很多倍。而且，站點架構(gòu)師預(yù)測，從長期來看，即便是巨型數(shù)據(jù)庫，最后也會不堪重負，Benedetto說，"換句話講，只要增長趨勢存在，我們最后無論如何都要走上向外擴展的道路。"
因此，MySpace最終將目光移到分布式計算架構(gòu)——它在物理上分布的眾多服務(wù)器，整體必須邏輯上等同于單臺機器。拿數(shù)據(jù)庫來說，就不能再像過去那樣將應(yīng)用拆分，再以不同數(shù)據(jù)庫分別支持，而必須將整個站點看作一個應(yīng)用?，F(xiàn)在，數(shù)據(jù)庫模型里只有一個用戶表，支持博客、個人資料和其他核心功能的數(shù)據(jù)都存儲在相同數(shù)據(jù)庫。
既然所有的核心數(shù)據(jù)邏輯上都組織到一個數(shù)據(jù)庫，那么MySpace必須找到新的辦法以分擔(dān)負荷——顯然，運行在普通硬件上的單個數(shù)據(jù)庫服務(wù)器是無能為力的。這次，不再按站點功能和應(yīng)用分割數(shù)據(jù)庫，MySpace開始將它的用戶按每百萬一組分割，然后將各組的全部數(shù)據(jù)分別存入獨立的SQL Server實例。目前，MySpace的每臺數(shù)據(jù)庫服務(wù)器實際運行兩個SQL Server實例，也就是說每臺服務(wù)器服務(wù)大約2百萬用戶。Benedetto指出，以后還可以按照這種模式以更小粒度劃分架構(gòu)，從而優(yōu)化負荷分擔(dān)。
當(dāng)然，還是有一個特殊數(shù)據(jù)庫保存了所有賬戶的名稱和密碼。用戶登錄后，保存了他們其他數(shù)據(jù)的數(shù)據(jù)庫再接管服務(wù)。特殊數(shù)據(jù)庫的用戶表雖然龐大，但它只負責(zé)用戶登錄，功能單一，所以負荷還是比較容易控制的。
里程碑四：9百萬到1千7百萬賬戶
2005年早期，賬戶達到9百萬后，MySpace開始用Microsoft的C#編寫ASP.NET程序。C#是C語言的最新派生語言，吸收了C++和Java的優(yōu)點，依托于Microsoft .NET框架（Microsoft為軟件組件化和分布式計算而設(shè)計的模型架構(gòu)）。ASP.NET則由編寫Web站點腳本的ASP技術(shù)演化而來，是Microsoft目前主推的Web站點編程環(huán)境。
可以說是立竿見影， MySpace馬上就發(fā)現(xiàn)ASP.NET程序運行更有效率，與ColdFusion相比，完成同樣任務(wù)需消耗的處理器能力更小。據(jù)技術(shù)總監(jiān)Whitcomb說，新代碼需要150臺服務(wù)器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，性能上升的另一個原因可能是在變換軟件平臺，并用新語言重寫代碼的過程中，程序員復(fù)審并優(yōu)化了一些功能流程。
最終，MySpace開始大規(guī)模遷移到ASP.NET。即便剩余的少部分ColdFusion代碼，也從Cold-Fusion服務(wù)器搬到了ASP.NET，因為他們得到了BlueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的產(chǎn)品，它能將ColdFusion代碼自動重新編譯到Microsoft平臺）的幫助。
賬戶達到1千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性能問題，但站點目前的要求已經(jīng)開始周期性超越SAN的I/O容量——即它從磁盤存儲系統(tǒng)讀寫數(shù)據(jù)的極限速度。
原因之一是每數(shù)據(jù)庫1百萬賬戶的分割策略，通常情況下的確可以將壓力均分到各臺服務(wù)器，但現(xiàn)實并非一成不變。比如第七臺賬戶數(shù)據(jù)庫上線后，僅僅7天就被塞滿了，主要原因是佛羅里達一個樂隊的歌迷瘋狂注冊。
某個數(shù)據(jù)庫可能因為任何原因，在任何時候遭遇主要負荷，這時，SAN中綁定到該數(shù)據(jù)庫的磁盤存儲設(shè)備簇就可能過載。"SAN讓磁盤I/O能力大幅提升了，但將它們綁定到特定數(shù)據(jù)庫的做法是錯誤的。"Benedetto說。
最初，MySpace通過定期重新分配SAN中數(shù)據(jù)，以讓其更為均衡的方法基本解決了這個問題，但這是一個人工過程，"大概需要兩個人全職工作。"Benedetto說。
長期解決方案是遷移到虛擬存儲體系上，這樣，整個SAN被當(dāng)作一個巨型存儲池，不再要求每個磁盤為特定應(yīng)用服務(wù)。MySpace目前采用了一種新型SAN設(shè)備——來自加利福尼亞州弗里蒙特的3PARdata。
在3PAR的系統(tǒng)里，仍能在邏輯上按容量劃分數(shù)據(jù)存儲，但它不再被綁定到特定磁盤或磁盤簇，而是散布于大量磁盤。這就使均分數(shù)據(jù)訪問負荷成為可能。當(dāng)數(shù)據(jù)庫需要寫入一組數(shù)據(jù)時，任何空閑磁盤都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經(jīng)過載的磁盤陣列處。而且，因為多個磁盤都有數(shù)據(jù)副本，讀取數(shù)據(jù)時，也不會使SAN的任何組件過載。
當(dāng)2005年春天賬戶數(shù)達到1千7百萬時，MySpace又啟用了新的策略以減輕存儲系統(tǒng)壓力，即增加數(shù)據(jù)緩存層——位于Web服務(wù)器和數(shù)據(jù)庫服務(wù)器之間，其唯一職能是在內(nèi)存中建立被頻繁請求數(shù)據(jù)對象的副本，如此一來，不訪問數(shù)據(jù)庫也可以向Web應(yīng)用供給數(shù)據(jù)。換句話說，100個用戶請求同一份資料，以前需要查詢數(shù)據(jù)庫100次，而現(xiàn)在只需1次，其余都可從緩存數(shù)據(jù)中獲得。當(dāng)然如果頁面變化，緩存的數(shù)據(jù)必須從內(nèi)存擦除，然后重新從數(shù)據(jù)庫獲取——但在此之前，數(shù)據(jù)庫的壓力已經(jīng)大大減輕，整個站點的性能得到提升。
緩存區(qū)還為那些不需要記入數(shù)據(jù)庫的數(shù)據(jù)提供了驛站，比如為跟蹤用戶會話而創(chuàng)建的臨時文件——Benedetto坦言他需要在這方面補課，"我是數(shù)據(jù)庫存儲狂熱分子，因此我總是想著將萬事萬物都存到數(shù)據(jù)庫。"但將像會話跟蹤這類的數(shù)據(jù)也存到數(shù)據(jù)庫，站點將陷入泥沼。
增加緩存服務(wù)器是"一開始就應(yīng)該做的事情，但我們成長太快，以致于沒有時間坐下來好好研究這件事情。"Benedetto補充道。
里程碑五：2千6百萬賬戶
2005年中期，服務(wù)賬戶數(shù)達到2千6百萬時，MySpace切換到了還處于beta測試的SQL Server 2005。轉(zhuǎn)換何太急？主流看法是2005版支持64位處理器。但Benedetto說，"這不是主要原因，盡管這也很重要；主要還是因為我們對內(nèi)存的渴求。"支持64位的數(shù)據(jù)庫可以管理更多內(nèi)存。
更多內(nèi)存就意味著更高的性能和更大的容量。原來運行32位版本的SQL Server服務(wù)器，能同時使用的內(nèi)存最多只有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQL Server 2005和64位Windows Server 2003后，MySpace每臺服務(wù)器配備了32G內(nèi)存，后于2006年再次將配置標(biāo)準(zhǔn)提升到64G。
意外錯誤
如果沒有對系統(tǒng)架構(gòu)的歷次修改與升級，MySpace根本不可能走到今天。但是，為什么系統(tǒng)還經(jīng)常吃撐著了？很多用戶抱怨的"意外錯誤"是怎么引起的呢？
原因之一是MySpace對Microsoft的Web技術(shù)的應(yīng)用已經(jīng)進入連Microsoft自己也才剛剛開始探索的領(lǐng)域。比如11月，超出SQL Server最大同時連接數(shù)，MySpace系統(tǒng)崩潰。Benedetto說，這類可能引發(fā)系統(tǒng)崩潰的情況大概三天才會出現(xiàn)一次，但仍然過于頻繁了，以致惹人惱怒。一旦數(shù)據(jù)庫罷工，"無論這種情況什么時候發(fā)生，未緩存的數(shù)據(jù)都不能從SQL Server獲得，那么你就必然看到一個‘意外錯誤‘提示。"他解釋說。
去年夏天，MySpace的Windows 2003多次自動停止服務(wù)。后來發(fā)現(xiàn)是操作系統(tǒng)一個內(nèi)置功能惹的禍——預(yù)防分布式拒絕服務(wù)攻擊（黑客使用很多客戶機向服務(wù)器發(fā)起大量連接請求，以致服務(wù)器癱瘓）。MySpace和其他很多頂級大站點一樣，肯定會經(jīng)常遭受攻擊，但它應(yīng)該從網(wǎng)絡(luò)級而不是依靠Windows本身的功能來解決問題——否則，大量MySpace合法用戶連接時也會引起服務(wù)器反擊。
"我們花了大約一個月時間尋找Windows 2003服務(wù)器自動停止的原因。"Benedetto說。最后，通過Microsoft的幫助，他們才知道該怎么通知服務(wù)器："別開槍，是友軍。"
緊接著是在去年7月某個周日晚上，MySpace總部所在地洛杉磯停電，造成整個系統(tǒng)停運12小時。大型Web站點通常要在地理上分布配置多個數(shù)據(jù)中心以預(yù)防單點故障。本來，MySpace還有其他兩個數(shù)據(jù)中心以應(yīng)對突發(fā)事件，但Web服務(wù)器都依賴于部署在洛杉磯的SAN。沒有洛杉磯的SAN，Web服務(wù)器除了懇求你耐心等待，不能提供任何服務(wù)。
Benedetto說，主數(shù)據(jù)中心的可靠性通過下列措施保證：可接入兩張不同電網(wǎng)，另有后備電源和一臺儲備有30天燃料的發(fā)電機。但在這次事故中，不僅兩張電網(wǎng)失效，而且在切換到備份電源的過程中，操作員燒掉了主動力線路。
2007年中，MySpace在另兩個后備站點上也建設(shè)了SAN。這對分擔(dān)負荷大有幫助——正常情況下，每個SAN都能負擔(dān)三分之一的數(shù)據(jù)訪問量。而在緊急情況下，任何一個站點都可以獨立支撐整個服務(wù)，Benedetto說。
MySpace仍然在為提高穩(wěn)定性奮斗，雖然很多用戶表示了足夠信任且能原諒偶現(xiàn)的錯誤頁面。
"作為開發(fā)人員，我憎惡Bug，它太氣人了。"Dan Tanner這個31歲的德克薩斯軟件工程師說，他通過MySpace重新聯(lián)系到了高中和大學(xué)同學(xué)。"不過，MySpace對我們的用處很大，因此我們可以原諒偶發(fā)的故障和錯誤。" Tanner說，如果站點某天出現(xiàn)故障甚至崩潰，恢復(fù)以后他還是會繼續(xù)使用。
這就是為什么Drew在論壇里咆哮時，大部分用戶都告訴他應(yīng)該保持平靜，如果等幾分鐘，問題就會解決的原因。Drew無法平靜，他寫道，"我已經(jīng)兩次給MySpace發(fā)郵件，而它說一小時前還是正常的，現(xiàn)在出了點問題……完全是一堆廢話。"另一個用戶回復(fù)說，"畢竟它是免費的。"Benedetto坦承100%的可靠性不是他的目標(biāo)。"它不是銀行，而是一個免費的服務(wù)。"他說。
換句話說，MySpace的偶發(fā)故障可能造成某人最后更新的個人資料丟失，但并不意味著網(wǎng)站弄丟了用戶的錢財。"關(guān)鍵是要認識到，與保證站點性能相比，丟失少許數(shù)據(jù)的故障是可接受的。"Benedetto說。所以，MySpace甘冒丟失2分鐘到2小時內(nèi)任意點數(shù)據(jù)的危險，在SQL Server配置里延長了"checkpoint"操作——它將待更新數(shù)據(jù)永久記錄到磁盤——的間隔時間，因為這樣做可以加快數(shù)據(jù)庫的運行。
Benedetto說，同樣，開發(fā)人員還經(jīng)常在幾個小時內(nèi)就完成構(gòu)思、編碼、測試和發(fā)布全過程。這有引入Bug的風(fēng)險，但這樣做可以更快實現(xiàn)新功能。而且，因為進行大規(guī)模真實測試不具可行性，他們的測試通常是在僅以部分活躍用戶為對象，且用戶對軟件新功能和改進不知就里的情況下進行的。因為事實上不可能做真實的加載測試，他們做的測試通常都是針對站點。
"我們犯過大量錯誤，"Benedetto說，"但到頭來，我認為我們做對的還是比做錯的多。"
MySpace Tech Roster
January 16, 2007
By David F. Carr
我的一些思考:
看完這篇文章首先很驚訝myspace居然是基于.net平臺的系統(tǒng),windows2003+asp.net+IIS+SQLSERVER,雖然我是一個純粹的MS技術(shù)者,但是對于MS的WEB應(yīng)用總是有點疑慮,我的擔(dān)心大概是來自于到處都在鼓吹的LAMP,我并不敵視開源,但是我承認,它給我?guī)砹撕艽蟮膲毫?看了這篇文章,我有點慶幸也有點笑自己之前的迂腐,其實對于技術(shù)來說,優(yōu)劣只在于開發(fā)者本身,myspace的六次重構(gòu),很好的說明了這一點.
我們常常講分布式系統(tǒng),這個概念很大,簡單點說,就是把系統(tǒng)給拆分開來,把本來一臺服務(wù)器做的事,分到兩臺服務(wù)器來做.如果只在一臺服務(wù)器上部署兩個程序來執(zhí)行之前一個程序做的事,我認為那不叫分布式,也是完全沒必要的,分布式的原則是"后分布"(lazy distribute),因為這本身是件損耗性能的工作,如果不能通過它來獲得明顯的性能提升,那為什么還要分布式?
myspace的六次重構(gòu)基本都是圍繞數(shù)據(jù)庫來進行的,做了這么多年的WEB應(yīng)用,我早就知道了數(shù)據(jù)庫對于一個網(wǎng)站來說是多么的重要.在程序沒有額外的問題的基礎(chǔ)上,隨著流量的增大,最先出現(xiàn)問題的,往往就是數(shù)據(jù)庫.癥狀通常為,數(shù)據(jù)庫查詢/更新變的非常非常的慢,經(jīng)常超時等.
這個時候,我們能做的事非常有限,無非是調(diào)整下SQLServer的內(nèi)存大小,給服務(wù)器加內(nèi)存換速度更快的硬盤等.如果要認真的解決這個問題,對于一般的開發(fā)者來說,都會自然的想到拆庫.海量的數(shù)據(jù)查詢對于SQL來說本就是不該存在的,無論你的數(shù)據(jù)庫優(yōu)化的多么好,比如你用的Oracle,數(shù)據(jù)吞吐量很大,難道查詢100W的記錄會比SQL查詢1W條更快嗎?拆庫又分本地數(shù)據(jù)庫分多個表和多個服務(wù)器分多個庫,執(zhí)行順序為由前到後,當(dāng)數(shù)據(jù)庫的壓力由海量查詢變成磁盤IO之后,就需要更多的數(shù)據(jù)庫服務(wù)器了.
除了硬件手段,更常用的是采用緩存.myspace直到第四次改版的后期才開始正式的引入緩存策略,這確實是個失誤,如果從最開始就考慮到緩存的作用的話,那么數(shù)據(jù)庫服務(wù)器至少不會膨脹的那么快,也可以有更多的時間來思考更好的架構(gòu).當(dāng)然,正如Benedetto所說,這是件一開始就該考慮的事,但是myspace成長的太快了.
不是誰都有機會來為一個流量在世界上排名前10的網(wǎng)站來設(shè)計架構(gòu),因此myspace的后面的若干次重構(gòu),對于普通的開發(fā)者已經(jīng)很難接觸了,我認為,在第三個里程碑時,也就是通過服務(wù)器的橫向擴展來實現(xiàn)的分布式,已經(jīng)足夠支持巨型網(wǎng)站的應(yīng)用了.myspace是個交互型特別強的網(wǎng)站,用戶執(zhí)行的請求數(shù)會遠大于一般的網(wǎng)站,這也是它巨大的數(shù)據(jù)庫壓力的來源.
最后總結(jié)一下WEB系統(tǒng)分布式的要點:
1.不到需要,絕對不要分布
2.分布式應(yīng)該圍繞數(shù)據(jù)庫展開
3.分布式系統(tǒng)本身具有很強的擴展性,系統(tǒng)性能的提升和硬件的增加是線性關(guān)系.
感想寫的比較亂,基本想到什么寫的什么,各位看官各取所需即是.
