門戶網(wǎng)站架構(gòu)設(shè)計文檔

/門戶網(wǎng)站架構(gòu)設(shè)計文檔

門戶網(wǎng)站架構(gòu)網(wǎng)站架構(gòu)前臺門戶網(wǎng)站架構(gòu)設(shè)計方案門戶網(wǎng)站架構(gòu)目錄123設(shè)計思路3系統(tǒng)結(jié)構(gòu)3網(wǎng)絡(luò)規(guī)劃及性能計算錯誤！未定義書簽。網(wǎng)絡(luò)架構(gòu)8網(wǎng)絡(luò)架構(gòu)說明錯誤！未定義書簽。接受雙防火墻雙交換機(jī)做網(wǎng)絡(luò)冗余，保障平臺服務(wù)8接受硬件設(shè)備負(fù)載均衡器，實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡8系統(tǒng)測算錯誤！未定義書簽。系統(tǒng)處理實(shí)力要求34業(yè)務(wù)處理實(shí)力要求錯誤！未定義書簽。系統(tǒng)話務(wù)模型錯誤！未定義書簽。配置核算錯誤！未定義書簽。數(shù)據(jù)庫服務(wù)器性能核算錯誤！未定義書簽。WEB服務(wù)器集群性能核算錯誤！未定義書簽。WEB服務(wù)器集群內(nèi)存性能核算錯誤！未定義書簽。網(wǎng)絡(luò)帶寬354性能模擬測試及性能推算錯誤！未定義書簽。測試環(huán)境錯誤！未定義書簽。測試結(jié)果錯誤！未定義書簽。1個客戶端模擬不同線和并發(fā)請求結(jié)果錯誤！未定義書簽。10個客戶端請求錯誤！未定義書簽。結(jié)果分析錯誤！未定義書簽。依據(jù)測試結(jié)果推算錯誤！未定義書簽。設(shè)備清單35硬件設(shè)備配置清單錯誤！未定義書簽。設(shè)備技術(shù)規(guī)格錯誤！未定義書簽。平臺擴(kuò)容的建議35網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)1網(wǎng)站的性能瓶頸分析網(wǎng)站的性能影響因素許多，下面主要從如下4個方面進(jìn)行分析說明：1)網(wǎng)絡(luò)負(fù)載a)公網(wǎng)負(fù)載b)內(nèi)網(wǎng)負(fù)載2)WEB應(yīng)用服務(wù)器性能a)CPUb)存儲，I/O訪問c)內(nèi)存d)并發(fā)TCP/IP連接數(shù)3)數(shù)據(jù)庫服務(wù)器性能a)數(shù)據(jù)庫參數(shù)配置b)服務(wù)器性能c)數(shù)據(jù)結(jié)構(gòu)的合理性4)不同WEB應(yīng)用的處理方式而對不同的性能瓶頸a)對于靜態(tài)的網(wǎng)站：靜態(tài)的HTML頁面嚴(yán)格地標(biāo)準(zhǔn)的HTML標(biāo)示語言構(gòu)成，并不須要服務(wù)器端即時運(yùn)算生成。這意味著，對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務(wù)器端只是簡潔地將該文檔傳輸?shù)娇蛻舳?。從服?wù)器運(yùn)行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。對于靜態(tài)HTML的訪問瓶頸為：網(wǎng)絡(luò)帶寬、磁盤I/O以及cache(高速緩沖存儲器)。b)對于動態(tài)頁面因?yàn)榉?wù)器解析動態(tài)頁面必需在其傳輸?shù)娇蛻舳饲熬屯ㄟ^服務(wù)器來進(jìn)行說明，這樣就會給應(yīng)用服務(wù)器添加額外的性能消耗，假如進(jìn)一步要訪問數(shù)據(jù)庫，則會增加數(shù)據(jù)庫服務(wù)器的性能消耗，則動態(tài)頁面還有額外的瓶頸：應(yīng)用服務(wù)器的性能，數(shù)據(jù)庫服務(wù)器的性能。2系統(tǒng)架構(gòu)設(shè)計總體思路為提高網(wǎng)站的高并發(fā)性能,提高開發(fā)效率及運(yùn)營效率,主要按如下幾個思路進(jìn)行規(guī)劃設(shè)計:負(fù)載均衡1)四層交換負(fù)載均衡：接受負(fù)載均衡器來實(shí)現(xiàn)硬件級的四層交換負(fù)載均衡，或接受LVS來實(shí)現(xiàn)軟件的四層交換負(fù)載均衡。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)2)通過第三方軟件來實(shí)現(xiàn)負(fù)載均衡,同時實(shí)現(xiàn)頁面請求的緩存。通過Nginx實(shí)現(xiàn)反向代理服務(wù)器集群，同時搭建squid集群以作為靜態(tài)頁面和圖片的緩存。3)通過web服務(wù)器的配置來實(shí)現(xiàn)負(fù)載均衡即通過apache或是Nginx將客戶請求均衡的分給tomcat1,tomcat2去處理。WEB應(yīng)用開發(fā)架構(gòu)思路1)應(yīng)用開發(fā)實(shí)現(xiàn)MVC架構(gòu)三層架構(gòu)進(jìn)行web應(yīng)用開發(fā)2)頁面盡可能靜態(tài)化以削減動態(tài)數(shù)據(jù)訪問，假如是資訊類的網(wǎng)站可以考慮接受第三方開源的CMS系統(tǒng)來生成靜態(tài)的內(nèi)容頁面。3)接受Oscache實(shí)現(xiàn)頁面緩存,接受Memcached實(shí)現(xiàn)數(shù)據(jù)緩存4)接受獨(dú)立的圖片服務(wù)器集群來實(shí)現(xiàn)圖片資源的存儲及WEB請求數(shù)據(jù)存儲的設(shè)計思路1)數(shù)據(jù)庫拆分,把生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫分別，對生產(chǎn)數(shù)據(jù)庫接受RAC實(shí)現(xiàn)數(shù)據(jù)庫的集群。2)接受高效的網(wǎng)絡(luò)文件共享策略，接受圖片服務(wù)器來實(shí)現(xiàn)頁面的圖片存儲。不同網(wǎng)絡(luò)用戶訪問考慮1)通過引入CDN來解決不同網(wǎng)絡(luò)服務(wù)商的接入速度問題，一般只能解決靜態(tài)頁面的訪問問題。2)在不同運(yùn)營商機(jī)房部署服務(wù)器，通過鏡像技術(shù)來實(shí)現(xiàn)不同網(wǎng)絡(luò)服務(wù)商的接入速度問題。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)總體架構(gòu)網(wǎng)站的系統(tǒng)分層架構(gòu)硬件四層交換軟件四層交換負(fù)載均衡器LVSNginxproxySquidNginxcache負(fù)載均衡反向代理軟件WEB服務(wù)SquidcacheApacheTomatControl...TomatWEB服務(wù)器架構(gòu)MVC應(yīng)用架構(gòu)應(yīng)用級緩存Model數(shù)據(jù)許久層(ibatis)頁面緩存(OSCache)View數(shù)據(jù)緩存(Memcached)查詢數(shù)據(jù)庫數(shù)據(jù)存儲文件共享NFSHDFS數(shù)據(jù)庫生產(chǎn)數(shù)據(jù)庫網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)網(wǎng)站的物理架構(gòu)Internet用戶閱讀頁面負(fù)載均衡器1...服務(wù)器1服務(wù)器2服務(wù)器3服務(wù)器2代理服務(wù)器集群服務(wù)器n服務(wù)器2...服務(wù)器1服務(wù)器2服務(wù)器1服務(wù)器2服務(wù)器1服務(wù)器2服務(wù)器1服務(wù)器n圖片服務(wù)器集群Web服務(wù)器集群AWeb服務(wù)器集群BSquid服務(wù)器集群網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)網(wǎng)站的開發(fā)架構(gòu)通訊層消息中心業(yè)務(wù)層WEB服務(wù)器許久層數(shù)據(jù)層數(shù)據(jù)存儲SMSMMSWAPPUSH基于struts的MVC框架ControlORMI/O文件存儲HDFS數(shù)據(jù)庫消息中心WEB容器請求ibatis數(shù)據(jù)ViewModelDB連接池生產(chǎn)數(shù)據(jù)庫JDBC頁面緩存ApacheTomat...Tomat短信群發(fā)器彩信群發(fā)器C3p0生產(chǎn)數(shù)據(jù)庫業(yè)務(wù)支撐模塊后臺支撐模塊HTML靜態(tài)化模塊統(tǒng)計支撐模塊查詢數(shù)據(jù)庫網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)Internet主防火墻備防火墻主交換機(jī)VRRP備交換機(jī)負(fù)載均衡器1負(fù)載均衡器2...服務(wù)器2服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器n服務(wù)器2服務(wù)器2服務(wù)器2...服務(wù)器2服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器2代理服務(wù)器集群網(wǎng)站服務(wù)器集群圖片服務(wù)器集群應(yīng)用服務(wù)器集群光纖交換機(jī)生產(chǎn)DB服務(wù)器集群查詢DB服務(wù)器組管理終端光纖交換機(jī)磁盤陣列柜磁盤陣列柜備注：1)接受雙防火墻雙交換機(jī)做網(wǎng)絡(luò)冗余，保障平臺服務(wù)接受雙防火墻通知接通2線路互聯(lián)網(wǎng)接入，設(shè)備之間接受VRRP協(xié)議，在任何一個防火墻、互聯(lián)網(wǎng)發(fā)生故障后均可自動將流量切換到另一端，保證網(wǎng)站的正運(yùn)行，設(shè)備或網(wǎng)絡(luò)復(fù)原后，自動復(fù)原。接受雙千兆交換機(jī)分別接在2臺防火墻上，當(dāng)某臺設(shè)備或者網(wǎng)絡(luò)鏈路發(fā)生故障后，好設(shè)備自動接管已壞設(shè)備的工作，不影響網(wǎng)站的整體運(yùn)行，依據(jù)業(yè)務(wù)及真實(shí)服務(wù)器的數(shù)量，交換機(jī)可以隨時增加。2)接受硬件設(shè)備負(fù)載均衡器，實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡運(yùn)用硬件設(shè)備負(fù)載均衡器，將網(wǎng)絡(luò)流量均衡的分擔(dān)到WEB服務(wù)器集群各節(jié)點(diǎn)服務(wù)器，保障平臺服務(wù)器資源均衡的運(yùn)用。3)接受代理服務(wù)器，實(shí)現(xiàn)軟件級的網(wǎng)絡(luò)負(fù)載均衡。4)數(shù)據(jù)庫服務(wù)器分別成生產(chǎn)數(shù)據(jù)庫集群和查詢數(shù)據(jù)庫集群，實(shí)現(xiàn)生產(chǎn)讀寫和后臺查詢統(tǒng)計進(jìn)行分別，同時生產(chǎn)數(shù)據(jù)庫接受rac技術(shù)進(jìn)行網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)架構(gòu)涉及技術(shù)的詳解負(fù)載均衡1.基于DNS的負(fù)載均衡--一個域名綁定多個IPDNS負(fù)載均衡技術(shù)是最早的負(fù)載均衡解決方案，它是通過DNS服務(wù)中的隨機(jī)名字解析來實(shí)現(xiàn)的，在DNS服務(wù)器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機(jī)將在解析這個名字時得到其中的一個地址。因此，對于同一個名字，不同的客戶機(jī)會得到不同的地址，它們也就訪問不同地址上的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。這種技術(shù)的優(yōu)點(diǎn)是，實(shí)現(xiàn)簡潔、實(shí)施簡潔、成本低、適用于大多數(shù)TCP/IP應(yīng)用；但是，其缺點(diǎn)也特殊明顯，首先這種方案不是真正意義上的負(fù)載均衡，DNS服務(wù)器將請求平均地支配到后臺的Web服務(wù)器上，而不考慮每個Web服務(wù)器當(dāng)前的負(fù)載狀況；假如后臺的Web服務(wù)器的配置和處理實(shí)力不同，最慢的Web服務(wù)器將成為系統(tǒng)的瓶頸，處理實(shí)力強(qiáng)的服務(wù)器不能充分發(fā)揮作用；其次未考慮容錯，假如后臺的某臺Web服務(wù)器出現(xiàn)故障，DNS服務(wù)器照舊會把DNS請求支配到這臺故障服務(wù)器上，導(dǎo)致不能響應(yīng)客戶端。最終一點(diǎn)是致命的，有可能造成相當(dāng)一部分客戶不能享受Web服務(wù)，并且于DNS緩存的緣由，所造成的后果要持續(xù)相當(dāng)長一段時間(一般DNS的刷新周期約為24小時)。所以在國外最新的建設(shè)中心Web站點(diǎn)方案中，已經(jīng)很少接受這種方案了。2.通過硬件四層交換實(shí)現(xiàn)負(fù)載均衡在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比如Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠供應(yīng)特殊優(yōu)秀的性能和很靈敏的管理實(shí)力。Yahoo中國當(dāng)時接近2000臺服務(wù)器運(yùn)用了三四臺Alteon就搞定了3.通過軟件四層交換實(shí)現(xiàn)負(fù)載均衡軟件四層交換我們可以運(yùn)用Linux上常用的LVS來解決，LVS就是LinuxVirtualServer，他供應(yīng)了基于心跳線heartbeat的實(shí)時災(zāi)難應(yīng)對解決方案，提高系統(tǒng)的魯棒性，同時可供了靈敏的虛擬VIP配置和管理功能，可以同時滿足多種應(yīng)用需求，這對于分布式的系統(tǒng)來說必不行少。一個典型的運(yùn)用負(fù)載均衡的策略就是，在軟件或者硬件四層交換的基礎(chǔ)上搭建squid集群，這種思路在許多大型網(wǎng)站包括搜尋引擎上被接受，這樣的架構(gòu)低成本、高性能還有很強(qiáng)的擴(kuò)張性。4.通過反向代理服務(wù)器實(shí)現(xiàn)負(fù)載均衡反向代理服務(wù)器又稱為WEB加速服務(wù)器，它位于WEB服務(wù)器的前端，充當(dāng)WEB服務(wù)器的內(nèi)容緩存器,反向代理服務(wù)器是針對WEB服務(wù)器設(shè)置的，后臺WEB服務(wù)器對互聯(lián)網(wǎng)用戶是透亮的，用戶只能看到反向代理服務(wù)器的地址，不清楚后臺WEB服務(wù)器是如何組織架構(gòu)的。當(dāng)互聯(lián)網(wǎng)用戶請求WEB服務(wù)時，DNS將請求的域名解析為反向代理服務(wù)器的IP地址，這樣URL請求將被發(fā)送到反向代理服務(wù)器，反向代理服務(wù)器負(fù)責(zé)處理用戶的請求和應(yīng)答、和后臺WEB服務(wù)器交互。利用網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)反向代理服務(wù)器減輕了后臺WEB服務(wù)器的負(fù)載，提高了訪問速度，同時避開了因用戶干脆和WEB服務(wù)器通信帶來的平安隱患。目前有許多反向代理軟件，比較出名的有Nginx和Squid。Nginx是IgorSysoev為俄羅斯訪問量其次的站點(diǎn)開發(fā)的，是一個高性能的和反向代理服務(wù)器，也是一個IMAP/POP3/SMTP代理服務(wù)器。Squid是美國政府大力資助的一項(xiàng)探討支配，其目的為解決網(wǎng)絡(luò)帶寬不足的問題，支持，S，F(xiàn)TP等多種協(xié)議，是現(xiàn)在Unix系統(tǒng)上運(yùn)用、最多功能也最完整的一套軟體。1）SquidSquid是一個開源的軟件，利用它的反向代理技術(shù)可以提高網(wǎng)站系統(tǒng)的訪問速度,下面將重點(diǎn)介紹Squid反向代理的實(shí)現(xiàn)原理和在提高網(wǎng)站性能方面的應(yīng)用。Squid反向代理服務(wù)器位于本地WEB服務(wù)器和Internet之間,組織架構(gòu)如下圖：客戶端請求訪問WEB服務(wù)時，DNS將訪問的域名解析為Squid反向代理服務(wù)器的IP地址，這樣客戶端的URL請求將被發(fā)送到反向代理服務(wù)器。假如Squid反向代理服務(wù)器中緩存了該請求網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)的資源，則將該請求的資源干脆返回給客戶端，否則反向代理服務(wù)器將向后臺的WEB服務(wù)器請求資源，然后將請求的應(yīng)答返回給客戶端，同時也將該應(yīng)答緩存在本地，供下一個請求者運(yùn)用。Squid反向代理一般只緩存可緩沖的數(shù)據(jù)，而一些CGI腳本程序或者ASP、JSP之類的動態(tài)程序默認(rèn)不緩存。它依據(jù)從WEB服務(wù)器返回的頭標(biāo)記來緩沖靜態(tài)頁面,有四個最重要頭標(biāo)記：????Last-Modified:告知反向代理頁面什么時間被修改Expires:告知反向代理頁面什么時間應(yīng)當(dāng)從緩沖區(qū)中刪除Cache-Control:告知反向代理頁面是否應(yīng)當(dāng)被緩沖Pragma:用來包含實(shí)現(xiàn)特定的指令，最常用的是Pragma:no-cache注：DNS的輪詢機(jī)制將某一個域名解析為多個IP地址。2）NginxNginx(“enginex”)是俄羅斯人IgorSysoev(塞索耶夫)編寫的一款高性能的和反向代理服務(wù)器。Nginx已經(jīng)在俄羅斯最大的門戶網(wǎng)站──RamblerMedia上運(yùn)行了4年時間，同時俄羅斯超過20%的虛擬主機(jī)平臺接受Nginx作為反向代理服務(wù)器。在國內(nèi)，已經(jīng)有新浪博客、新浪播客、搜狐通行證、網(wǎng)易新聞、網(wǎng)易博客、金山逍遙網(wǎng)、金山愛詞霸、校內(nèi)網(wǎng)、YUPOO相冊、豆瓣、迅雷看看等多家網(wǎng)站、頻道運(yùn)用Nginx服務(wù)器。Nginx特點(diǎn)如下：1)工作在OSI模型的第7層2)高并發(fā)連接官方測試能夠支撐5萬并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)。3)內(nèi)存消耗少在3萬并發(fā)連接下，開啟的10個Nginx進(jìn)程才消耗150M內(nèi)存。4)配置文件特殊簡潔風(fēng)格跟程序一樣通俗易懂。5)成本低廉Nginx為開源軟件，可以運(yùn)用。而購買F5BIG-IP、NetScaler等硬件負(fù)載均衡交換機(jī)則須要十多萬至幾十萬人民幣。6)支持Rewrite重寫規(guī)則能夠依據(jù)域名、URL的不同，將請求分到不同的后端服務(wù)器群組。7)內(nèi)置的健康檢查功能假如NginxProxy后端的某臺Web服務(wù)器宕機(jī)了，不會影響前端訪問。8)節(jié)約帶寬支持GZIP壓縮，可以添加閱讀器本地緩存的Header頭。9)穩(wěn)定性高用于反向代理，宕機(jī)的概率微乎其微。3）Nginx+squid頁面緩存來實(shí)現(xiàn)反向代理負(fù)載均衡通過Nginx反向代理和squid緩存實(shí)現(xiàn)動靜分別的架構(gòu)圖如下所示：網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)5.Apache+tomcat集群實(shí)現(xiàn)負(fù)載均衡。運(yùn)用apache和多個tomcat配置一個可以應(yīng)用的web網(wǎng)站，用Apache進(jìn)行分流，把請求依據(jù)權(quán)重以及當(dāng)時負(fù)荷分tomcat1,tomcat2...去處理，要達(dá)到以下要求：網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)1)Apache做為Server，通過mod_jk連接器連接多個tomcat應(yīng)用實(shí)例，并進(jìn)行負(fù)載均衡。2)同時還要配置session復(fù)制，也就是說其中任何一個tomcat的添加的session，是要同步復(fù)制到其它tomcat，集群內(nèi)的tomcat都有相同的session，并為系統(tǒng)設(shè)定Session超時時間。緩存1.系統(tǒng)架構(gòu)方面的緩存1）Squid緩存架構(gòu)方面運(yùn)用Squid進(jìn)行緩存。注：SQUID運(yùn)用了LM算法，LM就是頁面Header里時間(Date)和Last-Modified時間的差。Date一般是Squid從后面取頁面的時間，Last-Modified一般是頁面生成時間。2）Nginx的緩存功能Nginx從版本起先，支持了類似Squid的緩存功能；緩存把URL及相關(guān)組合當(dāng)作Key，用md5編碼哈希后保存；Nginx的Web緩存服務(wù)只能為指定URL或狀態(tài)碼設(shè)置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面；接受MMAP實(shí)現(xiàn)，設(shè)置的緩存區(qū)大小不能超過物理內(nèi)存+SWEB的值3）基于memcached的緩存nginx對memcached有所支持，但是功能并不是特殊之強(qiáng)，性能上還是特殊之優(yōu)秀。location/mem/{if($uri~\{set$memcached_key\memcached_pass:11211;}expires70;}這個配置會將/mem/abc指明到memcached的abc這個key去取數(shù)據(jù)。Nginx目前沒有寫入memcached的任何機(jī)制，所以要往memcached里寫入數(shù)據(jù)得用后臺的動態(tài)語言完成，可以利用404定向到后端去寫入數(shù)據(jù)。Nginx傳統(tǒng)緩存的缺點(diǎn)也是它和squid等緩存軟件的不同之特色，所以也可看作其優(yōu)點(diǎn)。在生產(chǎn)應(yīng)用中它常常用作和squid的搭檔，squid對于帶?的鏈接往往無法阻擋，而nginx能將其訪問攔住，例如：/?和/在squid上會被當(dāng)做兩個鏈接，所以會造成兩次穿透；而nginx只會保存一次，無論鏈接變成網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)/?1還是/?123，均不能透過nginx緩存，從而有效地愛惜了后端主機(jī)。nginx會特殊醇厚地將鏈接形式保存到文件系統(tǒng)中，這樣對于一個鏈接，可以很便利地查閱它在緩存機(jī)器上的緩存狀態(tài)和內(nèi)容，也可以很便利地和別的文件管理器如rsync等協(xié)作運(yùn)用，它完完全全就是一個文件系統(tǒng)結(jié)構(gòu)。2.應(yīng)用程序方面的緩存1）OSCacheOSCacheOpenSymphony設(shè)計，它是一種開創(chuàng)性的JSP定制標(biāo)記應(yīng)用，供應(yīng)了在現(xiàn)有JSP頁面之內(nèi)實(shí)現(xiàn)快速內(nèi)存緩沖的功能，OSCache是個一個廣泛接受的高性能的J2EE緩存框架，OSCache能用于任何Java應(yīng)用程序的一般的緩存解決方案。OSCache有以下特點(diǎn)：緩存任何對象，你可以不受限制的緩存部分jsp頁面或請求，任何java對象都可以緩存。擁有全面的API--OSCacheAPI給你全面的程序來限制全部的OSCache特性。永久緩存--緩存能隨意的寫入硬盤，因此允許昂貴的創(chuàng)建數(shù)據(jù)來保持緩存，甚至能讓應(yīng)用重啟。支持集群--集群緩存數(shù)據(jù)能被單個的進(jìn)行參數(shù)配置，不須要修改代碼。緩存記錄的過期--你可以有最大限度的限制緩存對象的過期，包括可插入式的刷新策略。OSCache是當(dāng)前運(yùn)用最廣的緩存方案，JBoss,Hibernate,Spring等都對其有支持。OSCache的特點(diǎn):1)緩存任何對象：你可以不受限制的緩存部分jsp頁面或請求，任何java對象都可以緩存。2)擁有全面的API：OSCacheAPI允許你通過編程的方式來限制全部的OSCache特性。3)永久緩存：緩存能被配置寫入硬盤，因此允許在應(yīng)用服務(wù)器的多次生命周期間緩存創(chuàng)建開銷昂貴的數(shù)據(jù)。4)支持集群：集群緩存數(shù)據(jù)能被單個的進(jìn)行參數(shù)配置，不須要修改代碼。5)緩存過期：你可以有最大限度的限制緩存對象的過期，包括可插入式的刷新策略。2）Memcachedmemcached是高性能的分布式內(nèi)存緩存服務(wù)器。一般的運(yùn)用目的是，通過緩存數(shù)據(jù)庫查詢結(jié)果，削減數(shù)據(jù)庫訪問次數(shù)，以提高動態(tài)Web應(yīng)用的速度、提高可擴(kuò)展性。Memcached是以Key/Value的形式單個對象緩存。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)3）自主開發(fā)的內(nèi)存數(shù)據(jù)緩存服務(wù)a）獨(dú)立進(jìn)程方式的緩存服務(wù)對于一些常用的動態(tài)數(shù)據(jù)通過開發(fā)程序服務(wù)緩存在內(nèi)存中，供應(yīng)應(yīng)其他子系統(tǒng)調(diào)用，如下面的數(shù)據(jù)就可以通過這樣方式進(jìn)行緩存。1)用戶基本信息及狀態(tài)的信息緩沖2)列表緩存，就像論壇里帖子的列表3)記錄條數(shù)的緩存，比如一個論壇板塊里有多少個帖子，這樣才便利實(shí)現(xiàn)分頁。4)困難一點(diǎn)的group，sum，count查詢，比如積分的分類排名b）集成在WEB應(yīng)用中的內(nèi)存緩存在web應(yīng)用中對于熱點(diǎn)的功能，考慮運(yùn)用完全裝載到內(nèi)存，保證確定的響應(yīng)速度，對于須要頻繁訪問的熱點(diǎn)數(shù)據(jù)，接受集中緩存(多個可以接受負(fù)載均衡)，減輕數(shù)據(jù)庫的壓力，比如：許多配置信息，操作員信息等等。頁面靜態(tài)化靜態(tài)的HTML頁面嚴(yán)格地標(biāo)準(zhǔn)的HTML標(biāo)示語言構(gòu)成，并不須要服務(wù)器端即時運(yùn)算生成。這意味著，對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務(wù)器端只是簡潔地將該文檔傳輸?shù)娇蛻舳?。從服?wù)器運(yùn)行的那個時間片來看，這個傳輸過程僅僅占用了很小的CPU資源。頁面靜態(tài)化就是接受效率最高、消耗最小的純靜態(tài)化的html頁面來替換動態(tài)頁面。我們盡可能使我們的網(wǎng)站上的頁面接受靜態(tài)頁面來實(shí)現(xiàn)，這個最簡潔的方法其實(shí)也是最有效的方法。網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)同時接受第三方開源的CMS系統(tǒng)來實(shí)現(xiàn)網(wǎng)站內(nèi)容的管理。對于大量內(nèi)容并且頻繁更新的網(wǎng)站，我們無法全部手動去挨個實(shí)現(xiàn)頁面靜態(tài)化，所以我們須要引入常見的信息發(fā)布系統(tǒng)(CMS)，信息發(fā)布系統(tǒng)(CMS)可以實(shí)現(xiàn)最簡潔的信息錄入自動生成靜態(tài)頁面，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不行少的。同時，HTML靜態(tài)化也是某些緩存策略運(yùn)用的手段，對于系統(tǒng)中頻繁運(yùn)用數(shù)據(jù)庫查詢但是內(nèi)容更新很小的應(yīng)用，可以考慮運(yùn)用HTML靜態(tài)化來實(shí)現(xiàn)，比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實(shí)大量被前臺程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺更新的時候進(jìn)行靜態(tài)化，這樣避開了大量的數(shù)據(jù)庫訪問請求。在進(jìn)行html靜態(tài)化的時候還可以運(yùn)用一種折中的方法，就是前端接著運(yùn)用動態(tài)實(shí)現(xiàn)，在確定的策略下通過后臺模塊進(jìn)行定時把動態(tài)網(wǎng)頁生成靜態(tài)頁面，并定時推斷調(diào)用，這個能實(shí)現(xiàn)許多靈敏性的操作。為了提高靜態(tài)HTML的訪問效率，主要可以對以下幾個方面進(jìn)行優(yōu)化：網(wǎng)絡(luò)帶寬、磁盤I/O以及cache(高速緩沖存儲器)。數(shù)據(jù)庫配置及優(yōu)化1.數(shù)據(jù)庫集群對生產(chǎn)數(shù)據(jù)庫接受RAC實(shí)現(xiàn)數(shù)據(jù)庫的集群。2.數(shù)據(jù)庫及表的散列把生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫進(jìn)行分別，針對系統(tǒng)業(yè)務(wù)數(shù)據(jù)的特點(diǎn)，把大的表進(jìn)行拆分，對于訪問較多的表接受分區(qū)表。運(yùn)用讀/寫數(shù)據(jù)庫分別，隨著系統(tǒng)變得越來越浩大，特殊是當(dāng)它們擁有很差的SQL時，一臺數(shù)據(jù)庫服務(wù)器通常不足以處理負(fù)載。但是多個數(shù)據(jù)庫意味著重復(fù)，除非你對數(shù)據(jù)進(jìn)行了分別。更一般地，這意味著建立主/從副本系統(tǒng)，其中程序會對主庫編寫全部的Update、Insert和Delete變更語句，而全部Select的數(shù)據(jù)都讀取自從數(shù)據(jù)庫。盡管概念上很簡潔，但是想要合理、精確地實(shí)現(xiàn)并不簡潔，這可能須要大量的代碼工作。因此，即便在起先時運(yùn)用同一臺數(shù)據(jù)庫服務(wù)器，也要盡早支配在PHP中運(yùn)用分別的DB連接來進(jìn)行讀寫操作。假如正確地完成該項(xiàng)工作，那么系統(tǒng)就可以擴(kuò)展到2臺、3臺甚至12臺服務(wù)器，并具備高可用性和穩(wěn)定性。3.擁有良好的DB配置和備份許多公司都沒有良好的備份機(jī)制，也不知道如何恰當(dāng)?shù)赝瓿蛇@項(xiàng)工作。只有imp是不夠的，還須要進(jìn)行熱備份，從而得到超快的速度和超高的牢靠性。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)另外，在將全部備份文件從服務(wù)器上轉(zhuǎn)移出來之前要進(jìn)行壓縮和加密。另外還要確保擁有設(shè)計合理的、有用的關(guān)于平安、性能和穩(wěn)定性問題的設(shè)定，包括防止數(shù)據(jù)敗壞，其中許多設(shè)定都是特殊重要的。文件存儲1.文件共享1）HDFSHDFS是ApacheHadoop項(xiàng)目中的一個分布式文件系統(tǒng)實(shí)現(xiàn)，基于Google于2003年10月發(fā)表的GoogleFileSystem(GFS)論文。?特性1)硬件要求低2)高容錯性3)易可擴(kuò)展4)配置簡潔5)超大文件HDFS接受master/slave架構(gòu)。一個HDFS集群是一個Namenode和確定數(shù)目的Datanodes組成。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)2）NFS和GFS比較首先從它們的功能上進(jìn)行分析。NFS即網(wǎng)絡(luò)文件系統(tǒng)，是SUN公司開發(fā)的。它是FreeBSD支持的文件系統(tǒng)中的一種，允許一個系統(tǒng)在網(wǎng)絡(luò)上和它人共享書目和文件。通過運(yùn)用NFS，用戶和程序訪問遠(yuǎn)端系統(tǒng)上的文件就像訪問本地文件一樣。而GFS是Google為了滿足本公司快速增長的數(shù)據(jù)處理要求而開發(fā)的文件系統(tǒng)。GFS是一個可擴(kuò)展的分布式文件系統(tǒng)，用于大型的、分布式的、對大量數(shù)據(jù)進(jìn)行訪問的應(yīng)用。它是針對Google的計算機(jī)集群進(jìn)行設(shè)計的，特地是為Google頁面搜尋的存儲進(jìn)行了優(yōu)化。所以從功能上看，它們兩者是完全不同的概念。其次從結(jié)構(gòu)上比較，NFS至少包括兩個主要部分：一臺服務(wù)器，以及至少一臺客戶機(jī)。被共享的書目和文件存放在服務(wù)器上，客戶機(jī)遠(yuǎn)程地訪問保存在服務(wù)器上的數(shù)據(jù)。GFS則一臺Master(通常有幾臺備份)和若干臺TrunkServer構(gòu)成。GFS中文件備份成固定大小的Trunk分別存儲在不同的TrunkServer上，每個Trunk有多份(比如3)拷貝，也存儲在不同的TrunkServer上。Master負(fù)責(zé)維護(hù)GFS中的Metadata，即文件名及其Trunk信息。客戶端先從Master上得到文件的Metadata，依據(jù)要讀取的數(shù)據(jù)在文件中的位置和相應(yīng)的TrunkServer通信，獲得文件數(shù)據(jù)。再從跨平臺性上，NFS的基本原則是“容許不同的客戶端及服務(wù)端通過一組RPCs共享相同的文件系統(tǒng)”，它是獨(dú)立于操作系統(tǒng)的，容許不同的操作系統(tǒng)共同地進(jìn)行文件的共享。而GFS則沒有這一特點(diǎn)，文件只能被集群系統(tǒng)中的PC所訪問，而且這些PC的操作系統(tǒng)一般是Linux。最終從規(guī)模上比較，HDFS只應(yīng)用在大批量的數(shù)據(jù)共享上。目前Google擁有超過200個的GFS集群，其中有些集群的PC數(shù)量超過5000臺。集群的數(shù)據(jù)存儲規(guī)?？梢赃_(dá)到5個PB，并且集群中的數(shù)據(jù)讀寫吞吐量可達(dá)到每秒40G。而NFS一般沒有這么巨大的規(guī)模。2.文件的多服務(wù)器自動同步運(yùn)用Linux內(nèi)核的inotify監(jiān)控Linux文件系統(tǒng)事務(wù)。利用開源的lsync監(jiān)聽某一書目，假如書目內(nèi)文件發(fā)生增、刪、改，利用Rsync協(xié)議自動同步到多臺服務(wù)器。3.圖片服務(wù)器分別特殊是假如程序和圖片都放在同一個APAHCE的服務(wù)器下，每一個圖片的請求都有可能導(dǎo)致一個D進(jìn)程的調(diào)用。運(yùn)用獨(dú)立的圖片服務(wù)器不但可以避開以上這個狀況，更可以對不同的運(yùn)用性質(zhì)的圖片設(shè)置不同的過期時間，以便同一個用戶在不同頁面訪問相同圖片時不會再次從服務(wù)器取數(shù)據(jù)，不但快速，而且還省了帶寬。還有就是，對于緩存的時間上，亦可以做獨(dú)立的調(diào)整。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)網(wǎng)絡(luò)問題解決方案你不行能要求全部的運(yùn)用人員，都和你的服務(wù)器在一個運(yùn)營商的網(wǎng)絡(luò)內(nèi)，而不同網(wǎng)絡(luò)之間訪問速度會很慢，我們可以接受鏡像網(wǎng)站和引入CDN來解決這一問題。用戶動態(tài)內(nèi)容靜態(tài)內(nèi)容智能DNS解析電信用戶網(wǎng)通用戶CDN其他用戶服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器n服務(wù)器1服務(wù)器n電信機(jī)房多線機(jī)房網(wǎng)通機(jī)房1.智能DNS解析我們可以在不同的網(wǎng)絡(luò)運(yùn)營商部署web服務(wù)器，通過linux上的rsync工具自動同步到不同網(wǎng)絡(luò)接入商的web服務(wù)器上，以作為主站的鏡像。然后通過配置智能DNS解析來引導(dǎo)不同網(wǎng)絡(luò)的訪問用戶到對應(yīng)的網(wǎng)絡(luò)運(yùn)營商的web服務(wù)器。2.CDN假如有足夠的投資，也可以接受CDN(內(nèi)容分發(fā)網(wǎng))，把靜態(tài)內(nèi)容進(jìn)行CDN緩存，以減輕服務(wù)器壓力。CDN的全稱是ContentDeliveryNetwork，即內(nèi)容分發(fā)網(wǎng)絡(luò)。它實(shí)行了分布式網(wǎng)絡(luò)緩存結(jié)構(gòu)，其目的是通過在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)\邊緣\，運(yùn)用戶可以就近取得所需的內(nèi)容，解決Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。從技術(shù)上全面解決于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點(diǎn)分布不均等緣由所造成的用戶訪問網(wǎng)站響應(yīng)速度慢的問題。(也就是一個服務(wù)器的內(nèi)容，平均分部到多個服網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)務(wù)器上，服務(wù)器智能識別，讓用戶獲得離用戶最近的服務(wù)器，提高速度。目前，國內(nèi)訪問量較高的大型網(wǎng)站如新浪、網(wǎng)易等，均運(yùn)用CDN網(wǎng)絡(luò)加速技術(shù)，雖然網(wǎng)站的訪問巨大，但無論在什么地方訪問都會感覺速度很快。而一般的網(wǎng)站假如服務(wù)器在網(wǎng)通，電信用戶訪問很慢，假如服務(wù)器在電信，網(wǎng)通用戶訪問又很慢。WEB應(yīng)用開發(fā)架構(gòu)設(shè)計思路1.基于MVC的三層應(yīng)用開發(fā)架構(gòu)應(yīng)用開發(fā)實(shí)現(xiàn)MVC三層架構(gòu)進(jìn)行web應(yīng)用開發(fā)，接受ibatis作為許久層框架，c3p0作為數(shù)據(jù)庫連接池。iBATIS是一個可以設(shè)計和實(shí)現(xiàn)更好的Java應(yīng)用程序許久化層的框架。iBATIS把對象和存儲過程或者運(yùn)用XML描述符的SQL語句進(jìn)行了關(guān)聯(lián)。簡潔是iBATIS最大的優(yōu)勢?ibatis-運(yùn)用ibatis的十個理1.至少能操作10種以上的數(shù)據(jù)庫2.可配置的caching(包括從屬)3.支持DataSource、localtransactionmanagemen和globaltransaction4.簡潔的XML配置文檔5.支持Map,Collection,List和簡潔類型包裝(如Integer,String)6.支持JavaBeans類(get/set方法)7.支持困難的對象映射(如populatinglists,complexobjectmodels)8.對象模型從不完備(不須要修改)9.數(shù)據(jù)模型從不完備(不須要修改)10.你已經(jīng)知道SQL，為什么還要學(xué)習(xí)其他東西網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)1）MVC架構(gòu)示意網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)2）Struts架構(gòu)客戶端發(fā)送一個請求，通過Struts框架最終獲得一個響應(yīng)，這一過程特殊重要，它是理解Struts框架的重點(diǎn)。上圖描述了Struts框架的結(jié)構(gòu)，而下圖通過一個活動圖更具體描述接受請求直至返回響應(yīng)的整個過程：網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)2.面對服務(wù)的應(yīng)用架構(gòu)面對服務(wù)的應(yīng)用架構(gòu)是指構(gòu)建可分布式的、去中心化的服務(wù)器平臺，以供應(yīng)許多不同的應(yīng)用，數(shù)據(jù)庫被分成許多個小部分，圍繞每個部分都會創(chuàng)建一個服務(wù)接口(API),并且該接口是訪問數(shù)據(jù)庫的唯一途徑。最終數(shù)據(jù)庫演化成一個特殊浩大的共享資源。這種架構(gòu)是松散耦合的，并且圍圍著服務(wù)進(jìn)行構(gòu)建。面對服務(wù)的架構(gòu)供應(yīng)應(yīng)他們隔離特性，一個服務(wù)可能有許多臺數(shù)據(jù)庫服務(wù)器，他們之間的數(shù)據(jù)是相通的，而對外他們的接口只有一個，外面是無法知道這個服務(wù)后面的數(shù)據(jù)組織是如何搭建的。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)這樣就有了越來越多的應(yīng)用服務(wù)器。這些應(yīng)用服務(wù)器從數(shù)據(jù)眾多的服務(wù)中聚合信息，然后生成我們所看到的的各個網(wǎng)站頁面。這樣各種服務(wù)如插件一樣組成了一個開放的平臺，這樣團(tuán)隊的規(guī)模就會比較小，比較靈敏。注Amazon就是接受了這種架構(gòu)來構(gòu)建的，它擁有上千臺服務(wù)器。系統(tǒng)軟件參數(shù)優(yōu)化在確定的架構(gòu)基礎(chǔ)上，要提高并發(fā)處理實(shí)力則須要調(diào)整服務(wù)器的操作系統(tǒng)內(nèi)核參數(shù)、web服務(wù)器，以使其性能達(dá)到最優(yōu)化。操作系統(tǒng)優(yōu)化調(diào)整系統(tǒng)的內(nèi)核參數(shù)，增大連接數(shù)及TCP/IP的超時設(shè)置。Linux系統(tǒng)中：在/etc/配置文件中增加如下內(nèi)核參數(shù)：_syncookies=1_tw_reuse=1_tw_recycle=1_fin_timeout=5tomcat服務(wù)器優(yōu)化增大并發(fā)連接數(shù)，調(diào)整內(nèi)存參數(shù)的設(shè)置。1、JDK內(nèi)存優(yōu)化：當(dāng)應(yīng)用程序須要的內(nèi)存超出堆的最大值時虛擬機(jī)就會提示內(nèi)存溢出，并且導(dǎo)致應(yīng)用服務(wù)崩潰。因此一般建議堆的最大值設(shè)置為可用內(nèi)存的最大值的80%。Tomcat默認(rèn)可以運(yùn)用的內(nèi)存為128MB，在較大型的應(yīng)用項(xiàng)目中，這點(diǎn)內(nèi)存是不夠的，須要調(diào)大.Tomcat默認(rèn)可以運(yùn)用的內(nèi)存為128MB,Windows下,在文件/bin/，Unix下，在文件/bin/的前面，增加如下設(shè)置：JAVA_OPTS=‘-Xms【初始化內(nèi)存大小】-Xmx【可以運(yùn)用的最大內(nèi)存】’須要把這個兩個參數(shù)值調(diào)大。例如：JAVA_OPTS=‘-Xms256m-Xmx512m’表示初始化內(nèi)存為256MB，可以運(yùn)用的最大內(nèi)存為512MB。2、連接器優(yōu)化：在tomcat配置文件中的配置中，和連接數(shù)相關(guān)的參數(shù)有：maxThreads：Tomcat運(yùn)用線程來處理接收的每個請求。這個值表示Tomcat可創(chuàng)建的最大的線程數(shù)。默認(rèn)值150。acceptCount：指定當(dāng)全部可以運(yùn)用的處理請求的線程數(shù)都被運(yùn)用時，可以放到處理隊列中的請求數(shù)，超過這個數(shù)的請求將不予處理。默認(rèn)值10。minSpareThreads：Tomcat初始化時創(chuàng)建的線程數(shù)。默認(rèn)值25。maxSpareThreads：一旦創(chuàng)建的線程超過這個值，Tomcat就會關(guān)閉不再須要的socket線程。默認(rèn)值75。網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)enableLookups：是否反查域名，默認(rèn)值為true。為了提高處理實(shí)力，應(yīng)設(shè)置為falseconnnectionTimeout：網(wǎng)絡(luò)連接超時，默認(rèn)值60000，單位：毫秒。設(shè)置為0表示永不超時，這樣設(shè)置有隱患的。通?？稍O(shè)置為30000毫秒。maxKeepAliveRequests：保持請求數(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ù)。webserver允許的最大連接數(shù)還受制于*作系統(tǒng)的內(nèi)核參數(shù)設(shè)置，通常Windows是2000個左右，Linux是1000個左右。apache服務(wù)器優(yōu)化加大并發(fā)數(shù)量和關(guān)閉不須要的模塊。因?yàn)閍pache特殊消耗內(nèi)存，盡量輕量化。Apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率同時配置apache和tomcat的組合使之能作到動靜分別，apache處理靜態(tài)頁面，tomcat處理動態(tài)頁面。在處理靜態(tài)頁面或者圖片、js等訪問方面，可以考慮運(yùn)用ligd代替Apache，它供應(yīng)了更輕量級和更高效的處理實(shí)力Nginx服務(wù)器的優(yōu)化worker_processes：該參數(shù)的值最好跟cpu核數(shù)相等，能夠發(fā)揮最大性能，假如nginx所在服務(wù)器為2顆雙核cpu，則建議設(shè)定為4。3Web服務(wù)架構(gòu)評測主要對基于tomcat和nginx+tomcat的web服務(wù)器的處理性能進(jìn)行測試，以作為不同性能要求下架構(gòu)選型的依據(jù)測試環(huán)境網(wǎng)絡(luò)環(huán)境1.內(nèi)網(wǎng)帶寬?千M內(nèi)網(wǎng)。?內(nèi)網(wǎng)ping包延遲：網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)2.網(wǎng)絡(luò)拓?fù)涫疽釽EB服務(wù)高可用測試網(wǎng)絡(luò)示意圖千兆交換機(jī)測試服務(wù)器WEB服務(wù):服務(wù)端服務(wù)器配置設(shè)備Nginx硬件配置IBMX3650CPU:Intel(R)Xeon(R)E51502核*2內(nèi)存：4G千兆網(wǎng)卡操作系統(tǒng)Redhatlinuxas4Tomcat1HpDL580G4CPU:Intel(R)Xeon(TM)4核*2內(nèi)存：8G千兆網(wǎng)卡Redhatlinuxas5Tomcat2HpDL580G4CPU:Intel(R)Xeon(TM)4核*2內(nèi)存：8G千兆網(wǎng)卡Redhatlinuxas5Test1HpDL580G5CPU:Intel(R)Xeon(R)E73104核*2內(nèi)存：4G千兆網(wǎng)卡IBMX3650CPU:Intel(R)Xeon(R)E51502核*2內(nèi)存：4G千兆網(wǎng)卡Redhatlinuxas5Test2Redhatlinuxas4網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)軟件環(huán)境1.操作系統(tǒng)網(wǎng)絡(luò)參數(shù)優(yōu)化用做測試的各臺服務(wù)器，均在/etc/配置文件中增加如下內(nèi)核參數(shù)：_syncookies=1_tw_reuse=1_tw_recycle=1_fin_timeout=52.Nginx設(shè)置主要配置如下：userwwwwww;worker_processes4;error_log/usr/local/nginx/logs/nginx_pid/usr/local/nginx/logs/;worker_rlimit_nofile51200;events{useepoll;worker_connections51200;}{include;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__version;網(wǎng)站架構(gòu)debug;門戶網(wǎng)站架構(gòu)#gzip_comp_level2;#gzip_typestext/plainapplication/x-javascripttext/cssapplication/xml;#gzip_varyon;upstreamtomcats{server:8081;server:8081;#server:8080;}server{listen81;server_namelocalhost;proxy_redirectoff;location/{proxy_passtomcats;}#后端的Web服務(wù)器可以通過X-Forwarded-For獲得用戶真實(shí)IP#proxy_set_headerX-Forwarded-For$remote_addr;#location/{#if($request_uri~*\#{#proxy_pass;#}#if($request_uri~*\#{#proxy_pass;#}#proxy_pass;#}#定義日志格式log_formataccess‘$remote_addr-$remote_user[$time_local]$request‘‘\’\#打日志網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)access_log/usr/local/nginx/logs/access;#允許客戶端請求的最大的單個文件字節(jié)數(shù)client_max_body_size10m;#緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù)可以理解為先保存到本地再傳給用戶client_body_buffer_size128k;#跟后端服務(wù)器連接的超時時間_發(fā)起握手等候響應(yīng)超時時間proxy_connect_timeout600;#連接成功后_等候后端服務(wù)器響應(yīng)時間_其實(shí)已經(jīng)進(jìn)入后端的排隊之中等候處理proxy_read_timeout600;#后端服務(wù)器數(shù)據(jù)回傳時間_就是在規(guī)定時間之內(nèi)后端服務(wù)器必需傳完全部的數(shù)據(jù)proxy_send_timeout600;#代理請求緩存區(qū)_這個緩存區(qū)間會保存用戶的頭信息以供Nginx進(jìn)行規(guī)則處理_一般只要能保存下頭信息即可proxy_buffer_size8k;#同上告知Nginx保存單個用的幾個Buffer最大用多大空間proxy_buffers432k;#假如系統(tǒng)很忙的時候可以申請更大的proxy_buffers官方舉薦*2proxy_busy_buffers_size64k;#proxy緩存臨時文件的大小proxy_temp_file_write_size64k;}}3.Tomcat設(shè)置主要配置如下：??MaxThread500?MinSpareThread25?MaxSpareThread75網(wǎng)站架構(gòu)門戶網(wǎng)站架構(gòu)?Xmx1740M4.Java環(huán)境?運(yùn)用_03啟動兩個Tomcat。運(yùn)用啟動兩個客戶端的Tes測試t進(jìn)程。網(wǎng)站架構(gòu)

門戶網(wǎng)站架構(gòu)測試結(jié)果單個TOMCAT的WEB服務(wù)器N客戶O數(shù)線程數(shù)500請求間隔測試服次數(shù)時間務(wù)器200萬200萬0毫秒25毫秒占用服務(wù)器內(nèi)存負(fù)載>150持續(xù)平均速時間度1298682秒條/秒288秒293秒422秒413秒742秒744秒1595秒1575秒6362秒6351秒4765條/秒4123條/秒2863條/秒2922條/秒1727條/秒1608條/秒742條/秒737條/秒471條/秒472條/秒完成請求106萬137萬120萬120萬120萬128萬119萬118萬116萬300萬300萬結(jié)果說明11Test1Test1從第82秒起先，tomcat占用內(nèi)存，但CPU資源被tomcat耗盡，服務(wù)器負(fù)載急劇上升，top顯示已達(dá)150，服務(wù)器停止響應(yīng)客戶端請求，客戶端請求速度急劇下降，錯包率100%，測試被迫中斷。從第280秒左右起先，tomcat占用內(nèi)存到達(dá)Xmx指定上限，Test1、Test2請求速度急劇下降，出現(xiàn)錯包，錯包率超過>6%，且仍在增加，測試終止。tomcat拋出“:GCoverheadlimitexceeded“異樣。服務(wù)端從第400秒左右起先，tomcat占用內(nèi)存到達(dá)Xmx指定上限，Test1、Test2請求速度急劇下降，起先出現(xiàn)大量錯包，422秒以后的錯包率超過%，且仍在在增加中，之前的錯包率約為%，測試終止。服務(wù)端從第740秒左右起先，tomcat占用內(nèi)存到達(dá)Xmx指定上限，Test1、Test2請求速度急劇下降，起先出現(xiàn)大量錯包，測試終止，達(dá)到前，錯包率只有%，達(dá)到后，截止停止測試時，錯包率增長到%，且仍在在增加中。web服務(wù)器負(fù)載小于2。服務(wù)端從第1595秒左右起先，tomcat占用內(nèi)存到達(dá)Xmx指定上限，Test1、Test2請求速度急劇下降，起先出現(xiàn)大量錯包，達(dá)到前，錯包率只有%，達(dá)到后，截止停止測試時，錯包率增長到%，測試終止。在測試進(jìn)度到80%左右時，tomcat1占用內(nèi)存達(dá)到了Xmx指定上限，但Test1、Test2請求速度并未下降，直到600萬次請求全部完成，兩個客戶端分別有9個丟包，丟包率只有%，最長的響應(yīng)時長為秒。22500Test2Test1門戶網(wǎng)站架構(gòu)Nginx+2個TOMCAT的WEB服務(wù)器NO客戶線程端數(shù)數(shù)2250請求間隔測試服次數(shù)時間務(wù)器150萬0毫秒Test1Test1Tomcat占用內(nèi)存1G門戶網(wǎng)站架構(gòu)Nginx+2個TOMCAT的WEB服務(wù)器+緩沖NO客戶線程端數(shù)數(shù)2250請求間隔次數(shù)時間150萬200萬0毫秒25毫秒測試服務(wù)器Test1Test2Test1Test2Test1Test2Test1Test2Test1Test2Test1Test2Tomcat占用內(nèi)存公開內(nèi)部公開√機(jī)密測試結(jié)果分析1.系統(tǒng)參數(shù)的影響分析1）worker_processes參數(shù)對Nginx性能的影響測試過程中分別設(shè)定worker_processes為8、4、2、1時發(fā)覺，該參數(shù)對nginx性能影響不大，對服務(wù)器資源消耗也沒有太大影響，相關(guān)資料顯示，該參數(shù)的值最好跟cpu核數(shù)相等，能夠發(fā)揮最大性能，本次測試nginx所在服務(wù)器為2顆雙核cpu，因此最終測試設(shè)定為4。2）MaxThread參數(shù)對tomcat并發(fā)性的影響本次測試tomcat的MaxThread參數(shù)設(shè)定為500，進(jìn)行13000條/秒并發(fā)測試時，tomcat啟動并發(fā)線程過多，將服務(wù)器cpu耗盡。分析MaxThread雖能夠提高tomcat并發(fā)實(shí)力，但前提是在一個合理的范圍內(nèi)，要確保服務(wù)器負(fù)載不會因?yàn)椴l(fā)線程過多而急劇上升，從而停止響應(yīng)。3）-Xmx最大內(nèi)存值對Tomcat能夠持續(xù)響應(yīng)高并發(fā)的影響持續(xù)高并發(fā)請求狀態(tài)下，有6次測試是因?yàn)閠omcat內(nèi)存達(dá)到指定最大值導(dǎo)致響應(yīng)變慢，直至內(nèi)存溢出停止響應(yīng)，因此，Tomcat最大內(nèi)存對tomcat能夠持續(xù)響應(yīng)高并發(fā)請求有很大的影響，調(diào)整該值，應(yīng)當(dāng)可以增加Tomcat響應(yīng)高并發(fā)請求的總數(shù)，進(jìn)而延長WEB服務(wù)能夠支撐峰值的時間。2.各架構(gòu)下的性能分析1)Nginx+2Tomcat的最大并發(fā)性低于單Tomcat，Nginx+2Tomcat最快為8980條/秒，單Tomcat為12986條/秒，分析可能是受nginx所在服務(wù)器性能影響所致。2)單tomcat在配置最大內(nèi)存時，在持續(xù)超過1479條/秒的并發(fā)請求下，在穩(wěn)定支撐約240萬次響應(yīng)后，Tomcat內(nèi)存達(dá)到上限，之后Tomcat響應(yīng)會急劇變慢，錯包急劇上升。3)Nginx+2tomcat架構(gòu)下，2個tomcat分別配置最大內(nèi)存時，在持續(xù)超過2900條/秒的并發(fā)請求下，能夠穩(wěn)定支撐約540萬次左右響應(yīng)，之后兩個Tomcat內(nèi)存都會達(dá)到上限，響應(yīng)會急劇變慢，但錯包狀況并未出現(xiàn)。4)在Nginx+2tomcat，同時配置了緩存的狀況下，可以達(dá)到萬以上的并發(fā)處理實(shí)力評測結(jié)果1)單個tomcat的處理實(shí)力在500條/秒左右單個tomcat能穩(wěn)定支持每秒500左右的并發(fā)請求。2)Nginx+Tomcat比單個Tomcat更穩(wěn)定，不易出現(xiàn)錯包，可以通過擴(kuò)充tomcat集群來提升系統(tǒng)的并發(fā)實(shí)力單個tomcat在超出并發(fā)實(shí)力的提求下，處理實(shí)力大大下降，并出現(xiàn)大量錯包，而接受Nginx+2Tomcat架構(gòu)在各種測試下，均未出現(xiàn)錯包，但處理實(shí)力也會下降。單個tomcat能穩(wěn)定支持每秒500左右的并發(fā)請求，而Nginx+2Tomcat能支持每秒1000左右4/12/2016版權(quán)全部，侵權(quán)必究Allrightsreserved第34頁,共39頁P(yáng)age34,Total39公開內(nèi)部公開√機(jī)密的并發(fā)請求。所以可以通過新加tomcat服務(wù)器來提升系統(tǒng)的并發(fā)實(shí)力，但在tomcat的總體處理實(shí)力超過nginx的處理實(shí)力時無效。3)Nginx+2Tomcat配置了緩存后，靜態(tài)頁面的并發(fā)實(shí)力不再受tomcat的限制，單個nginx的并發(fā)處理實(shí)力能達(dá)到萬以上。配置了緩存后，nginx+2tomcat的處理實(shí)力實(shí)測數(shù)據(jù)超過了萬次/秒，而單個tomcat可以支撐500次/秒，則從理論上計算一組Nginx+30個Tomcat集群可以支撐萬次/秒的并發(fā)處理。注：為tomcat均支配內(nèi)存。4配置選型網(wǎng)絡(luò)帶寬只考慮門戶訪問的帶寬占用，后臺管理頁面等其他業(yè)務(wù)訪問和門戶訪問相差2-3個數(shù)量級，這一部分網(wǎng)絡(luò)流量占用忽視。同時考慮網(wǎng)絡(luò)帶寬利用率依據(jù)業(yè)務(wù)設(shè)計實(shí)力，每秒網(wǎng)絡(luò)流量=WEB網(wǎng)站每秒鐘訪問流量=/帶寬利用率=(200K*8*n)/注：一般門戶的首頁大小>1M、平均200K/頁面，我們以平均值來計算。并發(fā)實(shí)力100次/秒200次/秒500次/秒1000次/秒占用的網(wǎng)絡(luò)帶寬228M457M1442M2286M架構(gòu)和硬件配置選型硬件配置參考序號1產(chǎn)品功能主機(jī)設(shè)備參考型號、配置TPMCIBMSystemx3850M2,4個處理器，每處理器為6核，共計數(shù)據(jù)庫服務(wù)器24核。內(nèi)存大小16G。SAS硬盤，硬盤大小587GB。4U機(jī)架，684508集成雙千兆以太網(wǎng)接口，兩塊千兆的光纖網(wǎng)卡。4/12/2016版權(quán)全部，侵權(quán)必究Allrightsreserved第35頁,共39頁P(yáng)age35,Total39

WEB服務(wù)器公開內(nèi)部公開√機(jī)密IBMSystemx3850M2,4個處理器，每處理器為6核，共計24核。內(nèi)存大于8G。SAS硬盤，硬盤大小587GB。4U機(jī)架，684508集成雙千兆以太網(wǎng)接口，兩塊千兆的光纖網(wǎng)卡。IBMSystemx3560，1個IntelXeonE5450處理器，內(nèi)存大小2G，2U機(jī)架。RADWARE應(yīng)用負(fù)載均衡設(shè)備,型號:為ODS-504,有，4個可選的千兆位電端口,1G主內(nèi)存,500M處理實(shí)力(最大可通過License升級為4G)CISCOASA5520防火墻并發(fā)連接：280000網(wǎng)絡(luò)吞吐：450平安過濾：225MB網(wǎng)絡(luò)端口：4個千兆以太網(wǎng)接口+1個快速用戶數(shù)限：無用戶數(shù)限制用戶VPN支持：支持QuidwayS3952P-EI傳輸速率：10Mbps/100Mbps/1000Mbps網(wǎng)絡(luò)標(biāo)準(zhǔn)：IEEE、IEEE端口數(shù)量：48接口介質(zhì)：10/100Base-T、1000Base-X傳輸模式：全雙工/半雙工自適應(yīng)背板帶寬：32Gbps光纖存儲柜光纖交換機(jī)326002管理終端網(wǎng)絡(luò)設(shè)備負(fù)載均衡器防火墻交換機(jī)3存儲設(shè)備光纖存儲柜光纖交換機(jī)注：上表為硬件的參考配置，依據(jù)網(wǎng)站規(guī)模的不同，在初期可以不用硬件負(fù)載均衡器。服務(wù)器性能