運(yùn)營一個(gè)大型網(wǎng)站需要多少臺(tái)服務(wù)器?

首先要明白，這個(gè)問題不容易量化，影響一個(gè)大型網(wǎng)站所需服務(wù)器數(shù)量的因素很多。

對(duì)于最基礎(chǔ)的網(wǎng)站源代碼，如果一個(gè)技術(shù)高超的程序員能實(shí)現(xiàn)最好的算法，那么幾臺(tái)服務(wù)器就能完成一個(gè)擁有數(shù)千萬并發(fā)量的網(wǎng)站。相反，對(duì)于低水平的程序員來說，即使幾十萬臺(tái)服務(wù)器也只能完成幾萬個(gè)并發(fā)網(wǎng)站。對(duì)于隨意需要成百上千臺(tái)服務(wù)器的網(wǎng)站，程序員素質(zhì)很低，架構(gòu)師水平極低。

其次，業(yè)務(wù)量越大，網(wǎng)站的整體結(jié)構(gòu)就會(huì)越復(fù)雜。我們看到的網(wǎng)站只是冰山一角，有成千上萬的系統(tǒng)支持。服務(wù)器的評(píng)估需要根據(jù)不同業(yè)務(wù)系統(tǒng)的特點(diǎn)進(jìn)行分析。

(1) 新聞等服務(wù)不復(fù)雜的普通網(wǎng)站，交互容易，以展示為主，所以即使PV很大，也不會(huì)需要很多機(jī)器。單臺(tái)nginx服務(wù)器可以處理靜態(tài)頁面，可以達(dá)到幾千甚至幾萬QPS(當(dāng)然這只是一個(gè)理論值，考慮到頁面大小和寬帶等因素是達(dá)不到的)。

(2) 業(yè)務(wù)復(fù)雜的系統(tǒng)，如攜程， 京東， 淘寶等。復(fù)雜的用戶交互、存儲(chǔ)、支付、第三方溝通等。再加上保證系統(tǒng)穩(wěn)定性和支持容災(zāi)，將會(huì)成倍增加機(jī)器的需求。分析系統(tǒng)，對(duì)比業(yè)務(wù)復(fù)雜度，然后對(duì)比機(jī)器數(shù)量更有可比性。

此外，機(jī)器配置也有好有壞，新服務(wù)器的性能可能是舊機(jī)器的幾倍甚至十倍。

再者，什么樣的網(wǎng)站才算大？

假設(shè)2M帶寬，它可以在線承載10，000個(gè)IP。網(wǎng)頁大概60K，一般人的等待耐心是3到5秒。按3秒計(jì)算，每個(gè)網(wǎng)頁占用的帶寬約為20K/S2M=2048K2048/20=103。如果是5秒計(jì)算，200個(gè)人可以同時(shí)觸發(fā)。如果頁面文件很小，以此類推。用2M帶寬支持300人在線基本沒問題。如果每秒300人可以同時(shí)觸發(fā)，那么每分鐘就有1.8萬人，低至每秒10人。它每分鐘還能載600人。按照一般20分鐘SESSION故障計(jì)算，它也有12000人的承載能力。這種網(wǎng)站可以同時(shí)承受1000W人在線，基本可以算是中型網(wǎng)站。如新浪， 雅虎，校區(qū)、qq等�？梢运闶谴笮途W(wǎng)站。像官網(wǎng)這樣的中小企業(yè)都是小企業(yè)。

任何一個(gè)大型網(wǎng)站都是經(jīng)歷用戶積累，然后成長的。

只有一臺(tái)服務(wù)器對(duì)多臺(tái)服務(wù)器才能支持網(wǎng)站的現(xiàn)有數(shù)據(jù)、用戶和頁面請(qǐng)求。大型網(wǎng)站(如淘寶， 京東，等)的系統(tǒng)架構(gòu)。)不具備高性能、高可用性、安全性等完整特征。它總是隨著用戶的增加和業(yè)務(wù)功能的擴(kuò)展而不斷進(jìn)化和完善。在這個(gè)過程中，開發(fā)模式、技術(shù)架構(gòu)、設(shè)計(jì)思路也發(fā)生了很大的變化，甚至技術(shù)人員也從幾個(gè)人發(fā)展到一個(gè)部門甚至一條產(chǎn)品線。所以成熟的系統(tǒng)架構(gòu)是隨著業(yè)務(wù)的拓展而完善的，不是一蹴而就的；不同業(yè)務(wù)特性的系統(tǒng)會(huì)有自己的側(cè)重點(diǎn)。例如，在淘寶，需要解決搜索、下單和支付海量商品信息的問題。例如，在騰訊，需要解決數(shù)億用戶的實(shí)時(shí)消息傳輸問題，而在百度，則需要處理大量的搜索請(qǐng)求。他們都有自己的業(yè)務(wù)特點(diǎn)和不同的系統(tǒng)架構(gòu)。

1.如果一個(gè)網(wǎng)站訪問量小，比如一個(gè)小公司的小論壇，可能只有幾個(gè)人同時(shí)在線，穩(wěn)定性和安全性要求相對(duì)較低，那么配置差的服務(wù)器就足夠了，數(shù)據(jù)庫和應(yīng)用服務(wù)器都在上面；

2.再大一點(diǎn)，考慮到數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的分離，每個(gè)服務(wù)器都設(shè)置好了，可以再增加一個(gè)服務(wù)器，把靜態(tài)請(qǐng)求和動(dòng)態(tài)請(qǐng)求分開；

3.當(dāng)一個(gè)應(yīng)用服務(wù)在高峰期舉步維艱，嚴(yán)重影響訪問質(zhì)量時(shí)，可以考慮增加一個(gè)應(yīng)用服務(wù)器進(jìn)行負(fù)載均衡，分散壓力的同時(shí)提高穩(wěn)定性。如果一個(gè)應(yīng)用服務(wù)器宕機(jī)，還有一個(gè)應(yīng)用服務(wù)器響應(yīng)請(qǐng)求(前提是可以完成負(fù)載均衡，所有請(qǐng)求都會(huì)交給另一個(gè))；

4.如果安全要求高，就不能有數(shù)據(jù)丟失，尤其是涉及到錢的問題，數(shù)據(jù)庫需要備份，那么數(shù)據(jù)庫主從都可以做，主機(jī)停機(jī)時(shí)會(huì)自動(dòng)切換到從機(jī)；

5.如果訪問量持續(xù)增加，大量數(shù)據(jù)被頻繁讀取，相對(duì)較少被寫入，這部分?jǐn)?shù)據(jù)可以分離出來緩存到專門的服務(wù)器，比如Memcache和Redis緩存服務(wù)器，可以大大減輕數(shù)據(jù)庫讀寫的壓力。這是一種非常有效的解壓方法；

6.如果部署N個(gè)緩存服務(wù)器后數(shù)據(jù)庫仍然有壓力，可以考慮讀取數(shù)據(jù)庫的寫分李，一個(gè)主服務(wù)器寫，N個(gè)從服務(wù)器讀。當(dāng)然，你必須做好數(shù)據(jù)同步；

7.如果網(wǎng)站有大量圖片或文件需要管理，則需要添加圖片服務(wù)器或文件系統(tǒng)服務(wù)器。這些服務(wù)器通常是分布式應(yīng)用，比如Hadoop，可以使用N個(gè)服務(wù)器進(jìn)行部署；

8.如果瞬時(shí)流量極大，請(qǐng)求數(shù)量達(dá)到一定數(shù)量級(jí)，后臺(tái)服務(wù)還是很難的，我們對(duì)實(shí)時(shí)響應(yīng)有一般要求，可以增加N個(gè)消息隊(duì)列服務(wù)器進(jìn)行緩沖；

9.然后是上述服務(wù)器的大規(guī)模集群。它可以大到n。有些巨頭有幾十萬甚至幾百萬臺(tái)服務(wù)器。幾年前，谷歌有250萬臺(tái)服務(wù)器。

最后說說大型網(wǎng)站的配置建議。

在選擇服務(wù)器的時(shí)候，很多站長認(rèn)為虛擬空間就夠了，但實(shí)際上并非如此。當(dāng)一個(gè)網(wǎng)站的流量不斷完善的時(shí)候，對(duì)web服務(wù)器的配置要求也會(huì)隨之增加。當(dāng)一個(gè)網(wǎng)站的流量數(shù)以萬計(jì)時(shí)，虛擬服務(wù)器基本不適合使用。建設(shè)大型網(wǎng)站應(yīng)該使用什么樣的配置？

對(duì)于電商網(wǎng)站來說，每天都有大量的用戶訪問和購買，所以服務(wù)器需要處理大量的數(shù)據(jù)請(qǐng)求，所以對(duì)于電商網(wǎng)站的CPU和內(nèi)存的標(biāo)準(zhǔn)會(huì)更高。

對(duì)于視頻網(wǎng)站來說，除了用戶的訪問請(qǐng)求和下載數(shù)據(jù)之外，還需要配置大硬盤和大帶寬，才能有效保證用戶在觀看時(shí)不會(huì)卡殼。

對(duì)于大型網(wǎng)站，無論是視頻網(wǎng)站、門戶企業(yè)網(wǎng)站還是電商小票，在租用服務(wù)器時(shí)，都需要考慮基本的配置標(biāo)準(zhǔn)，比如CPU、硬盤、內(nèi)存、帶寬、硬防御。CPU要8核以上，內(nèi)存視頻網(wǎng)站不低于16G。硬盤至少1T，獨(dú)占帶寬100M會(huì)更好。

當(dāng)然，這里推薦的只是正規(guī)大型網(wǎng)站所需的配置條件。如果您是易受攻擊的行業(yè)類型，還應(yīng)該考慮服務(wù)器防御。另外，無論您的網(wǎng)站是需要租用服務(wù)器還是需要托管服務(wù)器，您都可以聯(lián)系我們天 下 數(shù) 據(jù)，我們會(huì)根據(jù)您的業(yè)務(wù)需求，為您全面分析和推薦最佳解決方案。詳詢電話400-638-8808 官網(wǎng)：m.51huadong.com

本文鏈接：http://m.51huadong.com/servernews/11006452.html