http://blog.chinaunix.net/uid-20787846-id-3370050.html
在我們公司ChinaNetCloud，見 過多種不同類型的網站和系統，有好也有差。其中有些系統擁有良好的服務器/網絡架構，並且進行了合理的調整和監控 ；然而一般的系統都會有安全和性能上的 問題，不能良好運行，也無法變得更流行。
在中國， 開源的LAMP棧是最流行的網絡架構，它使用PHP開發，運行在Apache服務器上，以MySQL作爲數據庫，所有這些都運行在Linux上。它是個可靠的平臺，運行良好，是現在全球最 流行的Internet系統架構。然而，我們很難對其規模進行正確的擴展並保持安全性，因爲每個應用層都有其自身的問題、缺陷和最佳實踐。我們的工作就是 幫助企業用最低的操作成本來創建並運行高性能的、可伸縮的、安全的系統，因此對於這類問題我們有很豐富的經驗。
當前的實際情況是，很多網站都是由開發人員 快速而廉價地創建，通常沒有任何IT人員或者經理，只是由程序員來管理系統。造成的結果是，雖然花費很低的成本網站就可以開始運行，但是當擁有大量用戶、 需要擴展規模的時候，通常就會面臨真正的問題。畢竟，中國擁有三億八千萬的Internet用戶，如果其中的0.01%訪問這個站點，就很容易引發25 萬~50萬的頁面訪問量。這些問題在各個級別上都會產生，下面總結的規則是對最一般的問題進行概述，並且說明爲什麼這些規則如此重要，以及最好採用什麼方 法來修正它們。遵循這些建議的站點會提高它的可伸縮性、安全性以及操作上的穩定性。
使用合適的會話管理
第 一個想到的擴展系統的方法就是添加更多硬件。例如，使用兩臺服務器而不是一臺。這聽着合理，但會產生潛在問題：會話管理。這對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上有很多不錯的關於良好的會話管理的例子，你可以根據需要找到最適合的。
總是要考慮安全性
儘管編寫像防止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和隨 機密碼。
使用標準的路徑和安裝配置
一個令人討厭的部署問題是，開發者很少考慮 他們的軟件會被部署到生產Web服務器的什麼位置，以及如何部署。我們看到過許多大型的系統將它們的PHP代碼部署在/home/xiaofeng或者 /web/code路徑下。事實上，這兩個路徑都是非常不標準的，並且會帶來操作和安全性的問題。當這些系統從開發環境轉移到測試環境再到生產環境中時， 因爲每個安裝配置都是非標準的，所以經常會出現問題，這時就需要開發者調整才能夠正常工作。
你應該總是使用標準的安裝包和二進制文件來 安裝像Apache之類的服務器。不要從源代碼編譯或者安裝Tarball，因爲這會導致長期穩定性和管理上的問題，另外在服務器上安裝多個不同的版本也 會造成混淆。
Web 站點應該總是在指定的平臺和 Linux發佈的標準路徑下進行測試和部署 ，像 RedHat 或者CentOS下的/var/www/html路徑。這有助於對系統進行有效的權限管 理、備份、配置、監控以及其他操作。
Web 服務器的日誌應該存放在/var /logs或者/var/logs/app_name下，而不應該位於主代碼區域。這樣做的原因不僅僅是因爲這些標準的路徑很重要，更應該關注的是，恰當 地配置服務器會將/var配置爲分離的文件系統。如果應用程序突然寫入了大量日誌並佔用所有磁盤空間，由於我們做了以上的配置就不會導致系統崩潰，或者其 他嚴重的問題。如果日誌位於其他位置，就可能會產生問題。
總是使用日誌
在Web系統中做多少日誌都不爲過。所有系 統都應該將重要的數據寫入到日誌中，不管是它們自己的日誌還是系統的Syslog。Cron的Job以及其他Shell腳本或者C語言的程序，對日誌都有 相應標準以及簡單的函數。在Shell腳本中，只需要使用 Logger命令就可以實現日誌的寫入。在腳本啓動/停止、重要的腳本執行以及實時數據產生的 情況下都要執行寫入日誌操作。這樣出現問題的時候，查看主要的系統日誌就可以很容易地看到發生了什麼。
大型系統經常會使用專門的工具如 Local5來記錄日誌，並配置Syslog或者Syslog-ng來將其存放在單獨的文件中，這樣會更容易使用。需要注意的是，Syslog工具和 Logger（以及任何Syslog調用）默認優先使用user.notice，如有必要，你可以對其進行調整。
一個好的系統會對程序進行配置，用來打開或 者關閉日誌，並可以選擇在每模塊或者功能的級別上應用不同級別的日誌。這使得我們可以記錄非常詳細和強大的日誌，用來分析和調試在生產操作中所發生的問 題。
大型高性能網站的十項規則
使用良好的數據庫設計和SQL
在任何系統中，數據庫通常是最大的性能瓶 頸。而影響數據庫性能的最大兩個問題是數據庫設計和SQL代碼質量。很多系統都擁有良好的或者至少是可用的數據庫設計，但由於沒有經過適當的性能測 試，SQL代碼質量通常都會很差。這樣的SQL代碼在開發環境中可能運行很快，因爲其中只有小數據集和最小的負載。但是當成千上萬的用戶同時讀取數據庫中 上百萬條記錄的時候，它就很可能會崩潰。
不幸的 是，這些問題一開始並不明顯，直到系 統增大、突然開始崩潰的時候纔會顯現出來。在增大的過程中，數據庫系統看起來運行得很快（因爲數據都位於內存中，而且很少有併發的查詢），並且對用戶的響 應也很快，但實際上它的內部運行效率很低。這並不重要，我們關注的是在系統增大並遇到性能問題之前找到這些問題並加以解決。
關於這個問題有很多不錯的書和站點進行了解 析，其中的關鍵工具包括慢查詢日誌、INNODB狀態系統，以及描述當前性能的MySQL統計信息。我們見到過很多系統每秒會讀取500,000條數據， 這是出現SQL問題的明顯預兆，但公司往往對其一無所知直到服務器開始崩潰。
MySQL系統應該對所有數據使用 INNODB存儲引擎，因爲INNODB與之前的MyISAM相比，運行得更快、更穩定，並且管理性能和備份工作也更加容易和快捷。在主配置文件 中，INNODB應該被設置爲默認的數據庫引擎，並且系統應該不時地進行檢查，看是否意外創建了MyISAM的表。
總要擁有良好的DB配置和備份
很多公司都沒有良好的備份機制，也不知道如 何恰當地完成這項工作。MySQL的Dump是不夠的，因爲最好的備份方法是使用LVM快照和INNODB對系統進行熱備份，從而得到超快的速度和超高的 可靠性。
另外，在將所有備份文件從服務器上轉移出來 之前要進行壓縮和加密。另外還要確保擁有設計合理的MySQL配置。MySQL默認安裝使用說明中只有5~10行關於配置的說明，這根本不適合開發使用。 而我們提供給客戶的最佳實踐文檔足足有10頁那麼長。文檔中大約有100種有用的關於安全、性能和穩定性問題的設定，包括防止數據敗壞，其中很多設定都是 非常重要的。
使用讀/寫數據庫分離
隨着系統變得越來越龐大，特別是當它們擁有 很差的SQL時，一臺數據庫服務器通常不足以處理負載。但是多個數據庫意味着重複，除非你對數據進行了分離。更一般地，這意味着建立主/從副本系統，其中 程序會對主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的數據都讀取自從數據庫（或者多個從數據庫）。
儘管概念上很簡單，但是想要合理、精確地實 現並不容易，這可能需要大量的代碼工作。因此，即便在開始時使用同一臺數據庫服務器，也要儘早計劃在PHP中使用分離的DB連接來進行讀寫操作。如果正確 地完成該項工作，那麼系統就可以擴展到2臺、3臺甚至12臺服務器，並具備高可用性和穩定性。
使用類似Memcached之類的數據庫緩存
即便有了好的數據庫設計、SQL和讀寫分 離，大型的系統仍然需要更快的性能，特別是對會話狀態、好友列表以及BBS文字之類的東西。爲了達到這個目的，我們可以使用像MemCached之類的數 據緩存，它是一個高性能的簡單數據緩存，已經被所有最大型的站點使用。但是要小心的是，不要100%依賴於一臺Memcache服務器來提高性能，因爲如 果那臺服務器崩潰了，就會破壞整個系統的性能。在這種情況下，應該使用2~3臺Memcache服務器形成簇集架構，並且有選擇地包含一個緩存準備過程， 如果緩存服務器重啓，需要重新載入數據，它能夠快速地載入緩存。
構建測試和開發環境
很多公司只有開發者的桌面系統和他們的生產 服務器。當系統變得越來越大、越來越複雜時，測試和管理代碼就會導致嚴重的問題。最佳的實踐是擁有兩個測試系統，一個用於開發者的代碼和功能的整合測試， 另一個要與生產環境完全一致，從而更容易向生產環境平滑地過渡。幸運的是，現在使用雲計算（或者私有云）可以輕鬆達到這一點。一個5~10臺服務器的生產 環境，可以很容易地在辦公室或者IDC中使用一臺服務器來複制，從而用於測試，而這臺服務器我們可以用於多個客戶的項目。
使 用版本控制
最後，要對一切使用版本控制，包括測試和生 產環境的部署。很多開發者都使用SVN或者類似的方法。在理想狀態下，這些方法可以被用於所有代碼、腳本、HTML、圖片、配置、文檔和測試。版本控制應 該是代碼轉移到測試環境的必經之路，而不是簡單地複製或者使用tar文件，因爲這二者都是不可靠的。開發者應該將所有一切都簽入，打上標籤，然後將它們籤 出到測試系統。如果所有都沒問題，那麼它們會將該版本簽出到生產環境。
總結
不管 是在開發還是在運營過程中，創建可靠的 高性能Web系統都有很多應該注意的事項。本文試圖從可操作性和可靠性的角度討論最重要的幾點。當你構建和管理站點的時候，請不要忘了這些重要的問題。遵 循這些規則會有助於確保系統長久、良好地運行。
作者簡介：
Steve Mushero，ChinaNetCloud 公司聯合創始人、CEO兼CTO，擁有全球20多年的技術管理經驗。曾擔任土豆網、Intermind和 Advanced Management Systems等多家企業CTO
譯者簡介：
侯伯薇，生於鳳城，學在春城，做過國內和對 日項目，現在大連某保險公司工作。樂於鑽研技術，同時注重業務知識，勤于思考，願意與人交流和分享。