如果沒有任何經(jīng)驗，學習如何擴展一個網(wǎng)站是相當困難的。假設現(xiàn)在你有很多像highscalability.com那樣網(wǎng)站，你需要一些好的解決方案來擴展它們，但是世上沒有“萬能藥”，沒有哪個解決方案可以適應所有網(wǎng)站的需要。你不得不自己動手，通過不斷地思考來找到一個能滿足你的需求的解決方案。我也是這樣做的。

幾年以前，我的老板來找我，然后對我說：“我們有一個新項目想交給你來做。主要是一個網(wǎng)站的重構，在一個月內，這個站點已經(jīng)擁有100萬個用戶了。你必須重新構建這個網(wǎng)站，來確保我們可以應對將來逐漸增加的用戶數(shù)量。”我已經(jīng)是一個有經(jīng)驗的程序員了，但是在這些方面并不擅長，所以我不得不開始學習如何擴展一個網(wǎng)站——整個過程歷盡了艱難困苦。(相關文章推薦：重構：“為什么”和“怎么做”)

這個網(wǎng)站的后臺軟件是一個PHP內容管理系統(tǒng)，基于Smarty和MySQL。第一個任務是找到一個合適的托管公司，這個公司需要具有豐富的經(jīng)驗，可以為我們管理服務器。經(jīng)過一番調查研究，我們找到了一家這樣的公司，然后告訴他們我們的需求，他們給我們推薦的配置如下：

負載均衡器 (+Fallback) 
2個Web服務器 
MySQL服務器(+Fallback) 
開發(fā)機器 
他們說，這就是我們需要的所有東西了——對此，我們深信不疑。我們最后得到的配置是：

負載均衡器 (單核, 1GB 內存, Pound) 
2個Web服務器 (雙核, 4GB 內存, Apache) 
MySQL服務器 (四核, 8GB 內存) 
開發(fā)機器 (單核, 1GB 內存) 
這個配置十分的基礎，并沒有做進一步優(yōu)化。為了同步文件(PHP和媒體文件)，他們建立了一個active-active DRBD。最后，重構開始了——當然，我們很興奮。一大早，我們把域名切換到了新的IP上，運行我們的監(jiān)控腳本，然后盯著屏幕看。我們馬上在這些機器上看到了流量，一切似乎都工作的很好。頁面載入的很快，MySQL負擔了大量的查詢任務，我們所有人都很高興。

然后，突然我們的電話開始響個不停：“我們不能訪問你們的網(wǎng)站了，這是怎么回事？”我們看了一下我們的監(jiān)控軟件，事實的確如此——服務器都被frozen了，站點處于離線狀態(tài)!當然，我們做的第一件事情是打電話給我們的托管服務提供商：“我們的所有服務器都死機了。這是怎么回事？”他們答應檢查一下機器，一會再打過來。這個電話來了：“你的系統(tǒng)根本就無法插手。你做了什么？它完全被搞砸了。”他們停止了負載均衡器，然后讓我觀察一下其中一個Web服務器。看到那個index.php文件，我大吃一驚。它包含一些奇怪的C代碼片段，錯誤消息和一些看起來像日志文件的東西。經(jīng)過進一步的調查，我們發(fā)現(xiàn)是DRBD引發(fā)了這次事故。

"殺死"你的服務器的方法之一

把Smarty compile和模板緩存放到一個高負載的active-active DRBD集群上，那么你的服務器將會掛掉!當我們的托管服務提供商修復了Web服務器的時候，為了在這些服務器的本地文件系統(tǒng)上存儲Smarty緩存文件，我重寫了部分CMS代碼。我們再次上線了!

現(xiàn)在是午后。這個網(wǎng)站通常在下午的晚些時候到傍晚達到峰值。晚上，幾乎沒有什么流量。我們一直盯著監(jiān)控軟件，我們所有人都緊張得不得了。這個網(wǎng)站可以被載入，但是后來，系統(tǒng)負載越高，響應就越慢。我增加了Smarty模板緩存的生存期，希望這能產(chǎn)生效果——但是很可惜，這并沒有產(chǎn)生效果!不久，服務器開始給出超時提示，空白頁面和錯誤信息。有兩臺機器不能處理負載。

我們的客戶這個時候有一點緊張，但是他說：OK，重構通常會引發(fā)一些問題的。只要你能很快地修復它，那就沒事了!

我們需要一個計劃來減少負載，然后，我們和我們的托管服務提供商討論了這個問題。他們的一個系統(tǒng)管理員提出了一個好主意：“伙計，你的服務器現(xiàn)在運行在一個非常常見的Apache+mod_php架構上。把你的Web服務器換成Lighttpd怎么樣？它是一個相當小項目，但是維基百科都在使用它。”我們同意了。(相關文章推薦：更好的選擇 細數(shù)Apache服務器的四個替代者)

"殺死"你的服務器的方法之二

把一個開箱即用的Web服務器架設在你的機器上，并且一點也沒有對它進行優(yōu)化，那么你的服務器將會掛掉!那個管理員盡了他的最大努力，盡快地重新配置了所有的Web服務器。他拋棄了Apache，然后切換到Lighttpd+FastCGI+Xcache上來。后來，當我們重新上線的時候，我們幾乎沒有再感受到壓力。這次，這些服務器會維持多長時間呢？

這些服務器運行的出奇地好。負載比以前低很多，平均響應時間也不錯。我們徹底放心了，然后我們都回家睡覺了。天已經(jīng)很晚了，我們認為沒有其他的事情需要我們做了。第二天，網(wǎng)站運行的相當好，但是在高峰時段，它一直接近于崩潰的邊緣。我們發(fā)現(xiàn)MySQL是瓶頸，我們再次打電話給我們的托管服務提供商。他們建議在每個Web服務器上用MySQL從服務器進行MySQL的主-從同步。

"殺死"你的服務器的方法之三

再強大的數(shù)據(jù)庫服務器也有它的極限，當你到達它的極限的時候，你的服務器將會掛掉!在這種情況下，某些時候你的數(shù)據(jù)庫會變得十分緩慢，以至于隊列中大量的網(wǎng)絡連接會再次“殺死”我們的Web服務器。不幸的是這個問題很難修復。內容管理系統(tǒng)在這方面十分的簡單，它本身并不支持單獨地讀取和寫入SQL查詢。重寫這一切花了很長時間，但是相對于每分鐘都遭遇到掛起休眠來說，是相當值得的。

MySQL同步真的成功了，網(wǎng)站最終穩(wěn)定了!在接下來的幾周，幾個月里，網(wǎng)站取得了成功，用戶的數(shù)量開始不斷地增加。流量再次超過我們的資源限制，這只是時間的問題。

"殺死"你的服務器的方法之四

不提前作規(guī)劃，你的服務器可能會掛掉!

幸運的是，我們一直在思考，并且一直在做規(guī)劃。我們優(yōu)化了代碼，減少了每個頁面載入的時候需要的SQL查詢的數(shù)量，我們意外地發(fā)現(xiàn)了MemCached這個好東東。首先，我們在一些核心功能上添加了對MemCached的支持，在一些重量級(運行緩慢)的功能上我們也添加了對MemCached的支持。當我們把這些變更部署以后，我們簡直不能相信這個結果——這感覺有點像發(fā)現(xiàn)了“圣杯”。我們每秒查詢的數(shù)量至少降低了50%。我們決定更多地使用MemCached，而不是購買另外一個Web服務器。

"殺死"你的服務器的方法之五

忘記做緩存，你會浪費很多錢，而且，你的服務器還會掛掉!事實證明，MemCached幫助我們減少了70%-80%的MySQL服務器上負載，同時，在Web服務器上，也產(chǎn)生了巨大的性能提升。頁面載入的相當快。

最終，我們的配置看起來似乎是完美的。即使在高峰時段，我們也無須再擔心崩潰或頁面響應緩慢了。我們搞定它了嗎？不!一臺藍色的Web服務器開始有一點響應緩慢了。然后出現(xiàn)了一些錯誤消息，空白頁面等等。這個系統(tǒng)負載能力很不錯，在大多數(shù)情況下服務器也都在工作，但是只是在“大多數(shù)情況下”而已。

"殺死"你的服務器的方法之六

把成百上千個小文件放在一個文件夾里，當索引節(jié)點耗盡的時候，你的服務器將會掛掉!

是的，你沒有看錯。我們過去只是關注MySQL，PHP和Web服務器本身，并沒有太關注文件系統(tǒng)。Smarty緩存文件存儲在本地文件系統(tǒng)里——所有的緩存文件都存儲在同一個目錄下。解決方案是把Smarty放在一個專用的ReiserFS分區(qū)里。另外，我們還打開了Smarty的“use_subdirs”選項。

在過去的幾年里，我們一直在優(yōu)化頁面。我們把Smarty緩存放到了memcached中。為了更快速地處理靜態(tài)文件，我們安裝了Varnish來減少I/O負載。我們還切換到了Nginx(Lighttpd會隨機的產(chǎn)生error 500的消息)，安裝了更多的內存，購買了更好的硬件，更多的硬件......這個列表永遠不會結束。

總結

擴展一個網(wǎng)站是一個永遠不會結束的過程。當你解決了一個瓶頸以后，很可能馬上會遇到下一個瓶頸。永遠都不要這樣想：“就是這樣，我們大功告成了”然后就靠邊站了。這會“殺死”你的服務器，甚至是你的業(yè)務。規(guī)劃和學習是一個持續(xù)的過程。如果你因為缺乏經(jīng)驗或資源而不能自己完成這個工作，那么可以找一個有能力勝任這個工作，而且很可靠的合作伙伴，和它一起來做這個工作。永遠都不要停止和你的團隊和合作伙伴溝通當前遇到的一些問題和即將會遇到的一些問題。思考在前才能爭取主動。