【導(dǎo)讀】高數(shù)據(jù)流動(dòng)性的網(wǎng)站為例，比如海內(nèi)，開心網(wǎng)等類似的系列架構(gòu)。是PHP還是JSP或者.NET環(huán)境，我們從架構(gòu)的方面去看問題，實(shí)現(xiàn)語言方面并不是問題，語言的優(yōu)勢在于實(shí)現(xiàn)而不是好壞，不論你選擇任何語言，架構(gòu)都是必須要面對的。這里討論一下大型網(wǎng)站需要注意和考慮的問題。決我們面對的問題，本身負(fù)載量不是很大，最多再加幾個(gè)索引就可以搞定。每天的數(shù)據(jù)量可能就上百萬，如果一個(gè)設(shè)計(jì)不好的多對多關(guān)系，在前期是沒有任何問題的，但是隨著用戶的增長，數(shù)據(jù)量會(huì)是幾何級(jí)的增長的。在這個(gè)時(shí)候我們對于一個(gè)表的select和。如果兩個(gè)或者多個(gè)請求同時(shí)對緩存有更新的要求的情況下，應(yīng)用程序會(huì)直接的死掉。的概率是非常高的，磁盤緩存就是一個(gè)大問題。常見的方案是對文件按照日期和類型進(jìn)行。必須有效的把多表聯(lián)合查詢降到最低。這是一個(gè)很正常的AJAX請求。但是在AJAX處理的時(shí)候，如果我們使用一個(gè)抓包工具的

　　

【正文】 對頁面的攻擊。 此 外，永遠(yuǎn)不要使用 Ftp 來上傳文件，特別 是在公用的 WiFi 環(huán)境中，因?yàn)樵谄渲泻诳秃苋菀妆I取用戶名和密碼。取而代之的是使用 Sftp 會(huì)更加安全。另外，每個(gè)雇員都應(yīng)該擁有自己的用戶 ID 和隨 機(jī)密碼。 使用標(biāo)準(zhǔn)的路徑和安裝配置 一個(gè)令人討厭的部署問題是，開發(fā)者很少考慮 他們的軟件會(huì)被部署到生產(chǎn) Web服務(wù)器的什么位置，以及如何部署。我們看到過許多大型的系統(tǒng)將它們的 PHP代碼部署在 /home/xiaofeng 或者 /web/code 路徑下。事實(shí)上，這兩個(gè)路徑都是非常不 標(biāo)準(zhǔn)的，并且會(huì)帶來操作和安全性的問題。當(dāng)這些系統(tǒng)從開發(fā)環(huán)境轉(zhuǎn)移到測試環(huán)境再到生產(chǎn)環(huán)境中時(shí)， 因?yàn)槊總€(gè)安裝配置都是非標(biāo)準(zhǔn)的，所以經(jīng)常會(huì)出現(xiàn)問題，這時(shí)就需要開發(fā)者調(diào)整才能夠正常工作。 你應(yīng)該總是使用標(biāo)準(zhǔn)的安裝包和二進(jìn)制文件來 安裝像 Apache 之類的服務(wù)器。不要從源代碼編譯或者安裝 Tarball，因?yàn)檫@會(huì)導(dǎo)致長期穩(wěn)定性和管理上的問題，另外在服務(wù)器上安裝多個(gè)不同的版本也 會(huì)造成混淆。 Web 站點(diǎn)應(yīng)該總是在指定的平臺(tái)和 Linux 發(fā)布的標(biāo)準(zhǔn)路徑下進(jìn)行測試和部署 ，像 RedHat 或者 CentOS 下的 /var//html 路徑。這有助于對系統(tǒng)進(jìn)行有效的權(quán)限管 理、備份、配置、監(jiān)控以及其他操作。 Web 服務(wù)器的日志應(yīng)該存放在 /var /logs 或者 /var/logs/app_name 下，而不應(yīng)該位于主代碼區(qū)域。這樣做的原因不僅僅是因?yàn)檫@些標(biāo)準(zhǔn)的路徑很重要，更應(yīng)該關(guān)注的是，恰當(dāng) 地配置服務(wù)器會(huì)將 /var 配置為分離的文件系統(tǒng)。如果應(yīng)用程序突然寫入了大量日志并占用所有磁盤空間，由于我們做了以上的配置就不會(huì)導(dǎo)致系統(tǒng)崩潰，或者其 他嚴(yán)重的問題。如果日志位于其他位置，就可能會(huì)產(chǎn)生問題。 總是使用日志 在 Web 系統(tǒng)中做多少日 志都不為過。所有系 統(tǒng)都應(yīng)該將重要的數(shù)據(jù)寫入到日志中，不管是它們自己的日志還是系統(tǒng)的 Syslog。 Cron 的 Job 以及其他 Shell 腳本或者 C 語言的程序，對日志都有 相應(yīng)標(biāo)準(zhǔn)以及簡單的函數(shù)。在 Shell 腳本中，只需要使用 Logger 命令就可以實(shí)現(xiàn)日志的寫入。在腳本啟動(dòng) /停止、重要的腳本執(zhí)行以及實(shí)時(shí)數(shù)據(jù)產(chǎn)生的 情況下都要執(zhí)行寫入日志操作。這樣出現(xiàn)問題的時(shí)候，查看主要的系統(tǒng)日志就可以很容易地看到發(fā)生了什么。 大型系統(tǒng)經(jīng)常會(huì)使用專門的工具如 Local5 來記錄日志，并配置 Syslog 或者Syslogng 來將其 存放在單獨(dú)的文件中，這樣會(huì)更容易使用。需要注意的是，Syslog 工具和 Logger（以及任何 Syslog 調(diào)用）默認(rèn)優(yōu)先使用 ，如有必要，你可以對其進(jìn)行調(diào)整。 一個(gè)好的系統(tǒng)會(huì)對程序進(jìn)行配置，用來打開或 者關(guān)閉日志，并可以選擇在每模塊或者功能的級(jí)別上應(yīng)用不同級(jí)別的日志。這使得我們可以記錄非常詳細(xì)和強(qiáng)大的日志，用來分析和調(diào)試在生產(chǎn)操作中所發(fā)生的問 題。 大型高性能網(wǎng)站的十項(xiàng)規(guī)則 使用良好的數(shù)據(jù)庫設(shè)計(jì)和 SQL 在任何系 統(tǒng)中，數(shù)據(jù)庫通常是最大的性能瓶 頸。而影響數(shù)據(jù)庫性能的最大兩個(gè)問題是數(shù)據(jù)庫設(shè)計(jì)和 SQL 代碼質(zhì)量。很多系統(tǒng)都擁有良好的或者至少是可用的數(shù)據(jù)庫設(shè)計(jì)，但由于沒有經(jīng)過適當(dāng)?shù)男阅軠y 試， SQL 代碼質(zhì)量通常都會(huì)很差。這樣的 SQL 代碼在開發(fā)環(huán)境中可能運(yùn)行很快，因?yàn)槠渲兄挥行?shù)據(jù)集和最小的負(fù)載。但是當(dāng)成千上萬的用戶同時(shí)讀取數(shù)據(jù)庫中 上百萬條記錄的時(shí)候，它就很可能會(huì)崩潰。 不幸的 是，這些問題一開始并不明顯，直到系 統(tǒng)增大、突然開始崩潰的時(shí)候才會(huì)顯現(xiàn)出來。在增大的過程中，數(shù)據(jù)庫系統(tǒng)看起來運(yùn)行得很快（因?yàn)閿?shù)據(jù)都位于內(nèi)存中，而且 很少有并發(fā)的查詢），并且對用戶的響 應(yīng)也很快，但實(shí)際上它的內(nèi)部運(yùn)行效率很低。這并不重要，我們關(guān)注的是在系統(tǒng)增大并遇到性能問題之前找到這些問題并加以解決。 關(guān)于這個(gè)問題有很多不錯(cuò)的書和站點(diǎn)進(jìn)行了解 析，其中的關(guān)鍵工具包括慢查詢?nèi)罩尽?INNODB 狀態(tài)系統(tǒng)，以及描述當(dāng)前性能的 MySQL 統(tǒng)計(jì)信息。我們見到過很多系統(tǒng)每秒會(huì)讀取 500,000 條數(shù)據(jù)， 這是出現(xiàn) SQL 問題的明顯預(yù)兆，但公司往往對其一無所知直到服務(wù)器開始崩潰。 MySQL系統(tǒng)應(yīng)該對所有數(shù)據(jù)使用 INNODB存儲(chǔ)引擎，因?yàn)?INNODB與之前的 MyISAM相比 ，運(yùn)行得更快、更穩(wěn)定，并且管理性能和備份工作也更加容易和快捷。在主配置文件 中， INNODB 應(yīng)該被設(shè)置為默認(rèn)的數(shù)據(jù)庫引擎，并且系統(tǒng)應(yīng)該不時(shí)地進(jìn)行檢查，看是否意外創(chuàng)建了 MyISAM 的表。 總要擁有良好的 DB 配置和備份 很多公司都沒有良好的備份機(jī)制，也不知道如 何恰當(dāng)?shù)赝瓿蛇@項(xiàng)工作。 MySQL的 Dump 是不夠的，因?yàn)樽詈玫膫浞莘椒ㄊ鞘褂?LVM 快照和 INNODB 對系統(tǒng)進(jìn)行熱備份，從而得到超快的速度和超高的 可靠性。 另外，在將所有備份文件從服務(wù)器上轉(zhuǎn)移出來 之前要進(jìn)行壓縮和加密。另外還要確保擁有設(shè)計(jì)合理的 MySQL 配置。 MySQL 默認(rèn)安裝使用說明中只有 5~10 行關(guān)于配置的說明，這根本不適合開發(fā)使用。 而我們提供給客戶的最佳實(shí)踐文檔足足有 10 頁那么長。文檔中大約有 100 種有用的關(guān)于安全、性能和穩(wěn)定性問題的設(shè)定，包括防止數(shù)據(jù)敗壞，其中很多設(shè)定都是 非常重要的。 使用讀 /寫數(shù)據(jù)庫分離 隨著系統(tǒng)變得越來越龐大，特別是當(dāng)它們擁有 很差的 SQL 時(shí)，一臺(tái)數(shù)據(jù)庫服務(wù)器通常不足以處理負(fù)載。但是多個(gè)數(shù)據(jù)庫意味著重復(fù)，除非你對數(shù)據(jù)進(jìn)行了分離。更一般地，這意味著建立主 /從副本系統(tǒng)，其中 程序會(huì)對主庫編寫所有的Update、 Insert 和 Delete 變更語句，而所有 Select 的數(shù)據(jù)都讀取自從數(shù)據(jù)庫（或者多個(gè)從數(shù)據(jù)庫）。 盡管概念上很簡單，但是想要合理、精確地實(shí) 現(xiàn)并不容易，這可能需要大量的代碼工作。因此，即便在開始時(shí)使用同一臺(tái)數(shù)據(jù)庫服務(wù)器，也要盡早計(jì)劃在 PHP中使用分離的 DB 連接來進(jìn)行讀寫操作。如果正確 地完成該項(xiàng)工作，那么系統(tǒng)就可以擴(kuò)展到 2 臺(tái)、 3 臺(tái)甚至 12 臺(tái)服務(wù)器，并具備高可用性和穩(wěn)定性。 使用類似 Memcached 之類的數(shù)據(jù)庫緩存 即便有了好的數(shù)據(jù)庫設(shè)計(jì)、 SQL 和讀寫分 離，大型的系統(tǒng)仍然需要更快的性能，特別是對會(huì)話狀態(tài)、好友列表以及 BBS 文字之類的東西。為了達(dá)到這個(gè)目的，我們可以使用像 MemCached 之類的數(shù) 據(jù)緩存，它是一個(gè)高性能的簡單數(shù)據(jù)緩存，已經(jīng)被所有最大型的站點(diǎn)使用。但是要小心的是，不要 100%依賴于一臺(tái) Memcache服務(wù)器來提高性能，因?yàn)槿? 果那臺(tái)服務(wù)器崩潰了，就會(huì)破壞整個(gè)系統(tǒng)的性能。在這種情況下，應(yīng)該使用 2~3 臺(tái) Memcache 服務(wù)器形成簇集架構(gòu)，并且有選擇地包含一個(gè)緩存準(zhǔn)備過程， 如果緩存服務(wù)器重啟，需要重新載入數(shù)據(jù)，它能夠快速地載入緩存。 構(gòu)建測試和開發(fā)環(huán)境 很多公司只有開發(fā)者的桌面系統(tǒng)和他們的生產(chǎn) 服務(wù)器。當(dāng)系統(tǒng) 變得越來越大、越來越復(fù)雜時(shí)，測試和管理代碼就會(huì)導(dǎo)致嚴(yán)重的問題。最佳的實(shí)踐是擁有兩個(gè)測試系統(tǒng)，一個(gè)用于開發(fā)者的代碼和功能的整合測試， 另一個(gè)要與生產(chǎn)環(huán)境完全一致，從而更容易向生產(chǎn)環(huán)境平滑地過渡。幸運(yùn)的是，現(xiàn)在使用云計(jì)算（或者私有云）可以輕松達(dá)到這一點(diǎn)。一個(gè) 5~10 臺(tái)服務(wù)器的生產(chǎn) 環(huán)境，可以很容易地在辦公室或者 IDC 中使用一臺(tái)服務(wù)器來復(fù)制，從而用于測試，而這臺(tái)服務(wù)器我們可以用于多個(gè)客戶的項(xiàng)目。 使 用版本控制 最后，要對一切使用版本控制，包括測試和生 產(chǎn)環(huán)境的部署。很多開發(fā)者都使用 SVN 或者類似的方法。在理想 狀態(tài)下，這些方法可以被用于所有代碼、腳本、HTML、圖片、配置、文檔和測試。版本控制應(yīng) 該是代碼轉(zhuǎn)移到測試環(huán)境的必經(jīng)之路，而不是簡單地復(fù)制或者使用 tar 文件，因?yàn)檫@二者都是不可靠的。開發(fā)者應(yīng)該將所有一切都簽入，打上標(biāo)簽，然后將它們簽 出到測試系統(tǒng)。如果所有都沒問題，那么它們會(huì)將該版本簽出到生產(chǎn)環(huán)境。 總結(jié) 不管 是在開發(fā)還是在運(yùn)營過程中，創(chuàng)建可靠的 高性能 Web 系統(tǒng)都有很多應(yīng)該注意的事項(xiàng)。本文試圖從可操作性和可靠性的角度討論最重要的幾點(diǎn)。當(dāng)你構(gòu)建和管理站點(diǎn)的時(shí)候，請不要忘了這些重要的問題。遵 循這些規(guī)則會(huì)有 助于確保系統(tǒng)長久、良好地運(yùn)行。 作者簡介： Steve Mushero， ChinaNetCloud 公司聯(lián)合創(chuàng)始人、 CEO 兼 CTO，擁有全球 20 多年的技術(shù)管理經(jīng)驗(yàn)。曾擔(dān)任土豆網(wǎng)、 Intermind 和 Advanced Management Systems 等多家企業(yè) CTO