【正文】 大型動態(tài)應(yīng)用系統(tǒng)又可分為幾個子系統(tǒng)： 1） Web 前端系統(tǒng) 2）負載均衡系統(tǒng) 3）數(shù)據(jù)庫集群系統(tǒng) 4）緩存系統(tǒng) 5）分布式存儲系統(tǒng) 6）分布式服務(wù)器管理系統(tǒng) 7）代碼分發(fā)系統(tǒng) Web 前端系統(tǒng) 結(jié)構(gòu)圖： 為了達到不同應(yīng)用的服務(wù)器共享、避免單點故障、集中管理、統(tǒng)一配置等目的，不以應(yīng)用劃分服務(wù)器，而是將所有服務(wù)器做統(tǒng)一使用，每臺服務(wù)器都可以對多個應(yīng)用提供服務(wù)，當某些應(yīng)用訪問量升高時，通過增加服務(wù)器節(jié)點達到整個服務(wù)器集群的性能提高，同時使他應(yīng)用也會受益。軟件負載均衡系統(tǒng)價格較低或者免費，效率較硬件負載均衡系統(tǒng)低，不過對于流量一般或稍大些網(wǎng)站來講也足夠使用，比如 lvs, nginx。一個主庫對應(yīng)多個從庫，主庫數(shù)據(jù)實時同步到從庫。 6) 從數(shù)據(jù)庫使用 BigIP 做負載均衡。使用正確的緩存系統(tǒng)可以達到實現(xiàn)以下目標： 使用緩存系統(tǒng)可以提高訪問效率，提高服務(wù)器吞吐能力，改善用戶體驗。因此需要專業(yè)的大規(guī)模存儲系統(tǒng)。） 分布式服務(wù)器管理系統(tǒng) 結(jié)構(gòu)圖： 隨著網(wǎng)站訪問流量的不斷增加，大多的網(wǎng)絡(luò)服務(wù)都是以負載均衡集群的方式對外提供服務(wù)，隨之集群規(guī)模的擴大，原來基于單機的服務(wù)器管理模式已經(jīng)不能夠滿足我們的需求，新的需求必須能夠集中式的、分組的、批量的、自動化的對服務(wù)器進行管理，能夠批量化的執(zhí)行計劃任務(wù)。 有了 Cfengine 這種集中式的服務(wù)器管理工具，我們就可以高效的實現(xiàn)大規(guī)模的服 務(wù)器集群管理，被管理服務(wù)器和 Cfengine Server 可以分布在任何位置，只要網(wǎng)絡(luò)可以連通就能實現(xiàn)快速自動化的管理。 3) 我們需要實現(xiàn)源代碼管理和版本控制， SVN 可以實現(xiàn)該需求。 在中國， 開源的 LAMP 棧是最流行的網(wǎng)絡(luò)架構(gòu)，它使用 PHP 開發(fā)，運行在 Apache服務(wù)器上，以 MySQL 作為數(shù)據(jù)庫，所有這些都運行在 Linux 上。 當前的實際情況是，很多網(wǎng)站都是由開發(fā)人員 快速而廉價地創(chuàng)建，通常沒有任何 IT 人員或者經(jīng)理，只是由程序員來管理系統(tǒng)。遵循這些建議的站點會提高它的可伸縮性、安全性以及操作上的穩(wěn)定性。這對 Java 程序來說是很嚴重的問題，在 PHP 中也會產(chǎn)生可延展性問題， 對于數(shù)據(jù)庫的負載尤其如此。 問題在 于，在有兩臺 Web 服務(wù)器和多個 HTTP 連接的情況下，用戶流量會在兩臺服務(wù)器之間分配和移動，服務(wù)器很難知道用戶是誰，并對所有數(shù)據(jù)進行跟蹤，因 為每個頁面或者頁面的組成部分都可能來 自不同的服務(wù)器。但是， 如果復雜的頁面需要在每個頁面載入過程中對其進行十次查找（這是經(jīng)常要做的），那就意味著每個頁面都要執(zhí)行10 次 SQL 查詢， 這會導致數(shù)據(jù)庫上很大的負 載。解決方法是對會話 ID 進行恰當?shù)募用芑蛘吆灻?，并將其與時間區(qū)間、 IP 地址以及其他關(guān)鍵信息 像瀏覽器或者其他細節(jié)相綁定。對于這類安 全，我們的焦點集中在三個安全領(lǐng)域：防火墻、運行的用戶以及文件訪問權(quán)限。Iptables 可能會很復雜，但是有很多不錯的模板，我們通常可以使用它們來幫助客戶創(chuàng)建 Iptables。切記永遠都不 要使用 Root 用戶運行，因為這會讓任何闖入到 Apache 的用戶接管整個服務(wù)器。有很多方 法都可以做到這一點，而最簡單的就是將這些文件為其他用戶所有，然后讓 Apache/Nginx 等用戶歸屬于能夠使用 640 權(quán)限讀取文件的組中。另外，每個雇員都應(yīng)該擁有自己的用戶 ID 和隨 機密碼。當這些系統(tǒng)從開發(fā)環(huán)境轉(zhuǎn)移到測試環(huán)境再到生產(chǎn)環(huán)境中時， 因為每個安裝配置都是非標準的，所以經(jīng)常會出現(xiàn)問題，這時就需要開發(fā)者調(diào)整才能夠正常工作。這有助于對系統(tǒng)進行有效的權(quán)限管 理、備份、配置、監(jiān)控以及其他操作。如果日志位于其他位置，就可能會產(chǎn)生問題。在 Shell 腳本中，只需要使用 Logger 命令就可以實現(xiàn)日志的寫入。需要注意的是，Syslog 工具和 Logger（以及任何 Syslog 調(diào)用）默認優(yōu)先使用 ，如有必要，你可以對其進行調(diào)整。而影響數(shù)據(jù)庫性能的最大兩個問題是數(shù)據(jù)庫設(shè)計和 SQL 代碼質(zhì)量。 不幸的 是，這些問題一開始并不明顯，直到系 統(tǒng)增大、突然開始崩潰的時候才會顯現(xiàn)出來。我們見到過很多系統(tǒng)每秒會讀取 500,000 條數(shù)據(jù)， 這是出現(xiàn) SQL 問題的明顯預(yù)兆，但公司往往對其一無所知直到服務(wù)器開始崩潰。 MySQL的 Dump 是不夠的，因為最好的備份方法是使用 LVM 快照和 INNODB 對系統(tǒng)進行熱備份，從而得到超快的速度和超高的 可靠性。 而我們提供給客戶的最佳實踐文檔足足有 10 頁那么長。更一般地，這意味著建立主 /從副本系統(tǒng)，其中 程序會對主庫編寫所有的Update、 Insert 和 Delete 變更語句，而所有 Select 的數(shù)據(jù)都讀取自從數(shù)據(jù)庫（或者多個從數(shù)據(jù)庫）。 使用類似 Memcached 之類的數(shù)據(jù)庫緩存 即便有了好的數(shù)據(jù)庫設(shè)計、 SQL 和讀寫分 離，大型的系統(tǒng)仍然需要更快的性能，特別是對會話狀態(tài)、好友列表以及 BBS 文字之類的東西。 構(gòu)建測試和開發(fā)環(huán)境 很多公司只有開發(fā)者的桌面系統(tǒng)和他們的生產(chǎn) 服務(wù)器。一個 5~10 臺服務(wù)器的生產(chǎn) 環(huán)境，可以很容易地在辦公室或者 IDC 中使用一臺服務(wù)器來復制，從而用于測試，而這臺服務(wù)器我們可以用于多個客戶的項目。版本控制應(yīng) 該是代碼轉(zhuǎn)移到測試環(huán)境的必經(jīng)之路，而不是簡單地復制或者使用 tar 文件，因為這二者都是不可靠的。本文試圖從可操作性和可靠性的角度討論最重要的幾點。曾擔任土豆網(wǎng)、 Intermind 和 Advanced Management Systems 等多家企業(yè) CTO 。遵 循這些規(guī)則會有 助于確保系統(tǒng)長久、良好地運行。如果所有都沒問題，那么它們會將該版本簽出到生產(chǎn)環(huán)境。很多開發(fā)者都使用 SVN 或者類似的方法。最佳的實踐是擁有兩個測試系統(tǒng)，一個用于開發(fā)者的代碼和功能的整合測試， 另一個要與生產(chǎn)環(huán)境完全一致，從而更容易向生產(chǎn)環(huán)境平滑地過渡。但是要小心的是，不要 100%依賴于一臺 Memcache服務(wù)器來提高性能，因為如 果那臺服務(wù)器崩潰了，就會破壞整個系統(tǒng)的性能。因此，即便在開始時使用同一臺數(shù)據(jù)庫服務(wù)器，也要盡早計劃在 PHP中使用分離的 DB 連接來進行讀寫操作。 使用讀 /寫數(shù)據(jù)庫分離 隨著系統(tǒng)變得越來越龐大，特別是當它們擁有 很差的 SQL 時，一臺數(shù)據(jù)庫服務(wù)器通常不足以處理負載。另外還要確保擁有設(shè)計合理的 MySQL 配置。在主配置文件 中， INNODB 應(yīng)該被設(shè)置為默認的數(shù)據(jù)庫引擎，并且系統(tǒng)應(yīng)該不時地進行檢查，看是否意外創(chuàng)建了 MyISAM 的表。這并不重要，我們關(guān)注的是在系統(tǒng)增大并遇到性能問題之前找到這些問題并加以解決。這樣的 SQL 代碼在開發(fā)環(huán)境中可能運行很快，因為其中只有小數(shù)據(jù)集和最小的負載。這使得我們可以記錄非常詳細和強大的日志，用來分析和調(diào)試在生產(chǎn)操作中所發(fā)生的問 題。這樣出現(xiàn)問題的時候，查看主要的系統(tǒng)日志就可以很容易地看到發(fā)生了什么。所有系 統(tǒng)都應(yīng)該將重要的數(shù)據(jù)寫入到日志中，不管是它們自己的日志還是系統(tǒng)的 Syslog。這樣做的原因不僅僅是因為這些標準的路徑很重要，更應(yīng)該關(guān)注的是，恰當 地配置服務(wù)器會將 /var 配置為分離的文件系統(tǒng)。不要從源代碼編譯或者安裝 Tarball，因為這會導致長期穩(wěn)定性和管理上的問題，另外在服務(wù)器上安裝多個不同的版本也 會造成混淆。我們看到過許多大型的系統(tǒng)將它們的 PHP代碼部署在 /home/xiaofeng 或者 /web/code 路徑下。 此 外，永遠不要使用 Ftp 來上傳文件，特別 是在公用的 WiFi 環(huán)境中，因為在其中黑客很容易盜取用戶名和密碼。 Web 服務(wù)器運行或者服務(wù)的文件 （像 .php 和 .html 文件）對于 Web 服務(wù)器的用戶應(yīng)該是不可寫的。我們最佳實踐的 Iptables 配置大概有 5 頁，這其中包含了 Linux 所能提供的最高級的安全防范。這些威 脅和攻擊可能來自公共的 Inter、其他服務(wù)器或本地服務(wù)器，也包括使用 VPN 或者 SSH 通道的開發(fā)和操作人員。 總是要考慮安全性 盡管編寫像防止 SQL 注入和登錄安全之類的 代碼涉及很多安全問題，但不幸的是，幾乎沒有人考慮過安全性，而那些考慮到的人也沒有對其進行很好地理解。解決方法是一直使用位于 Cookie 中的會話 ID，并且使用像 Memcached 之類的服務(wù)來緩存會話數(shù)據(jù)以獲得高性能。 這樣做帶來一個問題，接下來每段 PHP 腳本 都需要基于