集團(tuán)公司門戶網(wǎng)站架構(gòu)設(shè)計方案

1、集團(tuán)公司門戶網(wǎng)站架構(gòu)設(shè)計方案集團(tuán)公司門戶網(wǎng)站架構(gòu)設(shè)計方案目錄1網(wǎng)站的性能瓶頸分析(1)2系統(tǒng)架構(gòu)設(shè)計(2)2.1總體思路(2)2.1.1負(fù)載均衡(2)2.1.2WEB應(yīng)用開發(fā)架構(gòu)思路(2)2.1.3數(shù)據(jù)存儲的設(shè)計思路(2)2.1.4不同網(wǎng)絡(luò)用戶訪問考慮(3)2.2總體架構(gòu)(4)2.2.1網(wǎng)站的系統(tǒng)分層架構(gòu)(4)2.2.2網(wǎng)站的物理架構(gòu)(5)2.2.3網(wǎng)站的開發(fā)架構(gòu)(6)2.2.4網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)(7)2.3架構(gòu)涉及技術(shù)的詳解(8)2.3.1負(fù)載均衡(8)2.3.2緩存(14)2.3.3頁面靜態(tài)化(18)2.3.4數(shù)據(jù)庫配置及優(yōu)化(19)2.3.5文件存儲(20)2.3.6網(wǎng)絡(luò)問題解決方案(23)2

2、.3.7WEB應(yīng)用開發(fā)架構(gòu)設(shè)計思路(25)2.4系統(tǒng)軟件參數(shù)優(yōu)化(29)2.4.1操作系統(tǒng)優(yōu)化(29)2.4.2tomcat服務(wù)器優(yōu)化(30)2.4.3apache服務(wù)器優(yōu)化(32)2.4.4Nginx服務(wù)器的優(yōu)化(32)3WEB服務(wù)架構(gòu)評測(33)3.1測試環(huán)境(33)3.1.1網(wǎng)絡(luò)環(huán)境(33)3.1.2服務(wù)器配置(34)3.1.3軟件環(huán)境(34)3.2測試結(jié)果(39)3.2.1單個TOMCAT的WEB服務(wù)器(39)3.2.2Nginx+2個TOMCAT的WEB服務(wù)器(40)3.2.3Nginx+2個TOMCAT的WEB服務(wù)器+緩沖(41)3.3測試結(jié)果分析(42)3.4評測結(jié)果(43)4配

3、置選型(44)4.1網(wǎng)絡(luò)帶寬(44)4.2架構(gòu)和硬件配置選型(45)4.2.1硬件配置參考(45)422Web架構(gòu)和硬件選型(45)4.3硬件擴(kuò)容策略(46)4.3.1增加服務(wù)器(47)4.3.2增加存儲(47)4.3.3升級服務(wù)器(47)4.3.4網(wǎng)絡(luò)擴(kuò)容(47)5附錄：一些主流網(wǎng)站的真實數(shù)據(jù)(48)1、網(wǎng)站的性能瓶頸分析網(wǎng)站的性能影響因素很多，下面主要從如下4個方面進(jìn)行分析說明:網(wǎng)絡(luò)負(fù)載公網(wǎng)負(fù)載內(nèi)網(wǎng)負(fù)載WEB應(yīng)用服務(wù)器性能CPU存儲，I/O訪問內(nèi)存并發(fā)TCP/IP連接數(shù)數(shù)據(jù)庫服務(wù)器性能數(shù)據(jù)庫參數(shù)配置服務(wù)器性能(CPU、內(nèi)存、存儲)數(shù)據(jù)結(jié)構(gòu)的合理性不同WEB應(yīng)用的處理方式而對不同的性能瓶頸a

4、)對于靜態(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)頁面因為服務(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)

5、設(shè)計2.1、總體思路為提高網(wǎng)站的高并發(fā)性能，提高開發(fā)效率及運(yùn)營效率，主要按如下幾個思路進(jìn)行規(guī)劃設(shè)計：2.1.1、負(fù)載均衡1）四層交換負(fù)載均衡：釆用負(fù)載均衡器來實現(xiàn)硬件級的四層交換負(fù)載均衡，或釆用LVS來實現(xiàn)軟件的四層交換負(fù)載均衡。2）通過第三方軟件來實現(xiàn)負(fù)載均衡,同時實現(xiàn)頁面請求的緩存。通過Nginx實現(xiàn)反向代理服務(wù)器集群，同時搭建squid集群以作為靜態(tài)頁面和圖片的緩存。3）通過web服務(wù)器的配置來實現(xiàn)負(fù)載均衡即通過apache或是Nginx將客戶請求均衡的分給tomcat1,tomcat2去處理。2.1.2、WEB應(yīng)用開發(fā)架構(gòu)思路1）應(yīng)用開發(fā)實現(xiàn)MVC架構(gòu)三層架構(gòu)進(jìn)行web應(yīng)用開發(fā)2）頁面

6、盡可能靜態(tài)化以減少動態(tài)數(shù)據(jù)訪問，如果是資訊類的網(wǎng)站可以考慮釆用第三方開源的CMS系統(tǒng)來生成靜態(tài)的內(nèi)容頁面。3）釆用Oscache實現(xiàn)頁面緩存，釆用Memcached實現(xiàn)數(shù)據(jù)緩存4）釆用獨(dú)立的圖片服務(wù)器集群來實現(xiàn)圖片資源的存儲及WEB請求2.1.3、數(shù)據(jù)存儲的設(shè)計思路1）數(shù)據(jù)庫拆分,把生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫分離，對生產(chǎn)數(shù)據(jù)庫釆用RAC實現(xiàn)數(shù)據(jù)庫的集群。2）釆用高效的網(wǎng)絡(luò)文件共享策略，釆用圖片服務(wù)器來實現(xiàn)頁面的圖片存儲。2.1.4、不同網(wǎng)絡(luò)用戶訪問考慮1）通過引入CDN來解決不同網(wǎng)絡(luò)服務(wù)商的接入速度問題，一般只能解決靜態(tài)頁面的訪問問題。2）在不同運(yùn)營商機(jī)房部署服務(wù)器，通過鏡像技術(shù)來實現(xiàn)不同網(wǎng)絡(luò)服務(wù)

7、商的接入速度問題。2.2、總體架構(gòu)221、網(wǎng)站的系統(tǒng)分層架構(gòu)ApacheTomatTomatWEB服務(wù)器MVCControl磁用架珂Model伽JVEB服務(wù):Apacliei-tomrat負(fù)載瀚：數(shù)推持典懇頁面緩存(ibatis)數(shù)據(jù)緩存(OSCachtJ(、1enitHched)豔FSHDFS雅據(jù)庫生產(chǎn)數(shù)據(jù)庫査詢數(shù)扳產(chǎn)用戶痢覽頁面弋理服務(wù)器眞群(Nginx)wdm器聚讎丸11據(jù)務(wù)鶴I服務(wù)器2持久層通訊層消息隆片服務(wù)券集譯中心業(yè)務(wù)層Xx*卜cSrSr弧務(wù)器i舉務(wù)影數(shù)據(jù)層發(fā)器發(fā)器WEBg務(wù)器2.2.4各拓?fù)浣Y(jié)構(gòu)備防火墻光纖交換機(jī)磁盤陣列柜磁盤陣列柜負(fù)載均衡器1負(fù)載均衡器2備注：釆用雙防火墻雙交換

8、機(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ù)及真實服務(wù)器的數(shù)量，交換機(jī)可以隨時增加。釆用硬件設(shè)備負(fù)載均衡器，實現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡使用硬件設(shè)備負(fù)載均衡器，將網(wǎng)絡(luò)流量均衡的分擔(dān)到WEB服務(wù)器集群各節(jié)點服務(wù)器，保障平臺服務(wù)器資源均衡的使用。釆用代理服務(wù)器，實現(xiàn)軟件級的網(wǎng)絡(luò)負(fù)載均衡。數(shù)據(jù)庫服務(wù)器分離成生產(chǎn)數(shù)據(jù)庫集群和查

9、詢數(shù)據(jù)庫集群，實現(xiàn)生產(chǎn)讀寫與后臺查詢統(tǒng)計進(jìn)行分離，同時生產(chǎn)數(shù)據(jù)庫釆用rac技術(shù)進(jìn)行2.3、架構(gòu)涉及技術(shù)的詳解2.3.1、負(fù)載均衡基于DNS的負(fù)載均衡-一個域名綁定多個IPDNS負(fù)載均衡技術(shù)是最早的負(fù)載均衡解決方案，它是通過DNS服務(wù)中的隨機(jī)名字解析來實現(xiàn)的，在DNS服務(wù)器中，可以為多個不同的地址配置同一個名字，而最終查詢這個名字的客戶機(jī)將在解析這個名字時得到其中的一個地址。因此，對于同一個名字，不同的客戶機(jī)會得到不同的地址，它們也就訪問不同地址上的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。這種技術(shù)的優(yōu)點是，實現(xiàn)簡單、實施容易、成本低、適用于大多數(shù)TCP/IP應(yīng)用；但是，其缺點也非常明顯，首先這種方

10、案不是真正意義上的負(fù)載均衡，DNS服務(wù)器將Http請求平均地分配到后臺的Web服務(wù)器上，而不考慮每個Web服務(wù)器當(dāng)前的負(fù)載情況；如果后臺的Web服務(wù)器的配置和處理能力不同，最慢的Web服務(wù)器將成為系統(tǒng)的瓶頸，處理能力強(qiáng)的服務(wù)器不能充分發(fā)揮作用；其次未考慮容錯，如果后臺的某臺Web服務(wù)器出現(xiàn)故障，DNS服務(wù)器仍然會把DNS請求分配到這臺故障服務(wù)器上，導(dǎo)致不能響應(yīng)客戶端。最后一點是致命的，有可能造成相當(dāng)一部分客戶不能享受Web服務(wù)，并且由于DNS緩存的原因，所造成的后果要持續(xù)相當(dāng)長一段時間(一般DNS的刷新周期約為24小時)。所以在國外最新的建設(shè)中心Web站點方案中，已經(jīng)很少釆用這種方案了。通過硬

11、件四層交換實現(xiàn)負(fù)載均衡在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比女Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當(dāng)初接近2000臺服務(wù)器使用了三四臺Alteon就搞定了通過軟件四層交換實現(xiàn)負(fù)載均衡軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是LinuxVirtualServer,他提供了基于心跳線heartbeat的實時災(zāi)難應(yīng)對解決方案，提高系統(tǒng)的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應(yīng)用需求，這對于分布式的系統(tǒng)來說必不可少。一個典型的使用負(fù)載均衡的策略就是，在軟件或者硬件四層交換的基礎(chǔ)上搭建jquid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被釆用，這樣的架構(gòu)低成本、高性能還有很強(qiáng)的擴(kuò)張性。通過反向代理服務(wù)器實現(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ù)