隨著用戶訪問量的不斷增加，網(wǎng)站的后臺也會不斷變化以應對需求。本文主要從一個小型網(wǎng)站到大型網(wǎng)站服務器架構的過度與變化來陳述。

1.1 網(wǎng)站后臺架構

主要指由web server 、應用服務器、數(shù)據(jù)庫、存儲、監(jiān)控等組成的網(wǎng)站后臺系統(tǒng)。

1.2 架構演變

個人站點后臺架構。如圖2-1所示。

圖2-1 單臺一組

如圖所示，如果是個人站點，訪問量不大，一般都是將web server、應用服務器、數(shù)據(jù)庫部署在一臺物理服務器上。從圖中也可以看到，一個網(wǎng)站最基本的后臺需要web server、應用服務器、數(shù)據(jù)庫三部分組成。

1.2.1 網(wǎng)站架構的進一步演變

考慮到網(wǎng)站訪問量的不斷增加，網(wǎng)站的后臺架構也必須不斷調(diào)整和優(yōu)化，進一步實現(xiàn)功能分離。www.linuxidc.com特別是隨著訪問量不斷增加以及考慮到數(shù)據(jù)庫的負載和數(shù)據(jù)的重要性，數(shù)據(jù)庫需要分離出來。從web server到數(shù)據(jù)庫實現(xiàn)各個層次的負載均衡。

1.2.1.1 數(shù)據(jù)庫功能分離，數(shù)據(jù)庫單臺部署

考慮到數(shù)據(jù)庫的安全性和處理性能，數(shù)據(jù)庫單臺部署。如圖2-2-1-1所示。

圖2-2-1-1 數(shù)據(jù)庫分離

如圖所示，數(shù)據(jù)庫與web server 、應用服務器分離出來，單臺部署。這樣做有兩個好處：

(1)數(shù)據(jù)庫服務器性能提高，不再和webserver 、應用服務器搶占資源。

(2)數(shù)據(jù)庫服務器安全性能提高，不會因為一臺服務器宕機而影響所有服務，特別是數(shù)據(jù)庫服務。

1.2.1.2 前端負載均衡部署，用于緩解單臺web server壓力

隨著訪問量的不斷增加，單臺web server 負載會加大，甚至有宕機的危險，所以需要在前端增加負載均衡器，實現(xiàn)web server層的負載均衡。緩解壓力。如圖2-2-1-2所示。

圖2-2-1-2 前端負載均衡

如圖所示，通過增加web server并用負載均衡器(load balance)來緩解前端的web server和應用服務器壓力。并且，為了保證數(shù)據(jù)庫的絕對安全，做了Master-Slave主從備份。這樣當master db宕機之后，slavedb可以立即啟用。所以這樣做有以下好處：

(1)前臺web server 和 應用服務器壓力減少，負載均衡器分流負載。

(2)后端數(shù)據(jù)庫安全性加強，出現(xiàn)故障后，業(yè)務可以很快切換到slave db 上。

1.2.1.3 增加緩存及數(shù)據(jù)庫讀寫分離

隨著訪問量的不斷增加，發(fā)現(xiàn)整個系統(tǒng)的讀寫比例很大，對用戶而言，讀操作多于寫操作，而且比例很大，這就需要進一步改善架構，實現(xiàn)讀寫分離。

通過增加db proxy，實現(xiàn)讀寫分離。如圖所示，2-2-1-3。

圖2-2-1-3

考慮到讀寫比例大的特點，如圖2-2-1-3所示，通過增加db proxy，以及master-slaves ，實現(xiàn)讀寫分離，所有寫操作在master db上進行，所有讀操作在其他slave dbs 上進行，這樣做有以下好處：

(1)緩解單臺db的壓力，減少單臺db的負載

(2)增加多個slave，當master db宕機之后，可以很快切換到slave 上，減少所有db同時宕機的風險。

很多用戶訪問，讀與寫操作比例很大，如圖2-2-1-3所示，通過在web server層上增加緩存，可以提高訪問速度。比如可以緩存css、jpg等靜態(tài)文件。

增加緩存有兩個好處：

(1)加快用戶的讀請求訪問速度。

(2)緩解web server的壓力。

1.2.1.4 解決單點故障問題，增加在線備份設備(交換設備和服務器)

雖然上述幾個架構圖，從各個層面緩解了服務器壓力，但是，還是存在當點故障的可能性。如果出現(xiàn)單點故障，沒有在線物理設備提供使用，那該系統(tǒng)也不是一個高可用的系統(tǒng)。針對上述問題，增加在線物理備份設備，解決單點故障問題，如圖2-2-1-4所示。

圖 2-2-1-4

如圖2-2-1-4所示，增加了負載均衡器的在線備用設備和db proxy在線備用服務器，這樣做可以在負載均衡器出現(xiàn)故障的時候，啟用在線備用設備;如果db proxy出現(xiàn)故障，也可以啟用在線備用db proxy，實現(xiàn)故障轉(zhuǎn)移。保證系統(tǒng)的高可用性。

1.1 高可用性

“高可用性”(High Availability) 通常用來描述一個系統(tǒng)，經(jīng)過特殊設計，減少停止服務的時間，從而使其服務保持高度的可使用性。

計算機系統(tǒng)的可靠性用平均無故障時間(MTTF)來度量，即計算機系統(tǒng)平均能夠正常運行多長時間，才會發(fā)生一次故障。系統(tǒng)的可靠性能越高，平均無故障時間越長?？删S護性用平均維修時間(MTTR)來度量，即系統(tǒng)發(fā)生故障后維修和重新恢復正常運行平均花費時間。系統(tǒng)的可維護性越好，平均維修時間越短。計算機系統(tǒng)的可用性定義為：MTTF/(MTTF+MTTR)*100%。

舉例來說，淘寶網(wǎng)在2010年成交額為300億，則每分鐘成交額為5—10萬，那么對淘寶來說，其后臺系統(tǒng)的高可用，對企業(yè)運營非常重要。淘寶數(shù)據(jù)負責人寧海元指出，淘寶系統(tǒng)，可用性至少需要99.999%。那么對于taobao.com系統(tǒng)，在一年365天，系統(tǒng)停止服務時間為5分15秒。

1.2 確保高可用性

高可用性的衡量指標

%availability=(TotalElapsed Time – Sum of Inoperative Times) / Total Elapsed Time

其中：

TotalElapsed Time 為系統(tǒng)總時間，包括可提供服務時間+停止服務時間。

Sumof Inoperative Times 為停止服務時間，包括宕機時間+維護時間。

1.2.1 如何確保高可用

可用性越高越好，提高可用性主要從一下幾個方面入手：

(1)系統(tǒng)架構

(2)容災性

(3)監(jiān)控報警

(4)故障轉(zhuǎn)移

1.2.1.1 系統(tǒng)架構

系統(tǒng)架構，指整個網(wǎng)站后臺系統(tǒng)的架構。好的系統(tǒng)架構，主要從下面幾個方面考慮：

(1)操作系統(tǒng)的選擇，從穩(wěn)定性、安全性和可維護性考慮，unix和linux性能遠遠好于windows，從成本考慮，Linux遠遠低于windows 和unix。

(2)負載均衡器的選擇，硬件負載均衡器性能和穩(wěn)定性高于軟件負載均衡器。但成本上，軟件比如haproxy、LVS優(yōu)于硬件(比如F5、Netscaler)。

(3)web server的選擇，Nginx優(yōu)于傳統(tǒng)的Apache。

(4)各級緩存的選擇與應用，varnish、squid、memcached。

(5)網(wǎng)站開發(fā)語言的選擇，與開發(fā)有關，www.linuxidc.com主要分為需要編譯性的語言和不需要編譯性的語言。

(6)數(shù)據(jù)庫的選擇，傳統(tǒng)的關系數(shù)據(jù)庫中，Oracle優(yōu)于MySQL，但Oracle收費遠遠高于MySQL，實際上，Oracle有兩種收費模式，一種是按用戶數(shù)，一種是按主機處理器個數(shù)。而MySQL有免費的版本。

(7)底層存儲設備的選擇，比如機械磁盤和固態(tài)硬盤的選擇。

(8)避免單點故障問題，在邏輯架構上，避免單點故障，避免出現(xiàn)割點。

1.2.1.2 容災性

容災性能對系統(tǒng)非常重要，比如服務器因為斷電，導致數(shù)據(jù)文件的不一致，因為發(fā)生自然或者非自然災害比如火災導致的磁盤損壞，發(fā)生數(shù)據(jù)丟失等。所以容災很重要，主要從以下幾個方面提高容災性能：

(1)服務器熱備機的部署，當發(fā)生故障后，熱備機能馬上使用，提供服務。這里的服務器主要指web server 、應用服務器、數(shù)據(jù)庫服務器等。

(2) 數(shù)據(jù)備份，比如做定期備份、熱備份、增量備份，甚至需要做主從備份，來提高抗災性能。并且從底層存儲設備上進行備份，比如做RAID。

(3) 做雙線網(wǎng)絡交換，盡量優(yōu)化設計網(wǎng)絡，避免因為核心交換機故障，而影響服務。網(wǎng)絡上避免單點故障。

1.2.1.3 監(jiān)控報警

監(jiān)控是指對在線服務和非服務的在線服務器和相應的進程進行狀態(tài)檢測，當出現(xiàn)宕機或者某項服務進程僵死之后，能夠在盡量短的時間獲得該信息，然后通過報警系統(tǒng)將信息發(fā)送到一線運維人員。所以，監(jiān)控報警，直接影響宕機時間。監(jiān)控報警，主要從以下幾個方面展開：

(1)監(jiān)控主機CPU使用情況，負載情況。

(2)監(jiān)控主機內(nèi)存使用情況。

(3)監(jiān)控主機IO外設，主要以磁盤為主。如磁盤的讀寫、磁盤使用量等。

(4)監(jiān)控主機網(wǎng)卡使用情況。網(wǎng)卡是否損壞，是否招到DDOS攻擊。

(5)監(jiān)控應用進程，包括web server ，應用服務器等。

(6)監(jiān)控數(shù)據(jù)庫使用情況。包括用戶的請求數(shù)、緩存使用量等。

(7)監(jiān)控交換設備的使用情況。網(wǎng)絡入、出的流量。

(8)監(jiān)控IDC機房溫度、濕度等。

(9)防火墻、入侵檢測等安全檢測、監(jiān)控等。

通過上面的各項監(jiān)控、得到相應數(shù)值，應用監(jiān)控繪圖軟件，把相應的數(shù)值繪畫出來，現(xiàn)有監(jiān)控繪圖軟件有mrtg、cacti、nagios等。然后設置一個報警閾值，如果超過該閾值，那么通過報警系統(tǒng)，www.linuxidc.com比如短信、msn、郵件、甚至是聲音完成報警功能。典型的報警系統(tǒng)如圖3-2-1-3所示。

圖3-2-1-3

如圖3-2-1-3所示，監(jiān)控服務器從servers上收集系統(tǒng)信息，如果發(fā)現(xiàn)系統(tǒng)的某項狀態(tài)指數(shù)超過預設的閾值，則發(fā)送郵件到運維人員。同時，把相應的報警信息發(fā)送到短信運營商的短信網(wǎng)關服務器，然后短信網(wǎng)關服務器發(fā)送短信到運維人員手機中，完成短信報警。上述報警過程，傳送郵件報警信息，是基于TCP/IP協(xié)議，而傳送短信報警信息，是基于gprs網(wǎng)絡。

1.2.1.4 故障轉(zhuǎn)移

故障轉(zhuǎn)移是指，當對用戶提供服務的服務器或者相應的應用進程發(fā)生故障后，比如服務器宕機、進程僵死之后，備用服務器能夠在盡量短的時間內(nèi)啟用，提供服務。這樣能夠大限度減少損失，保證用戶的正常服務。所以，做好故障轉(zhuǎn)移，要解決以下兩個問題：

(1)實時監(jiān)測故障問題。

(2)準確快速切換服務器問題。

針對不同層次的服務，監(jiān)測機制也不同，詳細情況，在3.2.1.3已經(jīng)闡述。下面主要論述一下故障切換問題。

故障切換包括負載均衡器的故障切換、主機os的故障切換、web server的故障切換、應用進程的故障切換、數(shù)據(jù)庫的故障切換、存儲系統(tǒng)的故障切換、DNS的故障切換、交換設備的故障切換等。下面主要分析進程僵死的故障轉(zhuǎn)移和服務器宕機的故障轉(zhuǎn)移。

進程僵死故障轉(zhuǎn)移案例，常見的web server僵死故障轉(zhuǎn)移如圖3-2-1-4所示。

圖3-2-1-4-1

如圖3-2-1-4-1所示，當主機172.29.141.112的web server 對外提供服務時，通過在主機172.29.141.113上部署監(jiān)控程序Monitor_nginx.sh來監(jiān)控主機172.29.141.112上面的web server進程運行情況，一旦發(fā)現(xiàn)172.29.141.112上web server停止服務，馬上報警，先更改172.29.141.113的ip地址為172.29.141.112，再啟用其自身的web server,完成故障轉(zhuǎn)移。此外，也可以在兩服務器上同時部署監(jiān)控程序Monitor_nginx.sh，完成互相監(jiān)控。

服務器宕機故障轉(zhuǎn)移案例，常見的服務器宕機故障轉(zhuǎn)移，如圖3-2-1-4-2所示。

圖3-2-1-4-2

如圖3-2-1-4-2所示，服務器A和服務器B同時部署，但服務器A提供服務，而服務器B作為熱備機。監(jiān)控系統(tǒng)單獨部署。當服務器A宕機之后，監(jiān)控系統(tǒng)會檢測到這一信息，然后通過浮動更改服務器B的ip地址，完成故障切換。

1.3 本文小結(jié)

本文主要闡述了網(wǎng)站后臺系統(tǒng)的高可用性，分析了高可用性的定義和應用需求，重點闡述了如何做到高可用。通過從不同應用級別，如主機、存儲、網(wǎng)絡、外設、數(shù)據(jù)庫、安全等各個級別進行分析，最后詳細論述了web server的故障轉(zhuǎn)移和主機系統(tǒng)的故障轉(zhuǎn)移。

整理大型網(wǎng)站架構必知必會的幾個服務器知識

最近看書及系統(tǒng)開發(fā)部署過程中的一些心得，再對照自己之前的從業(yè)經(jīng)驗，很多都是聽聞而已，當然也有一些已經(jīng)很熟悉，有的正在搞，有的未來希望可以著手付諸實施，留此存照。

1、負載均衡服務器

負載均衡服務器主要作用是實現(xiàn)某些類型服務器的規(guī)模擴展。比如對于系統(tǒng)前端的web服務器和后端的數(shù)據(jù)庫服務器，想通過加服務器實現(xiàn)N+1橫向擴展，通過多臺服務器負載分擔壓力，負載均衡必不可少。

2、web服務器

最常見，內(nèi)存要求不是很高但cpu要求較高，主要用于部署各種web應用，如帶界面的web頁面、不帶界面的web服務、wcf等等。

3、緩存服務器

大中型網(wǎng)站，分布式緩存已是標配，緩存服務器專門用于部署分布式緩存，一般而言對內(nèi)存和帶寬要求較高。

4、消息隊列服務器

隊列是系統(tǒng)解耦利器，也是大中型分布式系統(tǒng)標配，沒有隊列，業(yè)務系統(tǒng)很容易高度耦合，系統(tǒng)吞吐量也會很快遭遇瓶頸。

5、文件服務器

分布式文件系統(tǒng)，專門用于存儲業(yè)務系統(tǒng)需要的各種文件如圖片、多媒體文件等。

6、索引服務器

用于網(wǎng)站全文索引，搜索必備。對內(nèi)存和CPU要求較高，大型網(wǎng)站，通常還需要支持主從備份和容錯，甚至多實例索引集群。

7、搜索服務器

通常需要部署多臺，否則查詢多了性能撐不住，對內(nèi)存要求不高。有的中小型站點，索引和搜索服務器在物理和邏輯上都是同一臺服務器。

8、作業(yè)服務器

主要用于后端應用程序大批量大數(shù)據(jù)量復雜業(yè)務邏輯的定時作業(yè)，大多數(shù)互聯(lián)網(wǎng)公司標配，某些企業(yè)的定時調(diào)度框架是直接部署在web服務器上的，可以減少這里的所謂作業(yè)服務器。

9、數(shù)據(jù)庫服務器

主要用于存儲和查詢數(shù)據(jù)。數(shù)據(jù)庫已是各種系統(tǒng)實際上的標配，內(nèi)存和CPU都要求極高，網(wǎng)絡和硬件要求也不低。大中型網(wǎng)站還需要支持數(shù)據(jù)庫的主從備份和容錯，甚至多實例的數(shù)據(jù)庫集群。

通常，大中型的互聯(lián)網(wǎng)應用會經(jīng)歷一個從單一的數(shù)據(jù)庫服務器,到Master/Slave主從服務器,再到垂直分區(qū)(分庫)，然后再到水平分區(qū)(分表，sharding)的過程。而在這個過程中，Master/Slave以及分庫相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分區(qū)join查詢數(shù)據(jù)，如何實現(xiàn)DB負載等等，這個時候就需要一個通用的DAL框架來屏蔽底層數(shù)據(jù)存儲對業(yè)務邏輯的影響，使得底層數(shù)據(jù)的訪問對應用完全透明化。

10、nosql服務器

海量數(shù)據(jù)處理的興起，各種nosql產(chǎn)品層出不窮，nosql服務器主要用于處理海量數(shù)據(jù)，支持存儲、查詢、分片等。

web應用中，有兩個一直是不好實現(xiàn)橫向擴展或者由于歷史遺留問題實現(xiàn)代價非常大的東西，如你所知，就是：A、數(shù)據(jù)庫 B、網(wǎng)絡帶寬。

而某些nosql的出現(xiàn)很可能解決這個歷史遺留難題，現(xiàn)在已經(jīng)有nosql產(chǎn)品彌補了關系型數(shù)據(jù)庫天生不支持橫向擴展的缺點，在特定場景下正在替代關系型數(shù)據(jù)庫。

11、其他

需求不斷變化和應用需要，某些互聯(lián)網(wǎng)企業(yè)還可能衍生出基于安全的授權/證書服務器，全局唯一的流水號服務器，會話服務器等等。

參考：

<<大型網(wǎng)站技術架構>>

<<構建高性能web站點>>

http://www.cnblogs.com/terryli/archive/2008/04/06/1139121.html

http://www.cnblogs.com/ejiyuan/archive/2010/10/29/1796292.html

http://kb.cnblogs.com/page/99549/

http://highscalability.com/blog/2014/7/21/stackoverflow-update-560m-pageviews-a-month-25-servers-and-i.html

http://www.infoq.com/articles/perera-data-storage-haystack

http://lethain.com/introduction-to-architecting-systems-for-scale/

原文地址:https://blog.csdn.net/u010098331/article/details/52243121

當前文章：大型網(wǎng)站服務器架構淺析
轉(zhuǎn)載來于：http://www.rwnh.cn/news/204867.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)站制作、用戶體驗、ChatGPT、手機網(wǎng)站建設、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)