《
大型高性能Web站點十項規(guī)則_》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/11064362012.htm
總是要斟酌安全性
此外，永遠不要使用Ftp來上傳文件，特殊是在公用的Wi-Fi環(huán)境中，因為在其中黑客很容易盜取用戶名和密碼。取而代之的是使用Sftp會更加安全。另外，每個雇員都應該占有本人的用戶ID和隨秘密碼。
問題在于，在有兩臺Web服務器和多個HTTP銜接的情況下，用戶流量會在兩臺服務器之間調(diào)配和挪動，服務器很難知道用戶是誰，并對所有數(shù)據(jù)進行跟蹤，因為每個頁面或者頁面的組成局部都可能來 自不同的服務器。在PHP中，通常是這樣解決的，在第一次連接或登錄的時候就創(chuàng)建一個會話ID并將其放在Cookie中，然后這個Cookie會和每個 HTTP懇求一起發(fā)送。
可憐的 是，這些問題一開始并不顯著，直到系統(tǒng)增大、忽然開始崩潰的時候才會浮現(xiàn)出來。在增大的過程中，數(shù)據(jù)庫系統(tǒng)看起來運行得很快（因為數(shù)據(jù)都位于內(nèi)存中，而且很少有并發(fā)的查詢），并且對用戶的響 應也很快，但實際上它的內(nèi)部運行效力很低。這并不重要，我們關注的是在系統(tǒng)增大并碰到性能問題之前找到這些問題并加以解決。
在中國，開源的LAMP棧是最流行的網(wǎng)絡架構，它使用PHP開發(fā)，運行在Apache服務器上，以MySQL作為數(shù)據(jù)庫，所有這些都運行在Linux上。它是個可靠的平臺，運行良好，是當初寰球最風行的Internet系統(tǒng)架構。
還要注 意其中存在安全性的問題，因為黑客可 以捏造另一個用戶的會話ID，這是很容易找到或看到的，特別是在公用的Wi-Fi中。解決方法是對會話ID進行恰當?shù)募用芑蛘吆灻�，并將其與時光區(qū)間、 IP地址以及其他癥結信息 像閱讀器或者其他細節(jié)相綁定。在Internet上有很多不錯的關于良好的會話管理的例子，你可以依據(jù)需要找到最適合的。
第一個想到的擴展系統(tǒng)的方法就是增加更多硬件。例如，使用兩臺服務器而不是一臺。這聽著合理，但會產(chǎn)生潛在問題：會話管理。這對Java程序來說是很嚴峻的問題，在PHP中也會產(chǎn)生可延展性問題， 對于數(shù)據(jù)庫的負載尤其如此。
使用良好的數(shù)據(jù)庫設計和SQL
許多公司都不良好的備份機制，也不曉得如 何適當?shù)貙崿F(xiàn)這項工作。MySQL的Dump是不夠的，由于最好的備份方法是使用LVM快照和INNODB對體系進行熱備份，從而得到超快的速度和超高的 牢靠性。
總要擁有良好的DB配置和備份
在前面所舉的中國Internet用戶 0.01%的例子中，可能很輕易在每秒內(nèi)僅僅為了治理會話就天生上百個查問。解決辦法是始終應用位于Cookie中的會話ID，并且使用像Memcached之類的服務來緩存會話數(shù)據(jù)以取得高機能。
使用標準的路徑和安裝配置
除了配置專門的硬件防火墻（像Cisco的 ASA）之外，所有服務器都還應該運行像Iptables之類的防火墻，它會維護服務器免受其余要挾和攻打。這些威逼和襲擊可能來自公共的 Internet、其他服務器或本地服務器，也包括使用VPN或者SSH通道的開發(fā)和操作職員。我們僅對指定的IP開放確切須要的端口。Iptables 可能會很龐雜，然而有很多不錯的模板，我們通常能夠使用它們來輔助客戶創(chuàng)建Iptables。例如，默認的RedHat或者CentOS防火墻的配置說明 只有10行，顯然并不適用。我們最佳實踐的Iptables配置大略有5頁，這其中包括了Linux所能供給的最高等的安全防備。
在任何系統(tǒng)中，數(shù)據(jù)庫通常是最大的性能瓶 頸。而影響數(shù)據(jù)庫性能的最大兩個問題是數(shù)據(jù)庫設計和SQL代碼質(zhì)量。很多系統(tǒng)都擁有良好的或者至少是可用的數(shù)據(jù)庫設計，但因為沒有經(jīng)由恰當?shù)男阅軠y 試，SQL代碼品質(zhì)通常都會很差。這樣的SQL代碼在開發(fā)環(huán)境中可能運行很快，因為其中只有小數(shù)據(jù)集和最小的負載。但是當成千上萬的用戶同時讀取數(shù)據(jù)庫中 上百萬條記錄的時候，它就很可能會崩潰。
使用版本把持
你應該老是使用標準的安裝包和二進制文件來 安裝像Apache之類的服務器。不要從源代碼編譯或者安裝Tarball，因為這會導致長期穩(wěn)定性和管理上的問題，另外在服務器上安裝多個不同的版本也 會造成混雜。
這樣做帶來一個問題，接下來每段PHP腳本 都需要基于ID來查找會話數(shù)據(jù)。由于PHP無奈在執(zhí)行過程之間保持狀態(tài)（這與Java不同），這個會話數(shù)據(jù)需要存儲在某個處所，通常是在數(shù)據(jù)庫中。但是， 如果復雜的頁面需要在每個頁面載入過程中對其進行十次查找（這是常常要做的），那就意味著每個頁面都要執(zhí)行10次SQL查詢，這會導致數(shù)據(jù)庫上很大的負載。
使用相似Memcached之類的數(shù)據(jù)庫緩存
會話被定義為單獨的終極用戶登錄或者連接一 段時間，其中通常會包含多個TCP/IP的HTTP連接、幾個Web頁面，通常還包括幾十個甚至上百個頁面元素，如框架、菜單、Ajax更新等。所有這些 HTTP要求都需要知道用戶是誰，能力滿意安全的請求，并向用戶傳遞適當?shù)膬?nèi)容，因為這些都是會話的組成部門。通常每個會話都會包括彼此關系的會話數(shù)據(jù)， 如用戶名、用戶ID、歷史、購物車、統(tǒng)計材料等等信息。
造成的成果是，固然破費很低的本錢網(wǎng)站就可以開始運行，但是當擁有大量用戶、 需要擴展規(guī)模的時候，通常就會見臨真正的問題。究竟，中國擁有三億八千萬的Internet用戶，如果其中的0.01%訪問這個站點，就很容易引發(fā)25 萬~50萬的頁面訪問量。
在Web系統(tǒng)中做多少日志都不為過。所有系統(tǒng)都應該將重要的數(shù)據(jù)寫入到日志中，不論是它們自己的日志仍是系統(tǒng)的Syslog。Cron的Job以及其他Shell腳本或者C語言的程序，對日志都有 相應尺度以及簡略的函數(shù)。在Shell腳本中，只要要使用 Logger命令就可以實現(xiàn)日志的寫入。在腳本啟動/結束、重要的腳本執(zhí)行以及實時數(shù)據(jù)產(chǎn)生的 情形下都要履行寫入日志操作。這樣呈現(xiàn)問題的時候，查看重要的系統(tǒng)日志就可以很容易地看到產(chǎn)生了什么。
MySQL系統(tǒng)應該對所有數(shù)據(jù)使用 INNODB存儲引擎，因為INNODB與之前的MyISAM比擬，運行得更快、更穩(wěn)定，并且管感性能和備份工作也更加容易和快捷。在主配置文件 中，INNODB應該被設置為默認的數(shù)據(jù)庫引擎，并且系統(tǒng)應該不斷地進行檢討，看是否意外創(chuàng)建了MyISAM的表。
很多公司只有開發(fā)者的桌面系統(tǒng)和他們的生產(chǎn) 服務器。當系統(tǒng)變得越來越大、越來越復雜時，測試和管理代碼就會導致重大的問題。最佳的實踐是擁有兩個測試系統(tǒng)，一個用于開發(fā)者的代碼和功效的整合測試， 另一個要與生產(chǎn)環(huán)境完整一致，從而更容易向生產(chǎn)環(huán)境平滑地過渡。榮幸的是，現(xiàn)在使用云盤算（或者私有云）可以輕松到達這一點。一個5~10臺服務器的生產(chǎn) 環(huán)境，可以很容易地在辦公室或者IDC中使用一臺服務器來復制，從而用于測試，而這臺服務器我們可以用于多個客戶的名目。
只管概念上很簡單，但是想要合理、準確地實 現(xiàn)并不容易，這可能需要大批的代碼工作。因而，即使在開始時使用統(tǒng)一臺數(shù)據(jù)庫服務器，也要盡早打算在PHP中使用分離的DB連接來進行讀寫操作。如果準確 地完成該項工作，那么系統(tǒng)就可以擴大到2臺、3臺甚至12臺服務器，并具備高可用性和穩(wěn)定性。
本文和大家分享一下創(chuàng)立大型高性能Web站點的十項規(guī)則，你應該來看下哦，無比不錯的文章。
即便有了好的數(shù)據(jù)庫設計、SQL和讀寫分離，大型的系統(tǒng)依然需要更快的性能，特別是對會話狀態(tài)、摯友列表以及BBS文字之類的貨色。為了達到這個目標，我們可以使用像MemCached之類的數(shù) 據(jù)緩存，它是一個高性能的簡單數(shù)據(jù)緩存，已經(jīng)被所有最大型的站點使用。但是要警惕的是，不要100%依附于一臺Memcache服務器來提高性能，因為如 果那臺服務器崩潰了，就會損壞整個系統(tǒng)的性能。在這種情況下，應該使用2~3臺Memcache服務器構成簇集架構，并且有取舍地包含一個緩存籌備進程， 如果緩存服務重視啟，需要從新載入數(shù)據(jù)，它可以快捷地載入緩存。
關于這個問題有很多不錯的書和站點進行懂得析，其中的要害工具包括慢查詢?nèi)罩�、INNODB狀態(tài)系統(tǒng)，以及描寫當前性能的MySQL統(tǒng)計信息。我們見到過很多系統(tǒng)每秒會讀取500,000條數(shù)據(jù)， 這是涌現(xiàn)SQL問題的顯明前兆，但公司往往對其一竅不通直到服務器開端瓦解。
另外，在將所有備份文件從服務器上轉移出來 之前要進行緊縮和加密。另外還要確保領有設計公道的MySQL配置。MySQL默認裝置使用解釋中只有5~10行關于配置的說明，這基本不合適開發(fā)使用。 而咱們提供應客戶的最佳實際文檔足足有10頁那么長。文檔中大概有100種有用的對于平安、性能跟穩(wěn)定性問題的設定，包含避免數(shù)據(jù)敗壞，其中良多設定都是十分重要的。
構建測試和開發(fā)環(huán)境
這些問題在各個級別上都會發(fā)生，下面總結的規(guī)則是對最個別的問題進行概述，并且闡明為什么這些規(guī)矩如斯主要，以及最好采取什么方式來修改它們。遵守這些倡議的站點會進步它的可伸縮性、保險性以及操作上的穩(wěn)固性。
Web服務器運行或者服務的文件 （像.php和.htm文件）對Web服務器的用戶應該是不可寫的。這象征著Apache或者Nginx用戶不應該擁有Web目錄的寫權限。有很多方 法都可以做到這一點，而最簡單的就是將這些文件為其他用戶所有，而后讓Apache/Nginx等用戶歸屬于可能使用640權限讀取文件的組中。這會防范 簡直所有的黑客和針對頁面的攻擊。
Web 站點應該總是在指定的平臺和 Linux宣布的標準路徑下進行測試和部署，像RedHat 或者CentOS下的/var/www/html路徑。這有助于對系統(tǒng)進行有效的權限管 理、備份、配置、監(jiān)控以及其他操作。
Web 服務器的日志應該存放在/var /logs或者/var/logs/app_name下，而不應該位于主代碼區(qū)域。這樣做的起因不僅僅是因為這些標準的路徑很重要，更應該關注的是，恰當 地配置服務器會將/var配置為分離的文件系統(tǒng)。如果應用程序突然寫入了大量日志并占用所有磁盤空間，因為我們做了以上的配置就不會導致系統(tǒng)崩潰，或者其 他嚴峻的問題。如果日志位于其他位置，就可能會產(chǎn)生問題。
使用讀/寫數(shù)據(jù)庫分別
跟著系統(tǒng)變得越來越宏大，特別是當它們擁有 很差的SQL時，一臺數(shù)據(jù)庫服務器通常不足以處置負載。但是多個數(shù)據(jù)庫意味著反復，除非你對數(shù)據(jù)進行了分離。更普通地，這意味著樹立主/從副本系統(tǒng)，其中程序會對主庫編寫所有的Update、Insert和Delete變革語句，而所有Select的數(shù)據(jù)都讀取自從數(shù)據(jù)庫（或者多個從數(shù)據(jù)庫）。
總是使用日志
一個好的系統(tǒng)會對程序進行配置，用來翻開或者封閉日志，并可以抉擇在每模塊或者功能的級別上運用不同級別的日志。這使得我們可以記載非常具體和強盛的日志，用來剖析和調(diào)試在生產(chǎn)操作中所發(fā)生的問題。
盡管編寫像預防SQL注入和登錄安全之類的 代碼波及很多安全問題，但不幸的是，多少乎沒有人考慮過安全性，而那些考慮到的人也沒有對其進行很好地輿解。而本文要關注的是操作性的系統(tǒng)安全。對于這類安 全，我們的焦點集中在三個安全范疇：防火墻、運行的用戶以及文件拜訪權限。
最后，要對一切使用版本節(jié)制，包括測試和出產(chǎn)環(huán)境的安排。很多開發(fā)者都使用SVN或者類似的方法。在幻想狀況下，這些方法可以被用于所有代碼、腳本、HTML、圖片、配置、文檔和測試。版本掌握應該是代碼轉移到測試環(huán)境的必經(jīng)之路，而不是簡單地復制或者使用tar文件，因為這二者都是不可靠的。開發(fā)者應該將所有所有都簽入，打上標簽，然后將它們簽 出到測試系統(tǒng)。如果所有都沒問題，那么它們會將該版本簽出到生產(chǎn)環(huán)境。
所有公用的服務，都應當運行在專門的用戶 下，如Apache。切記永遠都不要使用Root用戶運行，因為這會讓任何闖入到Apache的用戶接收全部服務器。假如Apache只是運行在 Apache用戶下或者運行在Nobody下，那么闖入Apache就不是一件容易的事件了。
然而，我們很難對其范圍進行正確的擴展并堅持安全性，因為每個利用層都有其本身的問題、缺點和最佳實踐。當前的實際情況是，很多網(wǎng)站都是由開發(fā)人員疾速而便宜地創(chuàng)建，通常沒有任何IT人員或者經(jīng)理，只是由程序員來管理系統(tǒng)。
-->
一個令人厭惡的部署問題是，開發(fā)者很少考慮 他們的軟件會被部署到生產(chǎn)Web服務器的什么地位，以及如何部署。我們看到過很多大型的系統(tǒng)將它們的PHP代碼部署在/home/xiaofeng或者 /web/code門路下。事實上，這兩個路徑都是異常不標準的，并且會帶來操作和安全性的問題。當這些系統(tǒng)從開發(fā)環(huán)境轉移到測試環(huán)境再到生產(chǎn)環(huán)境中時， 因為每個安裝配置都長短標準的，所以時常會出現(xiàn)問題，這時就需要開發(fā)者調(diào)整才干夠畸形工作。
使用適合的會話管理
大型系統(tǒng)常常會使用專門的工具如 Local5來記載日志，并配置Syslog或者Syslog-ng來將其寄存在獨自的文件中，這樣會更容易使用。需要留神的是，Syslog工具和 Logger（以及任何Syslog調(diào)用）默認優(yōu)先使用user.notice，如有必要，你可以對其進行調(diào)劑。
相關的主題文章：
(責任編輯：網(wǎng)站建設)
大型高性能Web站點十項規(guī)則_相關文章