大型高效能網站的十項規則

標籤：執行   使用者id   tables   bbs   操作性   應用程式   架構   關於   購物車   

在公司，見過多種不同類型的網站和系統，有好也有差。其中有些系統擁有良好的伺服器/網路架構，並且進行了合理的調整和監控；然而一般的系統都會有安全和效能上的問題，不能良好運行，也無法變得更流行。

在中國， 開源的LAMP棧是最流行的網路架構，它使用PHP開發，運行在Apache伺服器上，以MySQL作為資料庫，所有這些都運行在Linux上。它是個可靠的平台，運行良好，是現在全球最流行的Internet系統架構。然而，我們很難對其規模進行正確的擴充並保持安全性，因為每個應用程式層都有其自身的問題、缺陷和最佳實務。我們的工作就是協助企業用最低的操作成本來建立並運行高效能的、可伸縮的、安全的系統，因此對於這類問題我們有很豐富的經驗。

當前的實際情況是，很多網站都是由開發人員快速而廉價地建立，通常沒有任何IT人員或者經理，只是由程式員來管理系統。造成的結果是，雖然花費很低的成本，網站就可以開始運行，但是當擁有大量使用者、 需要擴充規模的時候，通常就會面臨真正的問題。畢竟，中國擁有三億八千萬的Internet使用者，如果其中的0.01%訪問這個網站，就很容易引發25 萬~50萬的頁面訪問量。這些問題在各個層級上都會產生，下面總結的規則是對最一般的問題進行概述，並且說明為什麼這些規則如此重要，以及最好採用什麼方 法來修正它們。遵循這些建議的網站會提高它的延展性、安全性以及操作上的穩定性。

1. 使用合適的會話管理

第一個想到的擴充系統的方法就是添加更多硬體。例如，使用兩台伺服器而不是一台。這聽著合理，但會產生潛在問題：會話管理。這對Java程式來說是很嚴重的問題，在PHP中也會產生可延展性問題， 對於資料庫的負載尤其如此。

會話被定義為單獨的終端使用者登入或者串連一段時間，其中通常會包含多個TCP/IP的HTTP串連、幾個Web頁面，通常還包括幾十個甚至上百個頁面元素，如架構、菜單、Ajax

更新等。所有這些 HTTP請求都需要知道使用者是誰，才能滿足安全的要求，並向使用者傳送適當的內容，因為這些都是會話的組成部分。通常每個會話都會包括相互關聯的會話資料， 如使用者名稱、使用者ID、曆史、購物車、統計資料等等資訊。

問題在於，在有兩台Web伺服器和多個 HTTP串連的情況下，使用者流量會在兩台伺服器之間分配和移動，伺服器很難知道使用者是誰，並對所有資料進行跟蹤，因為每個頁面或者頁面的組成部分都可能來自不同的伺服器。在PHP中，通常是這樣解決的，在第一次串連或登入的時候就建立一個會話ID並將其放在Cookie中，然後這個Cookie會和每個 HTTP請求一起發送。

這樣做帶來一個問題，接下來每段PHP指令碼都需要基於ID來尋找會話資料。由於PHP無法在執行過程之間保持狀態（這與Java不同），這個會話資料需要儲存在某個地方，通常是在資料庫中。但是， 如果複雜的頁面需要在每個頁面載入過程中對其進行十次尋找（這是經常要做的），那就意味著每個頁面都要執行10次SQL查詢，這會導致資料庫上很大的負載。

在前面所舉的中國 Internet使用者0.01%的例子中，可能很容易在每秒內僅僅為了管理會話就產生上百個查詢。解決方案是一直使用位於Cookie中的會話ID，並且使用像Memcached之類的服務來緩衝會話資料以獲得高效能。

還要注意其中存在安全性的問題，因為駭客可以偽造另一個使用者的會話ID，這是很容易找到或看到的，特別是在公用的Wi-Fi中。解決方案是對會話ID進行恰當的加密或者簽名，並將其與時間區間、 IP地址以及其他關鍵資訊像瀏覽器或者其他細節相綁定。在Internet上有很多不錯的關於良好的會話管理的例子，你可以根據需要找到最適合的。

2. 總是要考慮安全性

儘管編寫像防止SQL注入和登入安全之類的代碼涉及很多安全問題，但不幸的是，幾乎沒有人考慮過安全性，而那些考慮到的人也沒有對其進行很好地理解。而本文要關注的是操作性的系統安全。對於這類安全，我們的焦點集中在三個安全領域：防火牆、啟動並執行使用者以及檔案存取權限。

除了配置專門的硬體防火牆（像Cisco的 ASA）之外，所有伺服器都還應該運行像Iptables之類的防火牆，它會保護伺服器免受其他威脅和攻擊。這些威脅和攻擊可能來自公用的Internet、其他伺服器或本機伺服器，也包括使用VPN或者SSH通道的開發和操作人員。我們僅對指定的IP開放確實需要的連接埠。Iptables可能會很複雜，但是有很多不錯的模板，我們通常可以使用它們來協助客戶建立Iptables。例如，預設的RedHat或者CentOS防火牆的配置說明只有10行，顯然並不實用。我們最佳實務的Iptables配置大概有5頁，這其中包含了Linux所能提供的最進階的安全防範。

所有公用的服務，都應該運行在專門的使用者下，如Apache。切記永遠都不要使用Root使用者運行，因為這會讓任何闖入到Apache的使用者接管整個伺服器。如果Apache只是運行在Apache使用者下或者運行在Nobody下，那麼闖入Apache就不是一件容易的事情了。 Web伺服器運行或者服務的檔案 （像.php和.html檔案）對於Web伺服器的使用者應該是不可寫的。這意味著Apache或者Nginx使用者不應該擁有Web目錄的寫入權限。有很多方法都可以做到這一點，而最簡單的就是將這些檔案為其他使用者所有，然後讓

Apache/Nginx等使用者歸屬於能夠使用640許可權讀取檔案的組中。這會防範幾乎所有的駭客和針對頁面的攻擊。

此外，永遠不要使用FTP來上傳檔案，特別是在公用的Wi-Fi環境中，因為在其中駭客很容易盜取使用者名稱和密碼。取而代之的是使用SFTP會更加安全。另外，每個僱員都應該擁有自己的使用者ID和隨機密碼。

3. 使用標準的路徑和安裝配置

一個令人討厭的部署問題是，開發人員很少考慮他們的軟體會被部署到生產Web伺服器的什麼位置，以及如何部署。我們看到過許多大型的系統將它們的PHP代碼部署在/home/xiaofeng或者/web/code路徑下。事實上，這兩個路徑都是非常不標準的，並且會帶來操作和安全性的問題。當這些系統從開發環境轉移到測試環境再到生產環境中時， 因為每個安裝配置都是非標準的，所以經常會出現問題，這時就需要開發人員調整才能夠正常工作。

你應該總是使用標準的安裝包和二進位檔案來安裝像Apache之類的伺服器。不要從原始碼編譯或者安裝Tarball，因為這會導致長期穩定性和管理上的問題，另外在伺服器上安裝多個不同的版本也會造成混淆。

Web網站應該總是在指定的平台和 Linux發布的標準路徑下進行測試和部署 ，像 RedHat 或者CentOS下的/var/www/html路徑。這有助於對系統進行有效許可權管 理、備份、配置、監控以及其他動作。

Web伺服器的日誌應該存放在/var/logs或者/var/logs/app_name下，而不應該位於主代碼地區。這樣做的原因不僅僅是因為這些標準的路徑很重要，更應該關注的是，恰當地設定管理員會將/var配置為分離的檔案系統。如果應用程式突然寫入了大量日誌並佔用所有磁碟空間，由於我們做了以上的配置就不會導致系統崩潰，或者其他嚴重的問題。如果日誌位於其他位置，就可能會產生問題。

4. 總是使用日誌

在Web系統中做多少日誌都不為過。所有系統都應該將重要的資料寫入到日誌中，不管是它們自己的日誌還是系統的Syslog。Cron的Job以及其他Shell指令碼或者C語言的程式，對日誌都有相應標準以

及簡單的函數。在Shell指令碼中，只需要使用Logger命令就可以實現日誌的寫入。在指令碼啟動/停止、重要的指令碼執行以及即時資料產生的 情況下都要執行寫入日誌操作。這樣出現問題的時候，查看主要的系統日誌就可以很容易地看到發生了什麼。

大型系統經常會使用專門的工具如Local5來記錄日誌，並配置Syslog或者

Syslog-ng來將其存放在單獨的檔案中，這樣會更容易使用。需要注意的是，Syslog工具和 Logger（以及任何Syslog調用）預設優先使用user.notice，如有必要，你可以對其進行調整。

一個好的系統會對程式進行配置，用來開啟或者關閉日誌，並可以選擇在每模組或者功能的層級上應用不同層級的日誌。這使得我們可以記錄非常詳細和強大的日誌，用來分析和調試在生產操作中所發生的問 題。

5. 使用良好的資料庫設計和SQL

在任何系統中，資料庫通常是最大的效能瓶頸。而影響資料庫效能的最大兩個問題是資料庫設計和SQL代碼品質。很多系統都擁有良好的或者至少是可用的資料庫設計，但由於沒有經過適當的效能測試，SQL代碼品質通常都會很差。這樣的SQL代碼在開發環境中可能運行很快，因為其中只有小資料集和最小的負載。但是當成千上萬的使用者同時讀取資料庫中 上百萬條記錄的時候，它就很可能會崩潰。

不幸的是，這些問題一開始並不明顯，直到系統增大、突然開始崩潰的時候才會顯現出來。在增大的過程中，資料庫系統看起來運行得很快（因為資料都位於記憶體中，而且很少有並發的查詢），並且對使用者的響 應也很快，但實際上它的內部運行效率很低。這並不重要，我們關注的是在系統增大並遇到效能問題之前找到這些問題並加以解決。

關於這個問題有很多不錯的書和網站進行瞭解 析，其中的關鍵工具包括慢查詢日誌、INNODB狀態系統，以及描述當前效能的MySQL統計資訊。我們見到過很多系統每秒會讀取500,000條資料， 這是出現SQL問題的明顯預兆，但公司往往對其一無所知直到伺服器開始崩潰。

MySQL系統應該對所有資料使用INNODB儲存引擎，因為INNODB與之前的MyISAM相比，運行得更快、更穩定，並且管理效能和備份工作也更加容易和快捷。在主設定檔中，INNODB應該被設定為預設的資料庫引擎，並且系統應該不時地進行檢查，看是否意外建立了MyISAM的表。

6. 總要擁有良好的DB配置和備份

很多公司都沒有良好的備份機制，也不知道如何恰當地完成這項工作。MySQL的Dump是不夠的，因為最好的備份方法是使用LVM快照和INNODB對系統進行熱備份，從而得到超快的速度和超高的可靠性。

另外，在將所有備份檔案從伺服器上轉移出來之前要進行壓縮和加密。另外還要確保擁有設計合理的MySQL配置。MySQL預設安裝使用說明中只有5~10行關於配置的說明，這根本不適合開發使用。 而我們提供給客戶的最佳實務文檔足足有10頁那麼長。文檔中大約有100種有用的關於安全、效能和穩定性問題的設定，包括防止資料敗壞，其中很多設定都是非常重要的。

7. 使用讀/寫資料庫分離

隨著系統變得越來越龐大，特別是當它們擁有很差的SQL時，一台資料庫伺服器通常不足以處理負載。但是多個資料庫意味著重複，除非你對資料進行了分離。更一般地，這意

味著建立主/從副本系統，其中程式會對主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的資料都讀取自從資料庫（或者多個從資料庫）。

儘管概念上很簡單，但是想要合理、精確地實現並不容易，這可能需要大量的代碼工作。因此，即便在開始時使用同一台資料庫伺服器，也要儘早計劃在PHP中使用分離的DB串連來進行讀寫操作。如果正確地完成該項工作，那麼系統就可以擴充到2台、3台甚至12台伺服器，並具備高可用性和穩定性。

8. 使用類似Memcached之類的資料庫緩衝

即便有了好的資料庫設計、SQL和讀寫 離，大型的系統仍然需要更快的效能，特別是對工作階段狀態、好友名單以及BBS文字之類的東西。為了達到這個目的，我們可以使用像MemCached之類的資料緩衝，它是一個高效能的簡單資料緩衝，已經被所有最大型的網站使用。但是要小心的是，不要100%依賴於一台Memcache伺服器來提高效能，因為如果那台伺服器崩潰了，就會破壞整個系統的效能。在這種情況下，應該使用2~3台Memcache伺服器形成簇集架構，並且有選擇地包含一個緩衝準備過程， 如果快取服務器重啟，需要重新載入資料，它能夠快速地載入緩衝。

9. 構建測試和開發環境

很多公司只有開發人員的案頭系統和他們的生產 伺服器。當系統變得越來越大、越來越複雜時，測試和管理代碼就會導致嚴重的問題。最佳的實踐是擁有兩個測試系統，一個用於開發人員的代碼和功能的整合測試， 另一個要與生產環境完全一致，從而更容易向生產環境平滑地過渡。幸運的是，現在使用雲端運算（或者私人雲端）可以輕鬆達到這一點。一個5~10台伺服器的生產 環境，可以很容易地在辦公室或者IDC中使用一台伺服器來複製，從而用於測試，而這台伺服器我們可以用於多個客戶的項目。

10. 使用版本控制

最後，要對一切使用版本控制，包括測試和生 產環境的部署。很多開發人員都使用SVN或者類似的方法。在理想狀態下，這些方法可以被用於所有代碼、指令碼、HTML、圖片、配置、文檔和測試。版本控制應該是代碼轉移到測試環境的必經之路，而不是簡單地複製或者使用tar檔案，因為這二者都是不可靠的。開發人員應該將所有一切都簽入，打上標籤，然後將它們簽出到測試系統。如果所有都沒問題，那麼它們會將該版本簽出到生產環境。 總結

不管是在開發還是在運營過程中，建立可靠的高效能Web系統都有很多應該注意的事項。本文試圖從可操作性和可靠性的角度討論最重要的幾點。當你構建和管理網站的時候，請不要忘了這些重要的問題。遵循這些規則會有助於確保系統長久、良好地運行。

 

大型高效能網站的十項規則