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

1.1 網站后臺架構

主要指由web server 、應用服務器、數據庫、存儲、監控等組成的網站后臺系統。

1.2 架構演變

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

圖2-1 單臺一組

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

1.2.1 網站架構的進一步演變

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

1.2.1.1 數據庫功能分離，數據庫單臺部署

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

圖2-2-1-1 數據庫分離

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

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

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

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

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

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

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

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

(2)后端數據庫安全性加強，出現故障后，業務可以很快切換到slave db 上。

1.2.1.3 增加緩存及數據庫讀寫分離

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

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

圖2-2-1-3

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

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

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

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

增加緩存有兩個好處：

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

(2)緩解web server的壓力。

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

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

圖 2-2-1-4

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

1.1 高可用性

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

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

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

1.2 確保高可用性

高可用性的衡量指標

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

其中：

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

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

1.2.1 如何確保高可用

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

(1)系統架構

(2)容災性

(3)監控報警

(4)故障轉移

1.2.1.1 系統架構

系統架構，指整個網站后臺系統的架構。好的系統架構，主要從下面幾個方面考慮：

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

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

(3)web server的選擇，Nginx優于傳統的Apache。

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

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

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

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

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

1.2.1.2 容災性

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

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

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

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

1.2.1.3 監控報警

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

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

(2)監控主機內存使用情況。

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

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

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

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

(7)監控交換設備的使用情況。網絡入、出的流量。

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

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

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

圖3-2-1-3

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

1.2.1.4 故障轉移

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

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

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

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

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

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

圖3-2-1-4-1

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

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

圖3-2-1-4-2

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

1.3 本文小結

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

整理大型網站架構必知必會的幾個服務器知識

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

1、負載均衡服務器

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

2、web服務器

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

3、緩存服務器

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

4、消息隊列服務器

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

5、文件服務器

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

6、索引服務器

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

7、搜索服務器

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

8、作業服務器

主要用于后端應用程序大批量大數據量復雜業務邏輯的定時作業，大多數互聯網公司標配，某些企業的定時調度框架是直接部署在web服務器上的，可以減少這里的所謂作業服務器。

9、數據庫服務器

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

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

10、nosql服務器

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

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

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

11、其他

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

參考：

<<大型網站技術架構>>

<<構建高性能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

網站標題：大型網站服務器架構淺析
文章網址：http://m.kartarina.com/news17/204867.html

成都網站建設公司_創新互聯，為您提供外貿網站建設、外貿建站、App設計、品牌網站建設、網站維護、搜索引擎優化

廣告

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