常見的網站伺服器架構有哪些？

標籤：ber   授權   產生   有一個   otto   為我   指令碼   複雜度   不容易   

xlzd
連結：https://www.zhihu.com/question/20657269/answer/101795180
來源：知乎
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

1. 初始階段的網站架構

一般來講，大型網站都是從小型網站發展而來，一開始的架構都比較簡單，隨著業務複雜和使用者量的激增，才開始做很多架構上的改進。當它還是小型網站的時候，沒有太多訪客，一般來講只需要一台伺服器就夠了，這時應用程式、資料庫、檔案等所有資源都在一台伺服器上，網站架構如所示：

2. 應用服務和資料服務分離

隨著網站業務的發展和使用者量的增加，一台伺服器就無法再滿足需求了。大量使用者訪問導致訪問速度越來越慢，而逐漸增加的資料也會導致儲存空間不足。這時就需要將應用和資料分離，應用和資料分離後整個網站使用 3 台伺服器：應用伺服器、檔案伺服器和資料庫伺服器。這 3 台伺服器對硬體資源的要求各不相同：

• 應用伺服器商務邏輯，需要強大的CPU
• 資料庫伺服器對磁碟讀寫操作很多，需要更快的磁碟和更大的記憶體
• 檔案伺服器儲存使用者上傳的檔案，因此需要更大的磁碟空間

此時，網站系統的架構如所示：

3. 使用緩衝改善網站效能

隨著使用者再增加，網站又會一次面臨挑戰：資料庫壓力太大導致整站訪問效率再此下降，使用者體驗受到影響。一個網站，往往 80% 的業務訪問集中在 20% 的資料上，比如微博請求量最多的肯定是那些千萬級粉絲的大 V 的微博，而幾乎沒有人關注的你的首頁，除了自己想起來之外根本不會被開啟。既然大部分業務訪問集中在一小部分資料上，那就把這一小部分資料先提前緩衝在記憶體中，而不是每次都去資料庫讀取，這樣就可以減少資料庫的訪問壓力，從而提高整個網站的訪問速度。

網站使用的緩衝一般分為緩衝到應用伺服器或者緩衝在專門的分布式快取服務器。緩衝到應用伺服器自己的訪問速度快很多，但是受自身記憶體限制，往往不太適用。遠程分布式緩衝使用一個叢集專門負責快取服務，當記憶體不夠還可以輕鬆得動態擴容。

4. 使用應用伺服器叢集改善網站的並發處理能力

使用緩衝後，資料訪問壓力得到了緩解，但是單一應用伺服器能夠處理的請求串連有限，在網站訪問高峰期，應用伺服器就成了整個網站的效率瓶頸。使用分布式叢集是網站解決高並發、海量資料問題的常用手段。當一台伺服器的處理能力和儲存空間不足時，不要嘗試去更換更強大的伺服器，對大型網站而言，多麼強大的伺服器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一台伺服器分擔原有伺服器的訪問及儲存壓力。 對網站架構而言，只要能通過增加一台伺服器的方式改善負載壓力，就可以以同樣的方式持續增加伺服器不斷改善系統效能，從而實現系統的延展性。應用伺服器實現叢集是網站可伸縮架構設計中較為簡單成熟的一種，如所示：

通過負載平衡調度伺服器，可以將來自使用者瀏覽器的訪問請求分發到應用伺服器叢集中的任何一台伺服器上，如果有更多使用者，就在叢集中加入更多的應用伺服器，使應用伺服器的壓力不再成為整個網站的瓶頸。

5. 資料庫讀寫分離

網站在使用緩衝後，使對大部分資料讀操作訪問都可以不通過資料庫就能完成，但是仍有一部分讀操作（緩衝訪問不命中、緩衝到期）和全部的寫操作都需要訪問資料庫，在網站的使用者達到一定規模後，資料庫因為負載壓力過高而成為網站的瓶頸。 目前大部分的主流資料庫都提供主從熱備功能，通過配置兩台資料庫主從關係，可以將一台資料庫伺服器的資料更新同步到另一台伺服器上。網站利用資料庫的這一功能，實現資料庫讀寫分離，從而改善資料庫負載壓力。如所示：

應用伺服器在寫資料的時候，訪問主要資料庫，主要資料庫通過主從複製機制將資料更新同步到從資料庫，這樣當應用伺服器讀資料的時候，就可以通過從資料庫獲得資料。為了便於應用程式訪問讀寫分離後的資料庫，通常在應用伺服器端使用專門的資料訪問模組，使資料庫讀寫分離對應用透明。

6. 使用反向 Proxy和 CDN 加速網站響應

隨著網站業務不斷髮展，使用者規模越來越大，由於中國複雜的網路環境，不同地區的使用者訪問網站時，速度差別也極大。有研究表明，網站訪問延遲和使用者流失率正相關，網站訪問越慢，使用者越容易失去耐心而離開。為了提供更好的使用者體驗，留住使用者，網站需要加速網站訪問速度。主要手段有使用 CDN 和反向 Proxy。如所示：

7. 使用Distributed File System和分散式資料庫系統

任何強大的單一伺服器都滿足不了大型網站持續增長的業務需求。資料庫經過讀寫分離後，從一台伺服器拆分成兩台伺服器，但是隨著網站業務的發展依然不能滿足需求，這時需要使用分散式資料庫。檔案系統也一樣，需要使用Distributed File System。如所示：

分散式資料庫是網站資料庫拆分的最後手段，只有在單表資料規模非常龐大的時候才使用。不到不得已時，網站更常用的資料庫拆分手段是業務分庫，將不同業務的資料部署在不同的物理伺服器上。

8. 使用 NoSQL 和搜尋引擎

隨著網站業務越來越複雜，對資料存放區和檢索的需求也越來越複雜，網站需要採用一些非關聯式資料庫技術如 NoSQL 和非資料庫查詢技術如搜尋引擎。如所示：

NoSQL 和搜尋引擎都是源自互連網的技術手段，對可伸縮的分布式特性具有更好的支援。應用伺服器則通過一個統一資料訪問模組訪問各種資料，減輕應用程式管理諸多資料來源的麻煩。

9. 業務拆分

大型網站為了應對日益複雜的業務情境，通過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。

具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署。應用之間可以通過一個超連結建立關係（在首頁上的導航連結每個都指向不同的應用地址），也可以通過訊息佇列進行資料分發，當然最多的還是通過訪問同一個資料存放區系統來構成一個關聯的完整系統，如所示：

10. 分布式服務

隨著業務拆分越來越小，儲存系統越來越龐大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難。由於所有應用要和所有資料庫系統串連，在數萬台伺服器規模的網站中，這些串連的數目是伺服器規模的平方，導致資料庫連接資源不足，拒絕服務。

既然每一個應用系統都需要執行許多相同的業務操作，比如使用者管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的Business Connectivity資料庫，提供共用商務服務，而應用系統只需要系統管理使用者介面，通過分布式服務調用共用商務服務完成具體業務操作。如所示：

大型網站的架構演化到這裡，基本上大多數的技術問題都可以得以解決了。

編輯於 2016-09-131.1K33 條評論分享收藏感謝收合牛浩帆離問題越近，離真相越近764 人贊同了該回答

2013/04/18 更新

[只是大架構介紹，實際使用中的不容易注意的細節太多了，需要經驗的積累，才能運用嫻熟]

以下的架構都是在假設已經最佳化過linux核心的情況下進行

初級篇：（單機模式）

假設配置：（Dual core 2.0GHz,4GB ram,SSD）

基礎架構：apache(PHP) + Mysql / IIS + MSSQL
（最基礎架構，處理一般訪問請求）

進階1：替換Apache為Nginx，並在資料庫前加上cache層【資料庫的速度是最大的瓶頸】
Nginx(PHP) + Memcache + Mysql
（此時已經具備處理小型訪問量的能力）

進階2：隨著訪問量的上漲，最先面臨的問題就來了：CGI無法匹配上Nginx的高IO效能，這時候可以通過寫擴充來替代指令碼程式來提升效能，C擴充是個好辦法，但是大家更喜歡用簡單的指令碼語言完成任務，Taobao團隊開源了一個Nginx_lua模組，可以用lua寫Nginx擴充，這時候可處理的並發已經超越進階1 一個檔次了。
Nginx(nginx_lua or C) + Memcache + Mysql
（此時處理個同時線上三四千人沒有問題了）

進階3：隨著使用者的增多，Mysql的寫入速度成了又一大瓶頸，讀取有memcache做緩衝，但寫入是直接面對Mysql，效能受到了很大阻礙，這時候，要在Nginx和Mysql中間加入一層寫緩衝，隊列系統就出場了,就以RabbitMQ為例，所有寫入操作全部丟到這隻兔子的胃裡面，然後屁股後面寫個接應程式，一條條的拉出來再寫入mysql。而RabbitMQ的寫入效率是Mysql的N倍，此時架構的處理能力又上一階層。
|----write------>RabbitMQ--------
Nginx（lua or c）----- |--------->Mysql
|----read------>Memcache--------

(此時的並發吞吐能力已經可以處理萬人左右線上)

中級篇：（分而治之）

此時我們在單機最佳化上已經算是達到極限，接下來就要叢集來顯示作用了。

資料庫篇： 資料庫總是在整個環節中是吞吐能力最弱的，最常見的方法就是sharding。
sharding可以按多種方法來分，沒有定式，看情況。可以按使用者ID區段分，按讀寫分等等，可用參考軟體：mysql proxy（工作原理類似lvs）

緩衝篇：memcache一般採用的是構建memcache pool，將緩衝分散到多台memcache節點上，如何將快取資料均勻分散在各節點，一般採用將各節點順序編號，然後hash取餘對應到各個節點上去。這樣可以做到比較均勻的分散，但是有一個致命點就是，如果節點數增加或減少，將會帶來幾乎80%的資料移轉，解決方案我們在進階篇再提。

WEB伺服器篇： web伺服器叢集的建設，最常見的就是lvs方式(memcache pool同樣可以如此組建)，lvs的核心就是調度節點，調度節點負責將流量通過演算法分散到各個節點上，因調度所耗資源很少，所以可以產生很高的吞吐率，後台節點數量可以任意增刪，但此法弊病就是如果調度節點掛了，則整個叢集都掛了，解決方案我們在進階篇提。
方法2:參見 HAProxy - The Reliable, High Performance TCP/HTTP Load Balancer

進階篇：（高可用性+高可擴充性的叢集）

單點調度故障解決：
叢集的好處顯而易見，但是有一個弊端就是單節點進行調度，如果節點出現故障，則整個叢集全部都無法服務，對此的解決方案，我們使用keepalived來解決。Keepalived for Linux
keepalived是基於VRRP協議（VRRP協議介紹）的，請一定先瞭解VRRP協議後再進行配置。
keepalived可以把多台裝置虛擬出一個IP，並自動在故障節點與備用節點之間實現failover切換。這樣我們配置兩台貨多台lvs調度節點，然後配置好keepalived就可以做到lvs調度節點出現故障後，自動切換到備用調度節點。（同樣適用於mysql）

memcache叢集擴充解決：
memcache因為我們一般採用的都是hash後除以節點數取餘，然後分配到對應節點上，如果節點數出現變化，以前的快取資料將基本都不能命中。
解決方案：consistent hashing 簡介：一致性雜湊

consistent hashing大概的思路就是，把hash後的值保證在 0 ~ (2^32)-1 的數值上，然後把這一連串數字對應映射到一個想象的圓上。
把要儲存的各個值hash後，放到圓上，

然後把cache節點也用同樣的hash方法，映射到圓上，然後每個剛才hash過的value順時針尋找離自己最近的節點，這個節點就是儲存它的節點。

為了提高儲存的平衡性，演算法還可以加入虛擬節點的概念，即每個實際cache節點，會在圓上對應N個虛擬節點，這樣可以提高演算法的命中率，更加平衡。

consistent hashing原理：Consistent hashing and random trees

完結。
另：以片來自互連網，未找到原創者，故未標註來源。
歡迎署名轉載。編輯於 2014-05-0776433 條評論分享收藏感謝收合知乎使用者172 人贊同了該回答

系統架構演化曆程-初始階段架構

初始階段 的小型系統 應用程式、資料庫、檔案等所有的資源都在一台伺服器上通俗稱為LAMP

特徵：
應用程式、資料庫、檔案等所有的資源都在一台伺服器上。

描述：
通常伺服器作業系統使用linux，應用程式使用PHP開發，然後部署在Apache上，資料庫使用Mysql，彙集各種免費開源軟體以及一台廉價伺服器就可以開始系統的發展之路了。

系統架構演化曆程-應用服務和資料服務分離

好景不長，發現隨著系統訪問量的再度增加，webserver機器的壓力在高峰期會上升到比較高，這個時候開始考慮增加一台webserver

特徵：
應用程式、資料庫、檔案分別部署在獨立的資源上。

描述：
資料量增加，單台伺服器效能及儲存空間不足，需要將應用和資料分離，並發處理能力和資料存放區空間得到了很大改善。

系統架構演化曆程-使用緩衝改善效能

特徵：
資料庫中訪問較集中的一小部分資料存放區在快取服務器中，減少資料庫的訪問次數，降低資料庫的訪問壓力。

描述：
系統訪問特點遵循二八定律，即80%的業務訪問集中在20%的資料上。
緩衝分為本機快取和遠程分布式緩衝，本機快取訪問速度更快但快取資料量有限，同時存在與應用程式爭用記憶體的情況。

系統架構演化曆程-使用應用伺服器叢集

在做完分庫分表這些工作後，資料庫上的壓力已經降到比較低了，又開始過著每天看著訪問量暴增的幸福生活了，突然有一天，發現系統的訪問又開始有變慢的趨勢了，這個時候首先查看資料庫，壓力一切正常，之後查看webserver，發現apache阻塞了很多的請求，而應用伺服器對每個請求也是比較快的，看來 是請求數太高導致需要排隊等待，響應速度變慢

特徵：
多台伺服器通過負載平衡同時向外部提供服務，解決單台伺服器處理能力和儲存空間限制的問題。

描述：
使用叢集是系統解決高並發、海量資料問題的常用手段。通過向叢集中追加資源，提升系統的並發處理能力，使得伺服器的負載壓力不再成為整個系統的瓶頸。

系統架構演化曆程-資料庫讀寫分離

享受了一段時間的系統訪問量高速增長的幸福後，發現系統又開始變慢了，這次又是什麼狀況呢，經過尋找，探索資料庫寫入、更新的這些操作的部分資料庫連接的資源競爭非常激烈，導致了系統變慢

特徵：
多台伺服器通過負載平衡同時向外部提供服務，解決單台伺服器處理能力和儲存空間限制的問題。

描述：
使用叢集是系統解決高並發、海量資料問題的常用手段。通過向叢集中追加資源，使得伺服器的負載壓力不在成為整個系統的瓶頸。

系統架構演化曆程-反向 Proxy和CDN加速

特徵：
採用CDN和反向 Proxy加快系統的 訪問速度。

描述：
為了應付複雜的網路環境和不同地區使用者的訪問，通過CDN和反向 Proxy加快使用者訪問的速度，同時減輕後端伺服器的負載壓力。CDN與反向 Proxy的基本原理都是緩衝。

系統架構演化曆程-Distributed File System和分散式資料庫

隨著系統的不斷運行，資料量開始大幅度增長，這個時候發現分庫後查詢仍然會有些慢，於是按照分庫的思想開始做分表的工作

特徵：
資料庫採用分散式資料庫，檔案系統採用Distributed File System。

描述：
任何強大的單一伺服器都滿足不了大型系統持續增長的業務需求，資料庫讀寫分離隨著業務的發展最終也將無法滿足需求，需要使用分散式資料庫及Distributed File System來支撐。
分散式資料庫是系統資料庫拆分的最後方法，只有在單表資料規模非常龐大的時候才使用，更常用的資料庫拆分手段是業務分庫，將不同的業務資料庫部署在不同的物理伺服器上。

系統架構演化曆程-使用NoSQL和搜尋引擎

特徵：
系統引入NoSQL資料庫及搜尋引擎。

描述：
隨著業務越來越複雜，對資料存放區和檢索的需求也越來越複雜，系統需要採用一些非關係型資料庫如NoSQL和分資料庫查詢技術如搜尋引擎。應用伺服器通過統一資料訪問模組訪問各種資料，減輕應用程式管理諸多資料來源的麻煩。

系統架構演化曆程-業務拆分

特徵：
系統上按照業務進行拆分改造，應用伺服器按照業務區分進行分別部署。

描述：
為了應對日益複雜的業務情境，通常使用分而治之的手段將整個系統業務分成不同的產品線，應用之間通過超連結建立關係，也可以通過訊息佇列進行資料分發，當然更多的還是通過訪問同一個資料存放區系統來構成一個關聯的完整系統。

縱向拆分：
將一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接將其設計部署為一個獨立的Web應用系統

縱向拆分相對較為簡單，通過梳理業務，將較少相關的業務剝離即可。

橫向拆分：將複用的業務拆分出來，獨立部署為分布式服務，新增業務只需要調用這些分布式服務

橫向拆分需要識別可複用的業務，設計服務介面，規範服務依賴關係。

系統架構演化曆程-分布式服務

特徵：
公用的應用模組被提取出來，部署在分布式伺服器上供應用伺服器調用。

描述：
隨著業務越拆越小，應用系統整體複雜程度呈指數級上升，由於所有應用要和所有資料庫系統串連，最終導致資料庫連接資源不足，拒絕服務。

編輯於 2014-10-3017215 條評論分享收藏感謝收合矮個芝麻一枚程式猿40 人贊同了該回答這個問題之寬泛已經跨越銀河系了_(:з」∠)_
哥哥我只能從初級到進階一點點解釋了~~~~

圈子裡有一個偉人說過一句話：
億萬級的架構是逐步演化出來的，傻缺才會上來就直接照著億萬級的來搭(′?`) ...（沒錯這個偉人就是我），所以這裡只是解釋下不同量級下的架構形式，具體要看業務規模和體量。

補一個，中小型網站推薦的技術選型LAMP ( linux+apache+mysql+php )。
大型網站的架構技術則可以靈活選擇。

新生兒：
最初的網站一般只是個demo，老闆拿去給朋友們看看，恩，小夥子網站做的不錯，給你加工資∠( ? 」∠)＿，這個時期資源成本和時間成本第一，一般程式，資料庫，檔案都放在一台伺服器，如：

這個時期可以說不存在太多架構的概念，apache/ IIS + MYSQL/MSSQL + PHP/JAVA/NET 等選型都可以，具體看公司的技術合伙人的方向，技術合伙人來確定方案和選型即可。

1周歲：
度過了前期的磨合，業務量開始穩步上升之後就建議開始做分離的工作了，可以根據伺服器的用途不同，選用不同的配置安排：

假設業務情況涉及到的檔案會比較多，建議可以做多台檔案伺服器對檔案進行儲存，比如電商類的商品文描圖片及主圖，多網域名稱，多伺服器儲存。
即便是業務初期，也建議至少有一台熱備伺服器，不需要太高的配置，即時對業務資料庫進行備份即可。

2周歲：
一般到了這個階段之後，為了減輕資料庫壓力防止鎖死，以及提高訪問速度，可以開始考慮對核心業務做分布式緩衝處理了。
一般來講，業務初期可以考慮使用一些成熟的緩衝引擎，比如resin等，將搜尋，商品詳情，CMS等頁面基於此做緩衝處理。
另外就是現在CDN服務的費用目前來講成本要比以往低很多了，所以這個階段可以考慮購買CDN的服務了：

5周歲：
如果進入這個階段，那麼首先恭喜你，開始走上正軌了<(￣▽￣)>
一般到了這個階段，隨著訪問量逐漸增加，即便有緩衝的存在，資料庫仍舊會有很大的瓶頸，尤其是電商類網站高並發下單的情境，或者知乎這類一堆人給我點贊刷評論的情況（雖然並沒有╮(╯_╰)╭，一般初步改善資料庫壓力的方案就是做讀寫分離，然後進一步的操作就是分庫分表。

另外一點就是，考慮到業務量極大，為了防止出現線上事故影響服務，另外就是分擔網站入口的請求，因此需要部署負載平衡伺服器。因為網站是一輛需要一直跑的汽車，不能停車換輪，負載平衡的作用之一就是保證每次修輪胎的時候，車子仍然在跑：

------------------------------------------

轉載自https://www.zhihu.com/question/20657269

常見的網站伺服器架構有哪些？