運營一個大型網站需要多少臺服務器？首先要明白，這個問題不容易量化，影響一個大型網站所需服務器數量的因素很多。

對于最基礎的網站源代碼，如果一個技術高超的程序員能實現最好的算法，那么幾臺服務器就能完成一個擁有數千萬并發量的網站。相反，對于低水平的程序員來說，即使幾十萬臺服務器也只能完成幾萬個并發網站。對于隨意需要成百上千臺服務器的網站，程序員素質很低，架構師水平極低。

其次，業務量越大，網站的整體結構就會越復雜。

我們看到的網站只是冰山一角，有成千上萬的系統支持。服務器的評估需要根據不同業務系統的特點進行分析。

(1) 新聞等服務不復雜的普通網站，交互容易，以展示為主，所以即使PV很大，也不會需要很多機器。單臺NGINX服務器可以處理靜態頁面，可以達到幾千甚至幾萬QPS(當然這只是一個理論值，考慮到頁面大小和寬帶等因素是達不到的)。

(2) 業務復雜的系統，如攜程， 京東， 淘寶等。復雜的用戶交互、存儲、支付、第三方溝通等。再加上保證系統穩定性和支持容災，將會成倍增加機器的需求。分析系統，對比業務復雜度，然后對比機器數量更有可比性。

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

再者，什么樣的網站才算大？

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

任何一個大型網站都是經歷用戶積累，然后成長的。

只有一臺服務器對多臺服務器才能支持網站的現有數據、用戶和頁面請求。大型網站(如淘寶， 京東，等)的系統架構。)不具備高性能、高可用性、安全性等完整特征。

它總是隨著用戶的增加和業務功能的擴展而不斷進化和完善。在這個過程中，開發模式、技術架構、設計思路也發生了很大的變化，甚至技術人員也從幾個人發展到一個部門甚至一條產品線。

所以成熟的系統架構是隨著業務的拓展而完善的，不是一蹴而就的；不同業務特性的系統會有自己的側重點。

例如，在淘寶，需要解決搜索、下單和支付海量商品信息的問題。例如，在騰訊，需要解決數億用戶的實時消息傳輸問題，而在百度，則需要處理大量的搜索請求。他們都有自己的業務特點和不同的系統架構。

1.如果一個網站訪問量小，比如一個小公司的小論壇，可能只有幾個人同時在線，穩定性和安全性要求相對較低，那么配置差的服務器就足夠了，數據庫和應用服務器都在上面；

2.再大一點，考慮到數據庫服務器和應用服務器的分離，每個服務器都設置好了，可以再增加一個服務器，把靜態請求和動態請求分開；

3.當一個應用服務在高峰期舉步維艱，嚴重影響訪問質量時，可以考慮增加一個應用服務器進行負載均衡，分散壓力的同時提高穩定性。如果一個應用服務器宕機，還有一個應用服務器響應請求(前提是可以完成負載均衡，所有請求都會交給另一個)；

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

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

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

7.如果網站有大量圖片或文件需要管理，則需要添加圖片服務器或文件系統服務器。這些服務器通常是分布式應用，比如Hadoop，可以使用N個服務器進行部署；

8.如果瞬時流量極大，請求數量達到一定數量級，后臺服務還是很難的，我們對實時響應有一般要求，可以增加N個消息隊列服務器進行緩沖；

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

一、如何搭建一個大型網站架構？

首先，什么是大型網站架構呢？

其實大型網站架構的概念對于每一個開發者來說很籠統、很模糊，正如盲人摸象，看到的、了解到的只是很小的一部分，大部分情況下我們只是負責架構中的一小塊內容，所以很難清晰地給出具體定義。這就是所謂“不識廬山真面目 只緣身在此山中”的尷尬吧。所以我們要跳出來，站在宏觀的角度，從整體到細節實現來認識大型網站架構。

那么從宏觀的角度怎么去認識大型網站架構呢？

1. 問題識別：當前什么問題、誰的問題、問題邊界；

2. 概念認知：通過分析問題，會產生哪些概念，統一概念認知，達成溝通交流規范；

3. 架構切分：根據概念來解決問題，如何架構切分，產生哪些架構，提出具體解決方案；

在進行分析大型網站架構的演進之路前，首先我們要明確的兩個價值觀：

1. 核心價值：隨網站所需靈活應對；大型網站不是從無到有一步就搭建好一個大型網站，而是能夠伴隨小型網站業務的漸進發展，慢慢地演化成一個大型網站；

2. 驅動力量：網站的業務發展—業務成就了技術，事業成就了人，而不是相反；

還有，大型網站架構演進必須避免的幾個誤區：

1. 一味追隨大公司的解決方案；

2. 為了技術而技術-->常見問題；

3. 企圖用技術解決所有問題：技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段去解決；

二、網站架構體系演進

1、單機時代

草根時期，快速開發網站并上線。當然，通常只是先試水，用戶規模也沒有形成，經濟能力和投入也非常有限。應用程序、數據庫、文件等所有資源都集中在一臺 Server上，典型案例：基于 LAMP 架構的 PHP 網站；

1. 優點：簡單、快速迭代達成業務目標；

2. 缺點：存在單點、談不上高可用；

3. 技術點：應用設計要保證可擴展；

2、緩存出場

有一定的業務量和用戶規模了，想提升網站速度，于是，緩存出場了。

1. 優點：簡單有效、方便維護；

2. 缺點：存在單點、談不上高可用；

3. 技術點：客戶端（瀏覽器）緩存、前端頁面緩存、頁面片段緩存、本地數據緩存/數據庫緩存、遠程緩存；

如上圖，緩存可以分為：

1. 頁面緩存：客戶端緩存，減少對網站的訪問；

2. 本地緩存：訪問速度快，但數據量有限，減少對DB查詢；

3. 遠程緩存：遠程訪問，可以集群，因此容量不受限制；

3、數據服務與應用分離

市場反響還不錯，用戶量每天在增長，數據庫瘋狂讀寫，逐漸發現一臺服務器快撐不住了。于是，決定把數據服務和APP做分離。

1. 優點：簡單有效、方便維護、提高不同Server對硬件資源的利用率；

2. 缺點：存在單點、談不上高可用；

3. 技術點：文件服務器部署、數據庫服務器，擴展數據訪問模塊；

分離后三臺 Server 對硬件資源的需求各不相同：

1. 應用服務器：需要更快更強大的 CPU；

2. 數據庫服務器：需要更快的硬盤和更大的內存；

3. 文件服務器：需要更大的硬盤；

4、數據庫讀寫分離

單臺數據庫也感覺快撐不住了，一般都會嘗試做“讀寫分離”。由于大部分互聯網“讀多寫少”的特性所決定的。Salve的臺數，取決于按業務評估的讀寫比例。

1. 優點：簡單有效、降低數據庫單臺壓力；

2. 缺點：讀寫分離，增加程序難度，架構變復雜，維護難度增加；

3. 技術點：數據庫主從同步部署，擴展數據訪問模塊，實現讀寫分離；

5、應用服務集群

數據庫層面是緩解了，但是應用程序層面也出現了瓶頸，由于訪問量增大，加上早期程序員水平有限寫的代碼也很爛，人員流動性也大，很難去維護和優化。所以，很常用的辦法還是“堆機器”。

1. 優點：增加服務器和HA機制，系統性能及可用性得到保證；

2. 缺點：應用之間緩存、Session一致性問題；

3. 技術點：負載均衡；

通過集群解決高并發、海量數據問題的常用手段，實現系統的可伸縮性。通過負載均衡調度器，可將用戶訪問分發到集群中的某臺 Server 上，應用服務器的負載壓力不再成為整個網站的瓶頸。

6、集中式緩存、Session集中存儲

加機器誰都會加，關鍵是加完之后得有效果，加完之后可能會引發一些問題。例如非常常見的：集群應用之間頁面輸出緩存和本地緩存一致性的問題，Session保存的問題......。

1. 優點：應用之間緩存、Session一致，存儲無限制，可以擴展；

2. 缺點：不如本地緩存訪問快，緩存服務器、Session服務器等仍存在單點問題；

3. 技術點：緩存服務器部署、Session集中存儲方案；

7、動靜分離

動靜分離也是提高網站響應速度的一種常用方式。將動態請求與靜態請求分離開，盡量減少對應用服務器的壓力。同時，可以再進一步對靜態請求，進行緩存，以加快響應速度。可以需要開發人員配合（把靜態資源放獨立站點下），也可以不需要開發人員配合（利用7層反向代理來處理，根據后綴名等信息來判斷資源類型）。

1. 優點：減輕應用負載壓力，針對靜態文件緩存；

2. 缺點：靜態文件緩存更新失效問題；

3. 技術點：動靜分離、靜態文件緩存方案；

8、反向代理和CDN加速網站響應

使用反向代理和CDN加速網站響應：CDN 和反向代理的基本原理都是緩存，區別在于：

1. CDN部署在網絡提供商的機房；

2. 反向代理則部署在網站的中心機房；

使用 CDN 和反向代理的目的都是盡早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕后端服務器的負載壓力。

1. 優點：減輕應用負載壓力，異地緩存有效解決不同地方用戶訪問過慢的問題；

2. 缺點：成本大幅增加，架構進一步復雜化，也維護難度進一步增大，靜態文件緩存更新失效問題；

3. 技術點：CDN、反向代理方案；

9、使用NoSQL和搜索引擎

到這里，已經基本做到了DB層面和應用層面的橫向擴展了，可以開始關注一些其它方面，例如：站內搜索的精準度，對DB的依賴，開始引入全文索引、NoSQL。

NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分布式特性具有更好的支持。應用服務器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。

1. 優點：降低DB依賴；

2. 缺點：單點問題，談不上高可用；

3. 技術點：NoSQL、搜索引擎、分布式；

到目前為止，一個能夠承載日均百萬級訪問量的中型網站架構基本介紹完了。

10、如何保證高可用

在做擴展滿足了基本的性能需求后，我們會逐漸關注“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。

對關鍵應用/服務，做集群冗余負載，這也是保證高可用比較常用的手段：

1. 文件系統、數據庫系統集群；

2. 靜態內容服務器集群；

3. CDN服務器集群；

4. 反向代理服務器集群；

5. 負載均衡調度器集群；

6. 分布式NoSQL服務器集群；

7. 搜索引擎服務器集群；

8. 分布式緩存服務器集群；

9. 分布式Session服務器集群；

1. 優點：集群負載，保證高可用；

2. 缺點：數據一致性、數據有狀態問題；

3. 技術點：負載調度器、集群方案；

截止目前為止，都沒有怎么去改動應用程序的架構，或者說通俗點，都不怎么需要大面積的修改代碼。

如果上面那些手段都用光了，還是支撐不住怎么辦？不停的加機器也不是辦法??？

11、應用垂直拆分

隨著業務越來越復雜，網站的功能越來越多，雖然部署層面是采用的集群，但是應用程序架構層面還是“集中式”的，這樣會導致很多耦合，不便于開發、維護，而且容易“一榮俱損”。所以，通常會把網站拆分出不同的子站點來單獨宿主。

通過分而治之的手段將整個網站業務分成不同的產品線，如首頁、商鋪、訂單、賣家、買家等拆分成不同的產品線，分歸不同的業務團隊負責。各個應用之間可以通過建立一個超鏈接建立關系，也可以通過消息隊列進行數據分發。

1. 優點：降低耦合、分壓；

2. 缺點：應用架構復雜；

3. 技術點：業務抽取拆分；

12、業務垂直分庫

應用都拆了，由于單個數據庫的連接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作。

1. 優點：降低DB耦合、分壓DB；

2. 缺點：數據訪問模塊復雜；

3. 技術點：業務抽取拆分；

13、分布式服務化

拆分應用和DB之后，其實還是會有很多問題。不同的站點，里面可能會有相同邏輯和功能的代碼。當然，對于一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關系等處理起來非常麻煩）。

既然每一個應用系統都需要執行許多相通的業務操作，比如用戶管理、商品管理等，那么可以將這些共用的業務提取出來，獨立部署。這樣，傳說中的SOA的價值就得到體現了。

1. 優點：服務統一管理，提供重用度；

2. 缺點：應用架構更復雜；

3. 技術點：業務抽取拆分、服務化技術方案；

消息隊列

應用、服務之間還是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了。

1. 優點：提高吞吐量、應用、服務之間解耦；

2. 缺點：存在消息消費延遲問題；

3. 技術點：消息隊列技術方案；

14、分庫分表

最后，再介紹一個大型互聯網公司都用的絕技--分庫分表。個人經驗，不是業務發展和各方面非常迫切，不要輕易走這一步。

因為分庫分表誰都會干，關鍵是拆完之后怎么辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決數據庫拆分問題。

分庫分表：

1. 橫向拆分；

2. 縱向拆分；

3. 分布式數據庫訪問層；

4. 數據庫中間件（代理）；

15、網站架構總結

上面講述了在網站業務發展的不同階段，會面臨不同的問題，針對不同的問題，會選擇不同的架構。大型網站架構就是在不同階段時解決不同問題的過程中慢慢演進來的。

最后幾句話，送給有緣的你：

1. 一切以解決業務目標為首要任務；

2. 沒有以業務為目標的任何架構、技術，都是毫無意義的耍流氓；

3. 再牛逼的架構、再牛逼的技術，不能夠解決業務的問題，你也只能算是會架構、會技術的工匠，而不能算是真正意義上的架構師；

4. 業務成就了技術，平臺成就了人，事業成就了人，而不是相反；

16、最后說說大型網站的配置建議。

在選擇服務器的時候，很多站長認為虛擬空間就夠了，但實際上并非如此。當一個網站的流量不斷完善的時候，對web服務器的配置要求也會隨之增加。當一個網站的流量數以萬計時，虛擬服務器基本不適合使用。建設大型網站應該使用什么樣的配置？

對于電商網站來說，每天都有大量的用戶訪問和購買，所以服務器需要處理大量的數據請求，所以對于電商網站的CPU和內存的標準會更高。

對于視頻網站來說，除了用戶的訪問請求和下載數據之外，還需要配置大硬盤和大帶寬，才能有效保證用戶在觀看時不會卡殼。

對于大型網站，無論是視頻網站、門戶企業網站還是電商小票，在租用服務器時，都需要考慮基本的配置標準，比如CPU、硬盤、內存、帶寬、硬防御。CPU要8核以上，內存視頻網站不低于16G。硬盤至少1T，獨占帶寬100M會更好。

當然，這里推薦的只是正規大型網站所需的配置條件。如果您是易受攻擊的行業類型，還應該考慮服務器防御。