門(mén)戶(hù)網(wǎng)站架構(gòu)設(shè)計(jì)方案

前臺(tái)門(mén)戶(hù)網(wǎng)站架構(gòu)設(shè)計(jì)方案北京寬連十方數(shù)字技術(shù)有限公司2010-7

目錄3網(wǎng)絡(luò)規(guī)劃及性能計(jì)算4.2測(cè)試結(jié)果43結(jié)果分析1網(wǎng)站的性能瓶頸分析網(wǎng)站的性能影響因素很多，下面主要從如下4個(gè)方面進(jìn)行分析說(shuō)明:1）網(wǎng)絡(luò)負(fù)載a）公網(wǎng)負(fù)載b）內(nèi)網(wǎng)負(fù)載2）WEB應(yīng)用服務(wù)器性能a）CPUb）存儲(chǔ)，I/O訪問(wèn)c）內(nèi)存d）并發(fā)TCP/IP連接數(shù)3）數(shù)據(jù)庫(kù)服務(wù)器性能a）數(shù)據(jù)庫(kù)參數(shù)配置b）服務(wù)器性能（CPU、內(nèi)存、存儲(chǔ)）c）數(shù)據(jù)結(jié)構(gòu)的合理性4）不同WEB應(yīng)用的處理方式而對(duì)不同的性能瓶頸a）對(duì)于靜態(tài)的網(wǎng)站：靜態(tài)的HTML頁(yè)面嚴(yán)格地由標(biāo)準(zhǔn)的HTML標(biāo)示語(yǔ)言構(gòu)成，并不需要服務(wù)器端即時(shí)運(yùn)算生成。這意味著，對(duì)一個(gè)靜態(tài)HTML文檔發(fā)出訪問(wèn)請(qǐng)求后，服務(wù)器端只是簡(jiǎn)單地將該文檔傳輸?shù)娇蛻?hù)端。從服務(wù)器運(yùn)行的那個(gè)時(shí)間片來(lái)看，這個(gè)傳輸過(guò)程僅僅占用了很小的CPU資源。對(duì)于靜態(tài)HTML的訪問(wèn)瓶頸為：網(wǎng)絡(luò)帶寬、磁盤(pán)I/O以及cache（高速緩沖存儲(chǔ)器）。b）對(duì)于動(dòng)態(tài)頁(yè)面因?yàn)榉?wù)器解析動(dòng)態(tài)頁(yè)面必須在其傳輸?shù)娇蛻?hù)端前就通過(guò)服務(wù)器來(lái)進(jìn)行解釋?zhuān)@樣就會(huì)給應(yīng)用服務(wù)器添加額外的性能消耗，如果進(jìn)一步要訪問(wèn)數(shù)據(jù)庫(kù)，則會(huì)增加數(shù)據(jù)庫(kù)服務(wù)器的性能消耗，則動(dòng)態(tài)頁(yè)面還有額外的瓶頸：應(yīng)用服務(wù)器的性能，數(shù)據(jù)庫(kù)服務(wù)器的性能。2系統(tǒng)架構(gòu)設(shè)計(jì)2.1總體思路為提高網(wǎng)站的高并發(fā)性能，提高開(kāi)發(fā)效率及運(yùn)營(yíng)效率，主要按如下幾個(gè)思路進(jìn)行規(guī)劃設(shè)計(jì)：2.1.1負(fù)載均衡1）四層交換負(fù)載均衡：采用負(fù)載均衡器來(lái)實(shí)現(xiàn)硬件級(jí)的四層交換負(fù)載均衡，或采用LVS來(lái)實(shí)現(xiàn)軟件的四層交換負(fù)載均衡。2）通過(guò)第三方軟件來(lái)實(shí)現(xiàn)負(fù)載均衡,同時(shí)實(shí)現(xiàn)頁(yè)面請(qǐng)求的緩存。通過(guò)Nginx實(shí)現(xiàn)反向代理服務(wù)器集群，同時(shí)搭建squid集群以作為靜態(tài)頁(yè)面和圖片的緩存。3）通過(guò)web服務(wù)器的配置來(lái)實(shí)現(xiàn)負(fù)載均衡即通過(guò)apache或是Nginx將客戶(hù)請(qǐng)求均衡的分給tomcat1,tomcat2....去處理。2.1.2WEB應(yīng)用開(kāi)發(fā)架構(gòu)思路1）應(yīng)用開(kāi)發(fā)實(shí)現(xiàn)MVC架構(gòu)三層架構(gòu)進(jìn)行web應(yīng)用開(kāi)發(fā)2）頁(yè)面盡可能靜態(tài)化以減少動(dòng)態(tài)數(shù)據(jù)訪問(wèn)，如果是資訊類(lèi)的網(wǎng)站可以考慮采用第三方開(kāi)源的CMS系統(tǒng)來(lái)生成靜態(tài)的內(nèi)容頁(yè)面。3）采用Oscache實(shí)現(xiàn)頁(yè)面緩存，采用Memcached實(shí)現(xiàn)數(shù)據(jù)緩存4）采用獨(dú)立的圖片服務(wù)器集群來(lái)實(shí)現(xiàn)圖片資源的存儲(chǔ)及WEB請(qǐng)求2.1.3數(shù)據(jù)存儲(chǔ)的設(shè)計(jì)思路1）數(shù)據(jù)庫(kù)拆分，把生產(chǎn)數(shù)據(jù)庫(kù)和查詢(xún)數(shù)據(jù)庫(kù)分離，對(duì)生產(chǎn)數(shù)據(jù)庫(kù)采用RAC實(shí)現(xiàn)數(shù)據(jù)庫(kù)的集群。2）采用高效的網(wǎng)絡(luò)文件共享策略，采用圖片服務(wù)器來(lái)實(shí)現(xiàn)頁(yè)面的圖片存儲(chǔ)。2.1.4不同網(wǎng)絡(luò)用戶(hù)訪問(wèn)考慮1）通過(guò)引ACDN來(lái)解決不同網(wǎng)絡(luò)服務(wù)商的接入速度問(wèn)題，一般只能解決靜態(tài)頁(yè)面的訪問(wèn)問(wèn)題。2）在不同運(yùn)營(yíng)商機(jī)房部署服務(wù)器，通過(guò)鏡像技術(shù)來(lái)實(shí)現(xiàn)不同網(wǎng)絡(luò)服務(wù)商的接入速度問(wèn)題。2.2總體架構(gòu)2.2.1網(wǎng)站的系統(tǒng)分層架構(gòu)2.2.2網(wǎng)站的物理架構(gòu)2.2.3網(wǎng)站的開(kāi)發(fā)架構(gòu)2.2.4網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)備注：1）采用雙防火墻雙交換機(jī)做網(wǎng)絡(luò)冗余，保障平臺(tái)服務(wù)采用雙防火墻通知接通2線路互聯(lián)網(wǎng)接入，設(shè)備之間采用VRRP協(xié)議，在任何一個(gè)防火墻、互聯(lián)網(wǎng)發(fā)生故障后均可自動(dòng)將流量切換到另一端，保證網(wǎng)站的正運(yùn)行，設(shè)備或網(wǎng)絡(luò)恢復(fù)后，自動(dòng)恢復(fù)。采用雙千兆交換機(jī)分別接在2臺(tái)防火墻上，當(dāng)某臺(tái)設(shè)備或者網(wǎng)絡(luò)鏈路發(fā)生故障后，好設(shè)備自動(dòng)接管已壞設(shè)備的工作，不影響網(wǎng)站的整體運(yùn)行，根據(jù)業(yè)務(wù)及真實(shí)服務(wù)器的數(shù)量，交換機(jī)可以隨時(shí)增加。2）采用硬件設(shè)備負(fù)載均衡器，實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡使用硬件設(shè)備負(fù)載均衡器，將網(wǎng)絡(luò)流量均衡的分擔(dān)到WEB服務(wù)器集群各節(jié)點(diǎn)服務(wù)器，保障平臺(tái)服務(wù)器資源均衡的使用。3）采用代理服務(wù)器，實(shí)現(xiàn)軟件級(jí)的網(wǎng)絡(luò)負(fù)載均衡。4）數(shù)據(jù)庫(kù)服務(wù)器分離成生產(chǎn)數(shù)據(jù)庫(kù)集群和查詢(xún)數(shù)據(jù)庫(kù)集群，實(shí)現(xiàn)生產(chǎn)讀寫(xiě)與后臺(tái)查詢(xún)統(tǒng)計(jì)進(jìn)行分離，同時(shí)生產(chǎn)數(shù)據(jù)庫(kù)采用rac技術(shù)進(jìn)行2.3架構(gòu)涉及技術(shù)的詳解2.3.1負(fù)載均衡基于DNS的負(fù)載均衡--一個(gè)域名綁定多個(gè)IPDNS負(fù)載均衡技術(shù)是最早的負(fù)載均衡解決方案，它是通過(guò)DNS服務(wù)中的隨機(jī)名字解析來(lái)實(shí)現(xiàn)的，在DNS服務(wù)器中，可以為多個(gè)不同的地址配置同一個(gè)名字，而最終查詢(xún)這個(gè)名字的客戶(hù)機(jī)將在解析這個(gè)名字時(shí)得到其中的一個(gè)地址。因此，對(duì)于同一個(gè)名字，不同的客戶(hù)機(jī)會(huì)得到不同的地址，它們也就訪問(wèn)不同地址上的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。這種技術(shù)的優(yōu)點(diǎn)是，實(shí)現(xiàn)簡(jiǎn)單、實(shí)施容易、成本低、適用于大多數(shù)TCP/IP應(yīng)用；但是，其缺點(diǎn)也非常明顯，首先這種方案不是真正意義上的負(fù)載均衡，DNS服務(wù)器將Http請(qǐng)求平均地分配到后臺(tái)的Web服務(wù)器上，而不考慮每個(gè)Web服務(wù)器當(dāng)前的負(fù)載情況；如果后臺(tái)的Web服務(wù)器的配置和處理能力不同，最慢的Web服務(wù)器將成為系統(tǒng)的瓶頸，處理能力強(qiáng)的服務(wù)器不能充分發(fā)揮作用；其次未考慮容錯(cuò)，如果后臺(tái)的某臺(tái)Web服務(wù)器出現(xiàn)故障，DNS服務(wù)器仍然會(huì)把DNS請(qǐng)求分配到這臺(tái)故障服務(wù)器上，導(dǎo)致不能響應(yīng)客戶(hù)端。最后一點(diǎn)是致命的，有可能造成相當(dāng)一部分客戶(hù)不能享受Web服務(wù)，并且由于DNS緩存的原因，所造成的后果要持續(xù)相當(dāng)長(zhǎng)一段時(shí)間（一般DNS的刷新周期約為24小時(shí)）。所以在國(guó)外最新的建設(shè)中心Web站點(diǎn)方案中，已經(jīng)很少采用這種方案了。通過(guò)硬件四層交換實(shí)現(xiàn)負(fù)載均衡在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比如Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國(guó)當(dāng)初接近2000臺(tái)服務(wù)器使用了三四臺(tái)Alteon就搞定了通過(guò)軟件四層交換實(shí)現(xiàn)負(fù)載均衡軟件四層交換我們可以使用Linux上常用的LVS來(lái)解決，LVS就是LinuxVirtualServer，他提供了基于心跳線heartbeat的實(shí)時(shí)災(zāi)難應(yīng)對(duì)解決方案，提高系統(tǒng)的魯棒性，同時(shí)可供了靈活的虛擬VIP配置和管理功能，可以同時(shí)滿足多種應(yīng)用需求，這對(duì)于分布式的系統(tǒng)來(lái)說(shuō)必不可少。一個(gè)典型的使用負(fù)載均衡的策略就是，在軟件或者硬件四層交換的基礎(chǔ)上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構(gòu)低成本、高性能還有很強(qiáng)的擴(kuò)張性。通過(guò)反向代理服務(wù)器實(shí)現(xiàn)負(fù)載均衡反向代理服務(wù)器又稱(chēng)為WEB加速服務(wù)器，它位于WEB服務(wù)器的前端，充當(dāng)WEB服務(wù)器的內(nèi)容緩存器，反向代理服務(wù)器是針對(duì)WEB服務(wù)器設(shè)置的，后臺(tái)WEB服務(wù)器對(duì)互聯(lián)網(wǎng)用戶(hù)是透明的，用戶(hù)只能看到反向代理服務(wù)器的地址，不清楚后臺(tái)WEB服務(wù)器是如何組織架構(gòu)的。當(dāng)互聯(lián)網(wǎng)用戶(hù)請(qǐng)求WEB服務(wù)時(shí)，DNS將請(qǐng)求的域名解析為反向代理服務(wù)器的IP地址，這樣URL請(qǐng)求將被發(fā)送到反向代理服務(wù)器，由反向代理服務(wù)器負(fù)責(zé)處理用戶(hù)的請(qǐng)求與應(yīng)答、與后臺(tái)WEB服務(wù)器交互。利用反向代理服務(wù)器減輕了后臺(tái)WEB服務(wù)器的負(fù)載，提高了訪問(wèn)速度，同時(shí)避免了因用戶(hù)直接與WEB服務(wù)器通信帶來(lái)的安全隱患。目前有許多反向代理軟件，比較有名的有Nginx和Squid。Nginx是由IgorSysoev為俄羅斯訪問(wèn)量第二的Rambler.ru站點(diǎn)開(kāi)發(fā)的，是一個(gè)高性能的HTTP和反向代理服務(wù)器，也是一個(gè)IMAP/POP3/SMTP代理服務(wù)器。Squid是由美國(guó)政府大力資助的一項(xiàng)研究計(jì)劃，其目的為解決網(wǎng)絡(luò)帶寬不足的問(wèn)題，支持HTTP，HTTPS，F(xiàn)TP等多種協(xié)議，是現(xiàn)在Unix系統(tǒng)上使用、最多功能也最完整的一套軟體。SquidSquid是一個(gè)開(kāi)源的軟件，利用它的反向代理技術(shù)可以提高網(wǎng)站系統(tǒng)的訪問(wèn)速度，下面將重點(diǎn)介紹Squid反向代理的實(shí)現(xiàn)原理和在提高網(wǎng)站性能方面的應(yīng)用。Squid反向代理服務(wù)器位于本地WEB服務(wù)器和Internet之間，組織架構(gòu)如下圖：客戶(hù)端請(qǐng)求訪問(wèn)WEB服務(wù)時(shí)，DNS將訪問(wèn)的域名解析為Squid反向代理服務(wù)器的IP地址，這樣客戶(hù)端的URL請(qǐng)求將被發(fā)送到反向代理服務(wù)器。如果Squid反向代理服務(wù)器中緩存了該請(qǐng)求的資源，則將該請(qǐng)求的資源直接返回給客戶(hù)端，否則反向代理服務(wù)器將向后臺(tái)的WEB服務(wù)器請(qǐng)求資源，然后將請(qǐng)求的應(yīng)答返回給客戶(hù)端，同時(shí)也將該應(yīng)答緩存在本地，供下一個(gè)請(qǐng)求者使用。Squid反向代理一般只緩存可緩沖的數(shù)據(jù)(比如html網(wǎng)頁(yè)和圖片等)，而一些CGI腳本程序或者ASP、JSP之類(lèi)的動(dòng)態(tài)程序默認(rèn)不緩存。它根據(jù)從WEB服務(wù)器返回的HTTP頭標(biāo)記來(lái)緩沖靜態(tài)頁(yè)面，有四個(gè)最重要HTTP頭標(biāo)記：Last-Modified:告訴反向代理頁(yè)面什么時(shí)間被修改Expires:告訴反向代理頁(yè)面什么時(shí)間應(yīng)該從緩沖區(qū)中刪除Cache-Control:告訴反向代理頁(yè)面是否應(yīng)該被緩沖Pragma:用來(lái)包含實(shí)現(xiàn)特定的指令，最常用的是Pragma:no-cache注：DNS的輪詢(xún)機(jī)制將某一個(gè)域名解析為多個(gè)IP地址。NginxNginx(“enginex”)是俄羅斯人IgorSysoev(塞索耶夫)編寫(xiě)的一款高性能的HTTP和反向代理服務(wù)器。Nginx已經(jīng)在俄羅斯最大的門(mén)戶(hù)網(wǎng)站在國(guó)內(nèi)，已經(jīng)有新浪博客、新浪播客、搜狐通行證、網(wǎng)易新聞、網(wǎng)易博客、金山逍遙網(wǎng)、金山愛(ài)詞霸、校內(nèi)網(wǎng)、YUPOO相冊(cè)、豆瓣、迅雷看看等多家網(wǎng)站、頻道使用Nginx服務(wù)器。Nginx特點(diǎn)如下:1）工作在OSI模型的第7層（應(yīng)用層）2）高并發(fā)連接官方測(cè)試能夠支撐5萬(wàn)并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到2?3萬(wàn)并發(fā)連接數(shù)。3）內(nèi)存消耗少在3萬(wàn)并發(fā)連接下，開(kāi)啟的10個(gè)Nginx進(jìn)程才消耗150M內(nèi)存（15M*10=150M）。4）配置文件非常簡(jiǎn)單風(fēng)格跟程序一樣通俗易懂。5）成本低廉Nginx為開(kāi)源軟件，可以免費(fèi)使用。而購(gòu)買(mǎi)F5BIG-IP、NetScaler等硬件負(fù)載均衡交換機(jī)則需要十多萬(wàn)至幾十萬(wàn)人民幣。6）支持Rewrite重寫(xiě)規(guī)則能夠根據(jù)域名、URL的不同，將HTTP請(qǐng)求分到不同的后端服務(wù)器群組。7）內(nèi)置的健康檢查功能如果NginxProxy后端的某臺(tái)Web服務(wù)器宕機(jī)了，不會(huì)影響前端訪問(wèn)。8）節(jié)省帶寬支持GZIP壓縮，可以添加瀏覽器本地緩存的Header頭。9）穩(wěn)定性高用于反向代理，宕機(jī)的概率微乎其微。3）Nginx+squid頁(yè)面緩存來(lái)實(shí)現(xiàn)反向代理負(fù)載均衡通過(guò)Nginx反向代理和squid緩存實(shí)現(xiàn)動(dòng)靜分離的架構(gòu)圖如下所示：5.Apache+tomcat集群實(shí)現(xiàn)負(fù)載均衡。使用apache和多個(gè)tomcat配置一個(gè)可以應(yīng)用的web網(wǎng)站，用Apache進(jìn)行分流，把請(qǐng)求按照權(quán)重以及當(dāng)時(shí)負(fù)荷分tomcat1,tomcat2...去處理，要達(dá)到以下要求：1）Apache做為HttpServer，通過(guò)mod_jk連接器連接多個(gè)tomcat應(yīng)用實(shí)例，并進(jìn)行負(fù)載均衡。2）同時(shí)還要配置session復(fù)制，也就是說(shuō)其中任何一個(gè)tomcat的添加的session，是要同步復(fù)制到其它tomcat，集群內(nèi)的tomcat都有相同的session，并為系統(tǒng)（包括Apache和tomcat）設(shè)定Session超時(shí)時(shí)間。2.3.2緩存系統(tǒng)架構(gòu)方面的緩存1）Squid緩存架構(gòu)方面使用Squid進(jìn)行緩存。注：SQUID使用了皿算法，W就是頁(yè)面血必尸里時(shí)間?*）和Lo炒Modred時(shí)間的差。Dote一般是網(wǎng)血從后面取頁(yè)面的時(shí)間ias山肱odgd一般是頁(yè)面生成時(shí)間。2）Nginx的緩存功能緩存把URL及相關(guān)組合當(dāng)作Key，用md5編碼哈希后保存；Nginx的Web緩存服務(wù)只能為指定URL或狀態(tài)碼設(shè)置過(guò)期時(shí)間，不支持類(lèi)似Squid的PURGE指令，手動(dòng)清除指定緩存頁(yè)面;采用MMAP實(shí)現(xiàn)，設(shè)置的緩存區(qū)大小不能超過(guò)物理內(nèi)存+SWEB的值3)基于memd的緩存nginx對(duì)memcached有所支持，但是功能并不是特別之強(qiáng)，性能上還是非常之優(yōu)秀。location/mem/{if($uri~f/mem/([0-9A-Za-z_]*)$"){set$memcached_key"$1";}expires70;}Nginx目前沒(méi)有寫(xiě)入memcached的任何機(jī)制，所以要往memcached里寫(xiě)入數(shù)據(jù)得用后臺(tái)的動(dòng)態(tài)語(yǔ)言完成，可以利用404定向到后端去寫(xiě)入數(shù)據(jù)。N“gMc會(huì)非常老實(shí)地將鏈接形式保存到文件系統(tǒng)中，這樣對(duì)于一個(gè)鏈接，可以很方便地查閱它在緩存機(jī)器上的緩存狀態(tài)和內(nèi)容，也可以很方便地和別的文件管理器如rsy砌等配合使用，它完完全全就是一個(gè)文件系統(tǒng)結(jié)構(gòu)。應(yīng)用程序方面的緩存OSCacheOSCache由OpenSymphony設(shè)計(jì)，它是一種開(kāi)創(chuàng)性的JSP定制標(biāo)記應(yīng)用，提供了在現(xiàn)有JSP頁(yè)面之內(nèi)實(shí)現(xiàn)快速內(nèi)存緩沖的功能，OSCache是個(gè)一個(gè)廣泛采用的高性能的J2EE緩存框架，OSCache能用于任何Java應(yīng)用程序的普通的緩存解決方案。OSCache有以下特點(diǎn)：緩存任何對(duì)象，你可以不受限制的緩存部分jsp頁(yè)面或HTTP請(qǐng)求，任何java對(duì)象都可以緩存。擁有全面的API--OSCacheAPI給你全面的程序來(lái)控制所有的OSCache特性。永久緩存--緩存能隨意的寫(xiě)入硬盤(pán)，因此允許昂貴的創(chuàng)建(expensive-to-create)數(shù)據(jù)來(lái)保持緩存，甚至能讓?xiě)?yīng)用重啟。支持集群--集群緩存數(shù)據(jù)能被單個(gè)的進(jìn)行參數(shù)配置，不需要修改代碼。緩存記錄的過(guò)期--你可以有最大限度的控制緩存對(duì)象的過(guò)期，包括可插入式的刷新策略(如果默認(rèn)性能不需要時(shí))。OSCache是當(dāng)前運(yùn)用最廣的緩存方案，JBoss,Hibernate,Spring等都對(duì)其有支持。OSCache的特點(diǎn)：1）緩存任何對(duì)象:你可以不受限制的緩存部分jsp頁(yè)面或HTTP請(qǐng)求，任何java對(duì)象都可以緩存。2）擁有全面的API：OSCacheAPI允許你通過(guò)編程的方式來(lái)控制所有的OSCache特性。3）永久緩存：緩存能被配置寫(xiě)入硬盤(pán)，因此允許在應(yīng)用服務(wù)器的多次生命周期間緩存創(chuàng)建開(kāi)銷(xiāo)昂貴的數(shù)據(jù)。4）支持集群：集群緩存數(shù)據(jù)能被單個(gè)的進(jìn)行參數(shù)配置，不需要修改代碼。5）緩存過(guò)期：你可以有最大限度的控制緩存對(duì)象的過(guò)期，包括可插入式的刷新策略（如果默認(rèn)性能不能滿足需要時(shí)）。2）Memcachedmemcached是高性能的分布式內(nèi)存緩存服務(wù)器。一般的使用目的是，通過(guò)緩存數(shù)據(jù)庫(kù)查詢(xún)結(jié)果，減少數(shù)據(jù)庫(kù)訪問(wèn)次數(shù)，以提高動(dòng)態(tài)Web應(yīng)用的速度、提高可擴(kuò)展性。Memcached是以Key/Value的形式單個(gè)對(duì)象緩存。3）自主開(kāi)發(fā)的內(nèi)存數(shù)據(jù)緩存服務(wù)a）獨(dú)立進(jìn)程方式的緩存服務(wù)對(duì)于一些常用的動(dòng)態(tài)數(shù)據(jù)通過(guò)開(kāi)發(fā)程序服務(wù)緩存在內(nèi)存中，提供給其他子系統(tǒng)調(diào)用，如下面的數(shù)據(jù)就可以通過(guò)這樣方式進(jìn)行緩存。1）用戶(hù)基本信息及狀態(tài)的信息緩沖2）列表緩存，就像論壇里帖子的列表3）記錄條數(shù)的緩存，比如一個(gè)論壇板塊里有多少個(gè)帖子，這樣才方便實(shí)現(xiàn)分頁(yè)。4）復(fù)雜一點(diǎn)的group，sum，count查詢(xún)，比如積分的分類(lèi)排名b）集成在WEB應(yīng)用中的內(nèi)存緩存在web應(yīng)用中對(duì)于熱點(diǎn)的功能，考慮使用完全裝載到內(nèi)存，保證絕對(duì)的響應(yīng)速度，對(duì)于需要頻繁訪問(wèn)的熱點(diǎn)數(shù)據(jù)，采用集中緩存（多個(gè)可以采用負(fù)載均衡），減輕數(shù)據(jù)庫(kù)的壓力，比如：很多配置信息，操作員信息等等。2.3.3頁(yè)面靜態(tài)化靜態(tài)的HTML頁(yè)面嚴(yán)格地由標(biāo)準(zhǔn)的HTML標(biāo)示語(yǔ)言構(gòu)成，并不需要服務(wù)器端即時(shí)運(yùn)算生成。這意味著，對(duì)一個(gè)靜態(tài)HTML文檔發(fā)出訪問(wèn)請(qǐng)求后，服務(wù)器端只是簡(jiǎn)單地將該文檔傳輸?shù)娇蛻?hù)端。從服務(wù)器運(yùn)行的那個(gè)時(shí)間片來(lái)看，這個(gè)傳輸過(guò)程僅僅占用了很小的CPU資源。頁(yè)面靜態(tài)化就是采用效率最高、消耗最小的純靜態(tài)化的html頁(yè)面來(lái)替換動(dòng)態(tài)頁(yè)面。我們盡可能使我們的網(wǎng)站上的頁(yè)面采用靜態(tài)頁(yè)面來(lái)實(shí)現(xiàn)，這個(gè)最簡(jiǎn)單的方法其實(shí)也是最有效的方法。同時(shí)采用第三方開(kāi)源的CMS系統(tǒng)來(lái)實(shí)現(xiàn)網(wǎng)站內(nèi)容的管理。對(duì)于大量?jī)?nèi)容并且頻繁更新的網(wǎng)站，我們無(wú)法全部手動(dòng)去挨個(gè)實(shí)現(xiàn)頁(yè)面靜態(tài)化，所以我們需要引入常見(jiàn)的信息發(fā)布系統(tǒng)CMS），信息發(fā)布系統(tǒng)（CMS）可以實(shí)現(xiàn)最簡(jiǎn)單的信息錄入自動(dòng)生成靜態(tài)頁(yè)面，對(duì)于一個(gè)大型網(wǎng)站來(lái)說(shuō)，擁有一套高效、可管理的CMS是必不可少的。同時(shí)，HTML靜態(tài)化也是某些緩存策略使用的手段，對(duì)于系統(tǒng)中頻繁使用數(shù)據(jù)庫(kù)查詢(xún)但是內(nèi)容更新很小的應(yīng)用，可以考慮使用HTML靜態(tài)化來(lái)實(shí)現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺(tái)管理并且再數(shù)據(jù)庫(kù)中，這些信息其實(shí)大量被前臺(tái)程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺(tái)更新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求。在進(jìn)行html靜態(tài)化的時(shí)候還可以使用一種折中的方法，就是前端繼續(xù)使用動(dòng)態(tài)實(shí)現(xiàn)，在一定的策略下通過(guò)后臺(tái)模塊進(jìn)行定時(shí)把動(dòng)態(tài)網(wǎng)頁(yè)生成靜態(tài)頁(yè)面，并定時(shí)判斷調(diào)用，這個(gè)能實(shí)現(xiàn)很多靈活性的操作。為了提高靜態(tài)HTML的訪問(wèn)效率，主要可以對(duì)以下幾個(gè)方面進(jìn)行優(yōu)化：網(wǎng)絡(luò)帶寬、磁盤(pán)I/O以及cache（高速緩沖存儲(chǔ)器）。2.3.4數(shù)據(jù)庫(kù)配置及優(yōu)化數(shù)據(jù)庫(kù)集群對(duì)生產(chǎn)數(shù)據(jù)庫(kù)采用RAC實(shí)現(xiàn)數(shù)據(jù)庫(kù)的集群。數(shù)據(jù)庫(kù)及表的散列把生產(chǎn)數(shù)據(jù)庫(kù)和查詢(xún)數(shù)據(jù)庫(kù)進(jìn)行分離，針對(duì)系統(tǒng)業(yè)務(wù)數(shù)據(jù)的特點(diǎn)，把大的表進(jìn)行拆分，對(duì)于訪問(wèn)較多的表采用分區(qū)表。使用讀/寫(xiě)數(shù)據(jù)庫(kù)分離，隨著系統(tǒng)變得越來(lái)越龐大，特別是當(dāng)它們擁有很差的SQL時(shí)，一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器通常不足以處理負(fù)載。但是多個(gè)數(shù)據(jù)庫(kù)意味著重復(fù)，除非你對(duì)數(shù)據(jù)進(jìn)行了分離。更一般地，這意味著建立主/從副本系統(tǒng)，其中程序會(huì)對(duì)主庫(kù)編寫(xiě)所有的Update、Insert和Delete變更語(yǔ)句，而所有Select的數(shù)據(jù)都讀取自從數(shù)據(jù)庫(kù)（或者多個(gè)從數(shù)據(jù)庫(kù)）。盡管概念上很簡(jiǎn)單，但是想要合理、精確地實(shí)現(xiàn)并不容易，這可能需要大量的代碼工作。因此，即便在開(kāi)始時(shí)使用同一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，也要盡早計(jì)劃在PHP中使用分離的DB連接來(lái)進(jìn)行讀寫(xiě)操作。如果正確地完成該項(xiàng)工作，那么系統(tǒng)就可以擴(kuò)展到2臺(tái)、3臺(tái)甚至12臺(tái)服務(wù)器，并具備高可用性和穩(wěn)定性。擁有良好的DB配置和備份很多公司都沒(méi)有良好的備份機(jī)制，也不知道如何恰當(dāng)?shù)赝瓿蛇@項(xiàng)工作。只有imp是不夠的，還需要進(jìn)行熱備份，從而得到超快的速度和超高的可靠性。另外，在將所有備份文件從服務(wù)器上轉(zhuǎn)移出來(lái)之前要進(jìn)行壓縮和加密。另外還要確保擁有設(shè)計(jì)合理的、有用的關(guān)于安全、性能和穩(wěn)定性問(wèn)題的設(shè)定，包括防止數(shù)據(jù)敗壞，其中很多設(shè)定都是非常重要的。2.3.5文件存儲(chǔ)文件共享1）HDFS（GFS）HDFS是ApacheHadoop項(xiàng)目中的一個(gè)分布式文件系統(tǒng)實(shí)現(xiàn)，基于Google于2003年10月發(fā)表的GoogleFileSystem（GFS）論文。特性1）硬件要求低2）高容錯(cuò)性3）易可擴(kuò)展4）配置簡(jiǎn)單5）超大文件HDFS采用master/slave架構(gòu)。一個(gè)HDFS集群是由一個(gè)Namenode和一定數(shù)目的。atanodes組成。2）NFS與GFS比較首先從它們的功能上進(jìn)行分析。NFS即網(wǎng)絡(luò)文件系統(tǒng)，是由SUN公司開(kāi)發(fā)的。它是FreeBSD支持的文件系統(tǒng)中的一種，允許一個(gè)系統(tǒng)在網(wǎng)絡(luò)上與它人共享目錄和文件。通過(guò)使用NFS，用戶(hù)和程序訪問(wèn)遠(yuǎn)端系統(tǒng)上的文件就像訪問(wèn)本地文件一樣。而GFS是Google為了滿足本公司迅速增長(zhǎng)的數(shù)據(jù)處理要求而開(kāi)發(fā)的文件系統(tǒng)。GFS是一個(gè)可擴(kuò)展的分布式文件系統(tǒng)，用于大型的、分布式的、對(duì)大量數(shù)據(jù)進(jìn)行訪問(wèn)的應(yīng)用。它是針對(duì)Google的計(jì)算機(jī)集群進(jìn)行設(shè)計(jì)的，專(zhuān)門(mén)是為Google頁(yè)面搜索的存儲(chǔ)進(jìn)行了優(yōu)化。所以從功能上看，它們兩者是完全不同的概念。其次從結(jié)構(gòu)上比較，NFS至少包括兩個(gè)主要部分：一臺(tái)服務(wù)器，以及至少一臺(tái)客戶(hù)機(jī)。被共享的目錄和文件存放在服務(wù)器上，客戶(hù)機(jī)遠(yuǎn)程地訪問(wèn)保存在服務(wù)器上的數(shù)據(jù)。GFS則由一臺(tái)Master（通常有幾臺(tái)備份）和若干臺(tái)TrunkServer構(gòu)成。GFS中文件備份成固定大小的Trunk分別存儲(chǔ)在不同的TrunkServer上，每個(gè)Trunk有多份（比如3）拷貝，也存儲(chǔ)在不同的TrunkServer上。Master負(fù)責(zé)維護(hù)GFS中的Metadata，即文件名及其Trunk信息?？蛻?hù)端先從Master上得到文件的Metadata，根據(jù)要讀取的數(shù)據(jù)在文件中的位置與相應(yīng)的TrunkServer通信，獲取文件數(shù)據(jù)。再?gòu)目缙脚_(tái)性上，NFS的基本原則是“容許不同的客戶(hù)端及服務(wù)端通過(guò)一組RPCs分享相同的文件系統(tǒng)”，它是獨(dú)立于操作系統(tǒng)的，容許不同的操作系統(tǒng)共同地進(jìn)行文件的共享。而GFS則沒(méi)有這一特點(diǎn)，文件只能被集群系統(tǒng)中的PC所訪問(wèn)，而且這些PC的操作系統(tǒng)一般是Linux。最后從規(guī)模上比較，HDFS只應(yīng)用在大批量的數(shù)據(jù)共享上。目前Google擁有超過(guò)200個(gè)的最后從規(guī)模上比較，GFS集群，其中有些集群的PC數(shù)量超過(guò)5000臺(tái)。集群的數(shù)據(jù)存儲(chǔ)規(guī)?？梢赃_(dá)到5個(gè)PB,并且集群中的數(shù)據(jù)讀寫(xiě)吞吐量可達(dá)到每秒40G。而NFS一般沒(méi)有這么巨大的規(guī)模。文件的多服務(wù)器自動(dòng)同步使用Linux2.6內(nèi)核的inotify監(jiān)控Linux文件系統(tǒng)事件。利用開(kāi)源的lsync監(jiān)聽(tīng)某一目錄，如果目錄內(nèi)文件發(fā)生增、刪、改，利用Rsync協(xié)議自動(dòng)同步到多臺(tái)服務(wù)器。圖片服務(wù)器分離特別是如果程序與圖片都放在同一個(gè)APAHCE的服務(wù)器下，每一個(gè)圖片的請(qǐng)求都有可能導(dǎo)致一個(gè)HTTPD進(jìn)程的調(diào)用。使用獨(dú)立的圖片服務(wù)器不但可以避免以上這個(gè)情況，更可以對(duì)不同的使用性質(zhì)的圖片設(shè)置不同的過(guò)期時(shí)間，以便同一個(gè)用戶(hù)在不同頁(yè)面訪問(wèn)相同圖片時(shí)不會(huì)再次從服務(wù)器（基于是緩存服務(wù)器）取數(shù)據(jù)，不但快速，而且還省了帶寬。還有就是，對(duì)于緩存的時(shí)間上，亦可以做獨(dú)立的調(diào)節(jié)。2.3.6網(wǎng)絡(luò)問(wèn)題解決方案你不可能要求所有的使用人員，都和你的服務(wù)器在一個(gè)運(yùn)營(yíng)商的網(wǎng)絡(luò)內(nèi)，而不同網(wǎng)絡(luò)之間訪問(wèn)速度會(huì)很慢，我們可以采用鏡像網(wǎng)站和引ACDN來(lái)解決這一問(wèn)題。智能DNS解析我們可以在不同的網(wǎng)絡(luò)運(yùn)營(yíng)商部署web服務(wù)器，通過(guò)linux上的rsync工具自動(dòng)同步到不同網(wǎng)絡(luò)接入商的web服務(wù)器上，以作為主站的鏡像。然后通過(guò)配置智能DNS解析來(lái)引導(dǎo)不同網(wǎng)絡(luò)的訪問(wèn)用戶(hù)到對(duì)應(yīng)的網(wǎng)絡(luò)運(yùn)營(yíng)商l的web服務(wù)器。CDN如果有足夠的投資，也可以采用CDN（內(nèi)容分發(fā)網(wǎng)），把靜態(tài)內(nèi)容（靜態(tài)頁(yè)面和圖片）進(jìn)行CDN緩存，以減輕服務(wù)器壓力。CDN的全稱(chēng)是Co*mDeliveryNetwork，即內(nèi)容分發(fā)網(wǎng)絡(luò)。它采取了分布式網(wǎng)絡(luò)緩存結(jié)構(gòu)（即國(guó)際上流行的瀝c?"e技術(shù)），其目的是通過(guò)在現(xiàn)有Sfeemet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶(hù)的網(wǎng)絡(luò)邊緣”，使用戶(hù)可以就近取得所需的內(nèi)容，解決mtemet網(wǎng)絡(luò)擁擠的狀況，提高用戶(hù)訪問(wèn)網(wǎng)站的響應(yīng)速度。從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶(hù)訪問(wèn)量大、網(wǎng)點(diǎn)分布不均等原因所造成的用戶(hù)訪問(wèn)網(wǎng)站響應(yīng)速度慢的問(wèn)題。（也就是一個(gè)服務(wù)器的內(nèi)容平均分部到多個(gè)服務(wù)器上，服務(wù)器智能識(shí)別，讓用戶(hù)獲取離用戶(hù)最近的服務(wù)器，提高速度。目前，國(guó)內(nèi)訪問(wèn)量較高的大型網(wǎng)站如新浪網(wǎng)易等，均使用CDN網(wǎng)絡(luò)加速技術(shù)，雖然網(wǎng)站的訪問(wèn)巨大，但無(wú)論在什么地方訪問(wèn)都會(huì)感覺(jué)速度很快。一般的網(wǎng)站如果服務(wù)器在網(wǎng)通，電信用戶(hù)訪問(wèn)很慢，如果服務(wù)器在電信，網(wǎng)通用戶(hù)訪問(wèn)又很慢。2.3.7WEB應(yīng)用開(kāi)發(fā)架構(gòu)設(shè)計(jì)思路基于MVC的三層應(yīng)用開(kāi)發(fā)架構(gòu)應(yīng)用開(kāi)發(fā)實(shí)現(xiàn)MVC三層架構(gòu)進(jìn)行web應(yīng)用開(kāi)發(fā)，采用ibatis作為持久層框架，c3p0作為數(shù)據(jù)庫(kù)連接池。iBATIS是一個(gè)可以設(shè)計(jì)和實(shí)現(xiàn)更好的Java應(yīng)用程序持久化層的框架°iBATIS把對(duì)象和存儲(chǔ)過(guò)程或者使用XML描述符的SQL語(yǔ)句進(jìn)行了關(guān)聯(lián)。簡(jiǎn)單是iBATIS最大的優(yōu)勢(shì)ibatis-使用ibatis的十個(gè)理由至少能操作10種以上的數(shù)據(jù)庫(kù)可配置的caching（包括從屬）支持DataSource、localtransactionmanagemen和globaltransaction簡(jiǎn)單的XML配置文檔支持Map,Collection,List和簡(jiǎn)單類(lèi)型包裝（如Integer,String）支持JavaBeans類(lèi)（get/set方法）支持復(fù)雜的對(duì)象映射（如populatinglists,complexobjectmodels）對(duì)象模型從不完美（不需要修改）數(shù)據(jù)模型從不完美（不需要修改）你已經(jīng)知道SQL，為什么還要學(xué)習(xí)其他東西1）MVC架構(gòu)示意2）Struts架構(gòu)客戶(hù)端發(fā)送一個(gè)HTTP請(qǐng)求，通過(guò)Struts框架最后獲得一個(gè)HTTP響應(yīng)，這一過(guò)程非常重要，它是理解Struts框架的重點(diǎn)。上圖描述了Struts框架的結(jié)構(gòu)，而下圖通過(guò)一個(gè)活動(dòng)圖更具體描述接受請(qǐng)求直至返回響應(yīng)的整個(gè)過(guò)程：面向服務(wù)的應(yīng)用架構(gòu)面向服務(wù)的應(yīng)用架構(gòu)是指構(gòu)建可分布式的、去中心化的服務(wù)器平臺(tái)，以提供許多不同的應(yīng)用，數(shù)據(jù)庫(kù)被分成很多個(gè)小部分，圍繞每個(gè)部分都會(huì)創(chuàng)建一個(gè)服務(wù)接口（API），并且該接口是訪問(wèn)數(shù)據(jù)庫(kù)的唯一途徑。最終數(shù)據(jù)庫(kù)演變成一個(gè)非常龐大的共享資源。這種架構(gòu)是松散耦合的，并且圍繞著服務(wù)進(jìn)行構(gòu)建。面向服務(wù)的架構(gòu)提供給他們隔離特性，一個(gè)服務(wù)可能有很多臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，他們之間的數(shù)據(jù)是相通的，而對(duì)外他們的接口只有一個(gè)，外面是無(wú)法知道這個(gè)服務(wù)后面的數(shù)據(jù)組織是如何搭建的。這樣就有了越來(lái)越多的應(yīng)用服務(wù)器。這些應(yīng)用服務(wù)器從數(shù)據(jù)眾多的服務(wù)（每個(gè)服務(wù)背后都有數(shù)據(jù)庫(kù)或集群數(shù)據(jù)庫(kù)）中聚合信息，然后生成我們所看到的A的各個(gè)網(wǎng)站頁(yè)面。這樣各種服務(wù)如插件一樣組成了一個(gè)開(kāi)放的平臺(tái)，這樣團(tuán)隊(duì)的規(guī)模就會(huì)比較小，比較靈活。注Amazon就是采用了這種架構(gòu)來(lái)構(gòu)建的，它擁有上千臺(tái)服務(wù)器。2.4系統(tǒng)軟件參數(shù)優(yōu)化在一定的架構(gòu)基礎(chǔ)上，要提高并發(fā)處理能力則需要調(diào)整服務(wù)器的操作系統(tǒng)內(nèi)核參數(shù)、web服務(wù)器（tomcat的參數(shù)、apache的參數(shù)、Nginx的參數(shù)），以使其性能達(dá)到最優(yōu)化。2.4.1操作系統(tǒng)優(yōu)化調(diào)整系統(tǒng)的內(nèi)核參數(shù)，增大連接數(shù)及TCP/IP的超時(shí)設(shè)置。Linux系統(tǒng)中：在/etc/sysctl.conf配置文件中增加如下內(nèi)核參數(shù)：2.4.2tomcat服務(wù)器優(yōu)化增大并發(fā)連接數(shù)，調(diào)整內(nèi)存參數(shù)的設(shè)置。1、JDK內(nèi)存優(yōu)化：當(dāng)應(yīng)用程序需要的內(nèi)存超出堆的最大值時(shí)虛擬機(jī)就會(huì)提示內(nèi)存溢出，并且導(dǎo)致應(yīng)用服務(wù)崩潰。因此一般建議堆的最大值設(shè)置為可用內(nèi)存的最大值的80%。Tomcat默認(rèn)可以使用的內(nèi)存為128MB，在較大型的應(yīng)用項(xiàng)目中，這點(diǎn)內(nèi)存是不夠的，需要調(diào)大.Tomcat默認(rèn)可以使用的內(nèi)存為128MB,Windows下,在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下設(shè)置：JAVA_OPTS='-Xms【初始化內(nèi)存大小】-Xmx【可以使用的最大內(nèi)存】’需要把這個(gè)兩個(gè)參數(shù)值調(diào)大。例如：JAVA_OPTS='-Xms256m-Xmx512m'表示初始化內(nèi)存為256MB，可以使用的最大內(nèi)存為512MB。2、連接器優(yōu)化：在tomcat配置文件server.xml中的配置中，和連接數(shù)相關(guān)的參數(shù)有：maxThreads：Tomcat使用線程來(lái)處理接收的每個(gè)請(qǐng)求。這個(gè)值表示Tomcat可創(chuàng)建的最大的線程數(shù)。默認(rèn)值150。acceptCount：指定當(dāng)所有可以使用的處理請(qǐng)求的線程數(shù)都被使用時(shí)，可以放到處理隊(duì)列中的請(qǐng)求數(shù)，超過(guò)這個(gè)數(shù)的請(qǐng)求將不予處理。默認(rèn)值10。minSpareThreads：Tomcat初始化時(shí)創(chuàng)建的線程數(shù)。默認(rèn)值25。maxSpareThreads：一旦創(chuàng)建的線程超過(guò)這個(gè)值，Tomcat就會(huì)關(guān)閉不再需要的socket線程。默認(rèn)值75。enableLookups：是否反查域名，默認(rèn)值為true。為了提高處理能力，應(yīng)設(shè)置為falseconnnectionTimeout:網(wǎng)絡(luò)連接超時(shí)，默認(rèn)值60000，單位：毫秒。設(shè)置為0表示永不超時(shí)，這樣設(shè)置有隱患的。通常可設(shè)置為30000毫秒。maxKeepAliveRequests：保持請(qǐng)求數(shù)量，默認(rèn)值100。bufferSize：輸入流緩沖大小，默認(rèn)值2048pression：壓縮傳輸，取值on/off/force，默認(rèn)值off。其中和最大連接數(shù)相關(guān)的參數(shù)為maxThreads和acceptCount。如果要加大并發(fā)連接數(shù)，應(yīng)同時(shí)加大這兩個(gè)參數(shù)。webserver允許的最大連接數(shù)還受制于*作系統(tǒng)的內(nèi)核參數(shù)設(shè)置，通常Windows是2000個(gè)左右，Linux是1000個(gè)左右。apache服務(wù)器優(yōu)化加大并發(fā)數(shù)量和關(guān)閉不需要的模塊。因?yàn)閍pache非常消耗內(nèi)存，盡量輕量化。Apache在配置ContentType的時(shí)候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率同時(shí)配置apache和tomcat的組合使之能作到動(dòng)靜分離，apache處理靜態(tài)頁(yè)面，tomcat處理動(dòng)態(tài)頁(yè)面。在處理靜態(tài)頁(yè)面或者圖片、js等訪問(wèn)方面，可以考慮使用代替Apache，它提供了更輕量級(jí)和更高效的處理能力Nginx服務(wù)器的優(yōu)化worker_processes：該參數(shù)的值最好跟cpu核數(shù)相等，能夠發(fā)揮最大性能，如果nginx所在服務(wù)器為2顆雙核cpu，則建議設(shè)定為4。3Web服務(wù)架構(gòu)評(píng)測(cè)主要對(duì)基于tomcat和nginx+tomca^web服務(wù)器的處理性能進(jìn)行測(cè)試，以作為不同性能要求下架構(gòu)選型的依據(jù)3.1測(cè)試環(huán)境3.1.1網(wǎng)絡(luò)環(huán)境內(nèi)網(wǎng)帶寬＞千M內(nèi)網(wǎng)。＞內(nèi)網(wǎng)ping包延遲：＜0.1ms網(wǎng)絡(luò)拓?fù)涫疽?.1.2服務(wù)器配置設(shè)備硬件配置操作系統(tǒng)NginxIBMX3650Redhatlinuxas4CPU:Intel(R)Xeon(R)E51502.66GHz2核*2內(nèi)存：4G千兆網(wǎng)卡Tomcat1HpDL580G4CPU:Intel(R)Xeon(TM)3.40GHz4核*2內(nèi)存：8G千兆網(wǎng)卡Redhatlinuxas5Tomcat2HpDL580G4CPU:Intel(R)Xeon(TM)3.40GHz4核*2內(nèi)存：8G千兆網(wǎng)卡Redhatlinuxas5Test1HpDL580G5CPU:Intel(R)Xeon(R)E73101.60GHz4核*2內(nèi)存：4G千兆網(wǎng)卡Redhatlinuxas5Test2IBMX3650CPU:Intel(R)Xeon(R)E51502.66GHz2核*2內(nèi)存：4G千兆網(wǎng)卡Redhatlinuxas43.1.3軟件環(huán)境操作系統(tǒng)網(wǎng)絡(luò)參數(shù)優(yōu)化用做測(cè)試的各臺(tái)服務(wù)器，均在/etc/sysctl.conf配置文件中增加如下內(nèi)核參數(shù):Nginx設(shè)置主要配置如下：userwwwwww;worker_processes4;error_log/usr/local/nginx/logs/nginx_error.logdebug;pid/usr/local/nginx/logs/nginx.pid;worker_rlimit_nofile51200;events{useepoll;worker_connections51200;}http{includemime.types;default_typeapplication/octet-stream;#charsetgb2312;server_names_hash_bucket_size128;client_header_buffer_size32k;large_client_header_buffers432k;sendfileon;tcp_nopushon;keepalive_timeout1;tcp_nodelayon;#gzipon;#gzip_min_length1k;#gzip_buffers416k;#gzip_http_version1.0;#gzip_comp_level2;#gzip_typestext/plainapplication/x-javascripttext/cssapplication/xml;#gzip_varyon;upstreamtomcats{}server{listen81;server_namelocalhost;proxy_redirectoff;location/{}#后端的Web服務(wù)器可以通過(guò)X-Forwarded-For獲取用戶(hù)真實(shí)IPproxy_set_headerX-Forwarded-For$remote_addr;location/{if($request_uri~*".*\.(js|css|gif|jpg|jpeg|png|bmp|swf)$")TOC\o"1-5"\h\z{}if($request_uri~*"A/view/(.*)$"){}#}#定義日志格式log_formataccess'$remote_addr-$remote_user[$time_local]$request'"$status"$body_bytes_sent"$http_referer"''"$http_user_agent""$http_x_forwarded_for"';#打日志access_log/usr/local/nginx/logs/access.logaccess;#允許客戶(hù)端請(qǐng)求的最大的單個(gè)文件字節(jié)數(shù)client_max_body_size10m;#緩沖區(qū)代理緩沖用戶(hù)端請(qǐng)求的最大字節(jié)數(shù)可以理解為先保存到本地再傳給用戶(hù)client_body_buffer_size128k;#跟后端服務(wù)器連接的超時(shí)時(shí)間_發(fā)起握手等候響應(yīng)超時(shí)時(shí)間proxy_connect_timeout600;TOC\o"1-5"\h\z#連接成功后_等候后端服務(wù)器響應(yīng)時(shí)間_其實(shí)已經(jīng)進(jìn)入后端的排隊(duì)之中等候處理proxy_read_timeout600;#后端服務(wù)器數(shù)據(jù)回傳時(shí)間_就是在規(guī)定時(shí)間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù)proxy_send_timeout600;#代理請(qǐng)求緩存區(qū)_這個(gè)緩存區(qū)間會(huì)保存用戶(hù)的頭信息以供Nginx進(jìn)行規(guī)則處理_一般只要能保存下頭信息即可proxy_buffer_size8k;#同上告訴Nginx保存單個(gè)用的幾個(gè)Buffer最大用多大空間proxy_buffers432k;#如果系統(tǒng)很忙的時(shí)候可以申請(qǐng)更大的proxy_buffers官方推薦*2proxy_busy_buffers_size64k;#proxy緩存臨時(shí)文件的大小proxy_temp_file_write_size64k;}}Tomcat設(shè)置主要配置如下：Tomcat5.5MaxThread500MinSpareThread25?MaxSpareThread75Xmx1740MJava環(huán)境>使用jdk1.6_03啟動(dòng)兩個(gè)Tomcato使用jdk1.6啟動(dòng)兩個(gè)客戶(hù)端的httpTes測(cè)試t進(jìn)程。

3.2測(cè)試結(jié)果3.2.1單個(gè)TOMCAT的WEB服務(wù)器NO客戶(hù)數(shù)線程數(shù)請(qǐng)求次數(shù)間隔時(shí)間測(cè)試服務(wù)器占用內(nèi)存服務(wù)器負(fù)載持續(xù)時(shí)間平均速度完成請(qǐng)求11500200萬(wàn)0毫秒Test11.1G>15082秒12986條/秒106萬(wàn)從第82秒開(kāi)始，tomcat占用內(nèi)負(fù)載急劇升高，top顯示已達(dá)1速度急劇下降，錯(cuò)包率100%，22500200萬(wàn)25毫秒Test11.7G<6288秒4765條/秒137萬(wàn)從第280秒左右開(kāi)始，tomcat請(qǐng)求速度急劇下降，出現(xiàn)錯(cuò)包，拋出““異常。Test2293秒4123條/秒120萬(wàn)32500200萬(wàn)50毫秒Test11.7G<3422秒2863條/秒120萬(wàn)服務(wù)端從第400秒左右開(kāi)始，tTest2請(qǐng)求速度急劇下降，開(kāi)始且仍在在增加中，之前的錯(cuò)包修Test2413秒2922條/秒120萬(wàn)42500200萬(wàn)200毫秒Test11.7G<2742秒1727條/秒128萬(wàn)服務(wù)端從第740秒左右開(kāi)始，tTest2請(qǐng)求速度急劇下降，開(kāi)女率只有0.008%，達(dá)到1.7g后，在增加中。web服務(wù)器負(fù)載小Test2744秒1608條/秒119萬(wàn)52500200萬(wàn)500毫秒Test11.7G<11595秒742條/秒118萬(wàn)服務(wù)端從第1595秒左右開(kāi)始，tTest2請(qǐng)求速度急劇下降，開(kāi)始達(dá)到1.7g后，截止停止測(cè)試時(shí)Test21575秒737條/秒116萬(wàn)62500300萬(wàn)1000毫秒Test11.7G<16362秒471條/秒300萬(wàn)在測(cè)試進(jìn)度到80%左右時(shí)，tomcaTest2請(qǐng)求速度并未下降，直到包，丟包率只有0.003%，最長(zhǎng)的Test26351秒472條/秒300萬(wàn)

3.2.2Nginx+2個(gè)TOMCAT的WEB服務(wù)器NO客戶(hù)端數(shù)線程數(shù)請(qǐng)求次數(shù)間隔時(shí)間測(cè)試服務(wù)器Tomcat占用內(nèi)存服務(wù)器負(fù)載持續(xù)時(shí)間平均速度完成請(qǐng)求數(shù)最大響應(yīng)時(shí)長(zhǎng)平均響時(shí)長(zhǎng)12250150萬(wàn)0毫秒Test11G<2347秒4322條/秒150萬(wàn)93005毫秒0.21毫Test11G322秒4658條/秒150萬(wàn)21244毫秒0.23毫22500200萬(wàn)25毫秒Test11.4G<2542秒3690條/秒200萬(wàn)45016毫秒0.27毫Test21.4G544秒3676條/秒200萬(wàn)45014毫秒0.27毫32500300萬(wàn)50毫秒Test11.7G<21140秒2445條/秒278萬(wàn)Test21.7G1141秒2424條/秒276萬(wàn)42500300萬(wàn)200毫秒Test11.7G<11860秒1490條/秒277萬(wàn)Test21.7G1863秒1482條/秒276萬(wàn)52500500萬(wàn)500毫秒Test11.7G<15475秒913條/秒500萬(wàn)93000毫秒1.09毫Test21.7G5565秒898條/秒500萬(wàn)92987毫秒1.11毫62500500萬(wàn)1000毫秒Test1968M<110149秒492條/秒500萬(wàn)9077毫秒2.02毫Test21G10149秒492條/秒500萬(wàn)9044毫秒2.02毫

3.2.3Nginx+2個(gè)TOMCAT的WEB服務(wù)器+緩沖NO客戶(hù)端數(shù)線程數(shù)請(qǐng)求次數(shù)間隔時(shí)間測(cè)試服務(wù)器Tomcat占用內(nèi)存服務(wù)器負(fù)載持續(xù)時(shí)間平均速度（條/秒）完成請(qǐng)求數(shù)最大響應(yīng)時(shí)長(zhǎng)平均響長(zhǎng)12250150萬(wàn)0毫秒Test10.2G<164秒23437150萬(wàn)9993毫秒0.041Test20.2G59秒25423150萬(wàn)3472毫秒0.04122500200萬(wàn)25毫秒Test10.4G<1196秒10202200萬(wàn)9616毫秒0.101Test20.4G194秒10361200萬(wàn)9608毫秒0.10132500300萬(wàn)50毫秒Test10.4G<1379秒7915300萬(wàn)9015毫秒0.131Test20.2G384秒7812300萬(wàn)10234毫秒0200毫秒Test10.4G<11220秒2459300萬(wàn)3018毫秒0.401Test20.2G1241秒2417300萬(wàn)3384毫秒0.41152500500萬(wàn)500毫秒Test10.4G<15031秒993500萬(wàn)3020毫秒1.001Test20.2G5055秒989500萬(wàn)3394毫秒1.01162500500萬(wàn)1000毫秒Test10.4G<110040秒498500萬(wàn)3020毫秒2.001Test20.2G10038秒498500萬(wàn)78毫秒2.001注：本次測(cè)試所用明頁(yè)面僅100個(gè)字節(jié)大小，測(cè)試過(guò)程中帶寬壓力可以忽略不計(jì)。測(cè)試過(guò)程中曾嘗試過(guò)使嫌大兆內(nèi)網(wǎng)下，無(wú)論是單頑《^亦或是晦如+277?^血，請(qǐng)求速度最大均不超過(guò)000條/秒，網(wǎng)絡(luò)帶寬使用已經(jīng)達(dá)至800此，實(shí)際應(yīng)用中，網(wǎng)絡(luò)帶寬對(duì)整個(gè)瀝服務(wù)的影響會(huì)非常大3.3測(cè)試結(jié)果分析系統(tǒng)參數(shù)的影響分析worker_processes參數(shù)對(duì)Nginx性能的影響測(cè)試過(guò)程中分別設(shè)定worker_processes為8、4、2、1時(shí)發(fā)現(xiàn)，該參數(shù)對(duì)nginx性能影響不大，對(duì)服務(wù)器資源消耗也沒(méi)有太大影響，相關(guān)資料顯示，該參數(shù)的值最好跟cpu核數(shù)相等，能夠發(fā)揮最大性能，本次測(cè)試nginx所在服務(wù)器為2顆雙核cpu，因此最終測(cè)試設(shè)定為4。MaxThread參數(shù)對(duì)tomcat并發(fā)性的影響本次測(cè)試tomcat的MaxThread參數(shù)設(shè)定為500，進(jìn)行13000條/秒并發(fā)測(cè)試時(shí)，tomcat啟動(dòng)并發(fā)線程過(guò)多，將服務(wù)器cpu耗盡。分析MaxThread雖能夠提高tomcat并發(fā)能力，但前提是在一個(gè)合理的范圍內(nèi)，要確保服務(wù)器負(fù)載不會(huì)因?yàn)椴l(fā)線程過(guò)多而急劇升高，從而停止響應(yīng)。-Xmx最大內(nèi)存值對(duì)Tomcat能夠持續(xù)響應(yīng)高并發(fā)的影響持續(xù)高并發(fā)請(qǐng)求狀態(tài)下，有6次測(cè)試是因?yàn)閠omcat內(nèi)存達(dá)到指定最大值導(dǎo)致響應(yīng)變慢，直至內(nèi)存溢出停止響應(yīng)，因此，Tomcat最大內(nèi)存對(duì)tomcat能夠持續(xù)響應(yīng)高并發(fā)請(qǐng)求有很大的影響，調(diào)整該值，應(yīng)該可以增加Tomcat響應(yīng)高并發(fā)請(qǐng)求的總數(shù)，進(jìn)而延長(zhǎng)WEB服務(wù)能夠支撐峰值的時(shí)間。各架構(gòu)下的性能分析Nginx+2Tomcat的最大并發(fā)性低于單Tomcat，Nginx+2Tomcat最快為8980條/秒，單Tomcat為12986條/秒，分析可能是受nginx所在服務(wù)器性能影響所致。單tomcat在配置1.7g最大內(nèi)存時(shí)，在持續(xù)超過(guò)1479條/秒的并發(fā)請(qǐng)求下，在穩(wěn)定支撐約240萬(wàn)次響應(yīng)后，Tomcat內(nèi)存達(dá)到1.7上限，之后Tomcat響應(yīng)會(huì)急劇變慢，錯(cuò)包急劇上升。Nginx+2tomcat架構(gòu)下，2個(gè)tomcat分別配置1.7g最大內(nèi)存時(shí)，在持續(xù)超過(guò)2900條/秒的并發(fā)請(qǐng)求下，能夠穩(wěn)定支撐約540萬(wàn)次左右響應(yīng)，之后兩個(gè)Tomcat內(nèi)存都會(huì)達(dá)到1.7上限，響應(yīng)會(huì)急劇變慢，但錯(cuò)包情況并未出現(xiàn)。在Nginx+2tomcat，同時(shí)配置了緩存的情況下，可以達(dá)到1.5萬(wàn)以上的并發(fā)處理能力3.4評(píng)測(cè)結(jié)果單個(gè)tomcat的處理能力在500條/秒左右單個(gè)tomcat能穩(wěn)定支持每秒500左右的并發(fā)請(qǐng)求。Nginx+Tomcat比單個(gè)Tomcat更穩(wěn)定，不易出現(xiàn)錯(cuò)包，可以通過(guò)擴(kuò)充tomcat集群(新增tomcat服務(wù)器)來(lái)提升系統(tǒng)的并發(fā)能力單個(gè)tomcat在超出并發(fā)能力的提求下，處理能力大大下降，并出現(xiàn)大量錯(cuò)包，而采用Nginx+2Tomcat架構(gòu)在各種測(cè)試下，均未出現(xiàn)錯(cuò)包，但處理能力也會(huì)下降。單個(gè)tomcat能穩(wěn)定支持每秒500左右的并發(fā)請(qǐng)求，而Nginx+2Tomcat能支持每秒1000左右的并發(fā)請(qǐng)求。所以可以通過(guò)新加tomcat務(wù)器來(lái)提升系統(tǒng)的并發(fā)能力，但在tomcat的總體處理能力超過(guò)nginx的處理能力時(shí)無(wú)效。3）Nginx+2Tomcat配置了緩存后，靜態(tài)頁(yè)面的并發(fā)能力不再受tomcat的限制，單個(gè)nginx的并發(fā)處理能力能達(dá)到1.5萬(wàn)以上。配置了緩存后，nginx+2tomcat的處理能力實(shí)測(cè)數(shù)據(jù)超過(guò)了1.5萬(wàn)次/秒，而單個(gè)tomcat可以支撐500次/秒，則從理論上計(jì)算一組Nginx+30個(gè)Tomcat集群可以支撐1.5萬(wàn)次/秒的并發(fā)處理。注：為tomcat均分配1.7G內(nèi)存。4配置選型4.1網(wǎng)絡(luò)帶寬只考慮門(mén)戶(hù)訪問(wèn)的帶寬占用，后臺(tái)管理頁(yè)面等其他業(yè)務(wù)訪問(wèn)與門(mén)戶(hù)訪問(wèn)相差2-3個(gè)數(shù)量級(jí)，這一部分網(wǎng)絡(luò)流量占用忽略。同時(shí)考慮網(wǎng)絡(luò)帶寬利用率（70%）根據(jù)業(yè)務(wù)設(shè)計(jì)能力，每秒網(wǎng)絡(luò)流量=WEB網(wǎng)站每秒鐘訪問(wèn)流量=（每次訪問(wèn)占用的帶寬X每秒訪問(wèn)次數(shù)）/帶寬利用率=（200K*8*n）/0.7注：一般門(mén)戶(hù)的首頁(yè)大?。?M、平均200K/頁(yè)面，我們以平均值來(lái)計(jì)算。并發(fā)能力占用的網(wǎng)絡(luò)帶寬100次/秒228M200次/秒457M500次/秒1442M1000次/秒2286M4.2架構(gòu)和硬件配置選型4.2.1硬件配置參考序號(hào)產(chǎn)品功能參考型號(hào)、配置TPMC1主機(jī)設(shè)備1.1數(shù)據(jù)庫(kù)服務(wù)器IBMSystemx3850M2,4個(gè)處理器，每處理器為6核，共計(jì)24核。內(nèi)存大小16G。SAS硬盤(pán)，硬盤(pán)大小587GB。4U機(jī)架，集成雙千兆以太網(wǎng)接口，兩塊千兆的光纖網(wǎng)卡。6845081.2WEB服務(wù)器IBMSystemx3850M2,4個(gè)處理器，每處理器為6核，共計(jì)24核。內(nèi)存大于8G。SAS硬盤(pán)，硬盤(pán)大小587GB。4U機(jī)架，集成雙千兆以太網(wǎng)接口，兩塊千兆的光纖網(wǎng)卡。6845081.3管理終端IBMSystemx3560，1個(gè)IntelXeonE5450處理器，內(nèi)存大小2G，2U機(jī)架。326002網(wǎng)絡(luò)設(shè)備

2.1負(fù)載均衡器RADWARE應(yīng)用負(fù)載均衡設(shè)備,型號(hào):為ODS-504,有，4個(gè)可選的千兆位電端口，1G主內(nèi)存，500M處理能力（最大可通過(guò)License升級(jí)為4G）2.2防火墻CISCOASA5520防火墻并發(fā)連接：280000網(wǎng)絡(luò)吞吐：450安全過(guò)濾：225MB網(wǎng)絡(luò)端口：4個(gè)千兆以太網(wǎng)接口+1個(gè)快速用戶(hù)數(shù)限：無(wú)用戶(hù)數(shù)限制用戶(hù)VPN支持：支持2.2交換機(jī)QuidwayS3952P-EI傳輸速率：10Mbps/100Mbps/1000Mbps網(wǎng)絡(luò)標(biāo)準(zhǔn)：IEEE802.1Q、IEEE802.1D端口數(shù)量：48接口介質(zhì)：10/100Base-T、1000Base-X傳輸模式：全雙工/半雙工自適應(yīng)背板帶寬：32Gbps3存儲(chǔ)設(shè)備3.1光纖存儲(chǔ)柜光纖存儲(chǔ)柜（EVA4100）3.2光纖交換機(jī)光纖交換機(jī)（4/32BSANSwitch）注：上表為硬件的參考配置，根據(jù)網(wǎng)站規(guī)模的不同，在初期可