公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√前臺(tái)門戶網(wǎng)站架構(gòu)設(shè)計(jì)方案北京寬連十方數(shù)字技術(shù)有限公司2012-74/10/2013版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

前臺(tái)門戶網(wǎng)站架構(gòu)

設(shè)計(jì)方案

北京寬連十方數(shù)字技術(shù)有限公司

2012-7

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

目 錄

1

2

3 設(shè)計(jì)思路 ........................................................................................................................................................ 3 系統(tǒng)結(jié)構(gòu) ........................................................................................................................................................ 3 網(wǎng)絡(luò)規(guī)劃及性能計(jì)算 .................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.1 網(wǎng)絡(luò)架構(gòu) ................................................................................................................................................ 8

3.2 網(wǎng)絡(luò)架構(gòu)說(shuō)明 ...................................................................................................... 錯(cuò)誤！未定義書(shū)簽。

3.2.1 采用雙防火墻雙交換機(jī)做網(wǎng)絡(luò)冗余，保障平臺(tái)服務(wù) . ................................................................ 8

3.2.2 采用硬件設(shè)備負(fù)載均衡器，實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡 . ............................................................ 8

3.3 系統(tǒng)測(cè)算 .............................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.3.1 系統(tǒng)處理能力要求 ...................................................................................................................... 34

3.3.2 業(yè)務(wù)處理能力要求 ...................................................................................... 錯(cuò)誤！未定義書(shū)簽。

3.3.3 系統(tǒng)話務(wù)模型 .............................................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.4 配置核算 .............................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.4.1 數(shù)據(jù)庫(kù)服務(wù)器性能核算 .............................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.4.2 WEB 服務(wù)器集群性能核算 . ......................................................................... 錯(cuò)誤！未定義書(shū)簽。

3.4.3 WEB 服務(wù)器集群內(nèi)存性能核算 . ................................................................. 錯(cuò)誤！未定義書(shū)簽。

3.4.4 網(wǎng)絡(luò)帶寬 ...................................................................................................................................... 35 4 性能模擬測(cè)試及性能推算 .......................................................................................... 錯(cuò)誤！未定義書(shū)簽。

4.1 測(cè)試環(huán)境 .............................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

4.2 測(cè)試結(jié)果 .............................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

4.2.1 1個(gè)客戶端模擬不同線和并發(fā)請(qǐng)求結(jié)果 . .................................................... 錯(cuò)誤！未定義書(shū)簽。

4.2.2 10個(gè)客戶端請(qǐng)求 .......................................................................................... 錯(cuò)誤！未定義書(shū)簽。

4.3 結(jié)果分析 .............................................................................................................. 錯(cuò)誤！未定義書(shū)簽。

4.4 根據(jù)測(cè)試結(jié)果推算 .............................................................................................. 錯(cuò)誤！未定義書(shū)簽。

4.5 設(shè)備清單 .............................................................................................................................................. 35

4.5.1 硬件設(shè)備配置清單 ...................................................................................... 錯(cuò)誤！未定義書(shū)簽。

4.5.2 設(shè)備技術(shù)規(guī)格 .............................................................................................. 錯(cuò)誤！未定義書(shū)簽。

4.6 平臺(tái)擴(kuò)容的建議 .................................................................................................................................. 35

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

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) CPU

b) 存儲(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ù)娇蛻舳?。從服?wù)器運(yùn)行的那個(gè)時(shí)間片來(lái)看，這個(gè)傳輸過(guò)程僅僅占用了很小的CPU 資源。對(duì)于靜態(tài)HTML 的訪問(wèn)瓶頸為：網(wǎng)絡(luò)帶寬、磁盤I/O以及cache(高速緩沖存儲(chǔ)器) 。 b) 對(duì)于動(dòng)態(tài)頁(yè)面

因?yàn)榉?wù)器解析動(dòng)態(tài)頁(yè)面必須在其傳輸?shù)娇蛻舳饲熬屯ㄟ^(guò)服務(wù)器來(lái)進(jì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ù)載均衡。

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

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 將客戶請(qǐng)求均衡的分給tomcat1,tomcat2.... 去處理。

2.1.2 WEB 應(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)，如果是資訊類的網(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ù)和查詢數(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ò)用戶訪問(wèn)考慮

1) 通過(guò)引入CDN 來(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)題。

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

2.2 總體架構(gòu)

2.2.1 網(wǎng)站的系統(tǒng)分層架構(gòu)

4/10/2013 版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

2.2.2 網(wǎng)站的物理架構(gòu)

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

2.2.3 網(wǎng)站的開(kāi)發(fā)架構(gòu)

通訊層

消息中心

業(yè)務(wù)層持久層數(shù)據(jù)層

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

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ù)集群和查詢數(shù)據(jù)庫(kù)集群，實(shí)現(xiàn)生產(chǎn)讀寫與后臺(tái)查詢統(tǒng)計(jì)

進(jìn)行分離，同時(shí)生產(chǎn)數(shù)據(jù)庫(kù)采用rac 技術(shù)進(jìn)行

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

2.3 架構(gòu)涉及技術(shù)的詳解

2.3.1 負(fù)載均衡

1. 基于DNS 的負(fù)載均衡--一個(gè)域名綁定多個(gè)IP

DNS 負(fù)載均衡技術(shù)是最早的負(fù)載均衡解決方案，它是通過(guò)DNS 服務(wù)中的隨機(jī)名字解析來(lái)實(shí)現(xiàn)的，在DNS 服務(wù)器中，可以為多個(gè)不同的地址配置同一個(gè)名字，而最終查詢這個(gè)名字的客戶機(jī)將在解析這個(gè)名字時(shí)得到其中的一個(gè)地址。因此，對(duì)于同一個(gè)名字，不同的客戶機(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)客戶端。最后一點(diǎn)是致命的，有可能造成相當(dāng)一部分客戶不能享受Web 服務(wù)，并且由于DNS 緩存的原因，所造成的后果要持續(xù)相當(dāng)長(zhǎng)一段時(shí)間(一般DNS 的刷新周期約為24小時(shí)) 。所以在國(guó)外最新的建設(shè)中心Web 站點(diǎn)方案中，已經(jīng)很少采用這種方案了。

2. 通過(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 就搞定了

3. 通過(guò)軟件四層交換實(shí)現(xiàn)負(fù)載均衡

軟件四層交換我們可以使用Linux 上常用的LVS 來(lái)解決，LVS 就是Linux Virtual Server，他提供了基于心跳線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ò)張性。

4. 通過(guò)反向代理服務(wù)器實(shí)現(xiàn)負(fù)載均衡

反向代理服務(wù)器又稱為 WEB 加速服務(wù)器，它位于 WEB 服務(wù)器的前端，充當(dāng)WEB 服務(wù)器的內(nèi)容緩存器, 反向代理服務(wù)器是針對(duì) WEB 服務(wù)器設(shè)置的，后臺(tái) WEB 服務(wù)器對(duì)互聯(lián)網(wǎng)用戶是透明的，用戶只能看到反向代理服務(wù)器的地址，不清楚后臺(tái) WEB 服務(wù)器是如何組織架構(gòu)的。當(dāng)互聯(lián)網(wǎng)用戶請(qǐng)求 WEB 服務(wù)時(shí)，DNS 將請(qǐng)求的域名解析為反向代理服務(wù)器的 IP 地址，這樣 URL 請(qǐng)求將被發(fā)送到反向代理服務(wù)器，由反向代理服務(wù)器負(fù)責(zé)處理用戶的請(qǐng)求與應(yīng)答、與后臺(tái) WEB 服務(wù)器交互。利用

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第

公開(kāi) 內(nèi)部公開(kāi) 機(jī)密 絕密√

反向代理服務(wù)器減輕了后臺(tái) WEB 服務(wù)器的負(fù)載，提高了訪問(wèn)速度，同時(shí)避免了因用戶直接與 WEB 服務(wù)器通信帶來(lái)的安全隱患。

目前有許多反向代理軟件，比較有名的有 Nginx 和 Squid 。

Nginx 是由 Igor Sysoev 為俄羅斯訪問(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)上使用、最多功能也最完整的一套軟體。

1） Squid

Squid 是一個(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)如下圖：

客戶端請(qǐng)求訪問(wèn) WEB 服務(wù)時(shí)，DNS 將訪問(wèn)的域名解析為 Squid 反向代理服務(wù)器的 IP 地址，這樣客戶端的 URL 請(qǐng)求將被發(fā)送到反向代理服務(wù)器。如果 Squid 反向代理服務(wù)器中緩存了該請(qǐng)求

4/10/2013

版權(quán)所有，侵權(quán)必究All rights reserved 第