服務器劃分

?????? 對于訪問量大的網站而言，將網站的各個部分拆分分別部署到不同服務器上是很有必要的。例如將圖片和web站點分開。一般而言，在網站的整個服務器部署上分為如下幾種類型：

???????文件服務器：一般存儲系統的相關圖片和文件，給各個子系統提供統一的文件調用

???????代理服務器：一般使用linux+Nginx作為反向代理

???????web服務器：.net中最常用的Web服務器IIS，Mono中一般使用Nginx

???????應用服務器：負責系統中各個業務邏輯的提供，比如用戶中心，結算中心，支付中心等

???????緩存服務器：提供MemCached緩存服務

???????數據庫服務器：負責網站數據的提供，一般為Sqlserver,mysql,oracle等

帶寬的計算

?????? 假設網站每天要承受100萬pv的訪問量，計算帶寬要涉及到兩個指標(峰值流量和頁面平均大小),帶寬單位為bps(bit/s)。

?????? 1、假設峰值流量為平均流量的5倍；

?????? 2、假設每次訪問的平均頁面大小為100KB左右。

?????? 1B=8b---------------------1B/s=8b/s(1Bps=8bps)

?????? 1KB=1024B ------------- 1KB/s=1024B/s

?????? 1MB=1024KB------------1Mps=1024KB/s

?????? 100萬pv訪問量一天平均分布，折合每秒大約訪問12次，頁面大小為字節(Byte),總共訪問頁面大小就是12*100KB=1200KB,1Byte=8bit,則1200KB=9600Kb，9600Kb/1024大約9Mb/s(9Mbps)，我們網站在峰值流量時一定要保持正常訪問，則真實帶寬應該在9M*5=45Mbps左右。

網站架構的演變過程之一

公司剛剛起步，業務量不大，往往可能在某個虛擬主機空間商租用一個虛擬主機和一個數據庫就搭建了一個最基本的網站

?

網站架構的演變過程之二增加緩存

隨著業務量增加，用戶的訪問越來越多，網站經常性的打不開，慢，甚至出現數據庫鏈接達到最大限制數，這個時候需要針對網站做一些優化策略：

• 減少Http請求，壓縮css，js，圖片的大小
• 將Microsoft Ajax Minifier集成到VS2010對JS，CSS進行編譯時壓縮
• 增加頁面緩存和增加數據緩存處理
• cnblogs上的緩存全解析
• 自購服務器進行IDC托管
• 自購服務器能夠提升硬件的檔次以及帶寬可以自由控制，一般都是獨享帶寬，相比共享帶寬來說能夠支撐更多的訪問量

?

網站架構的演變過程之三增加web服務器

?????? 當系統訪問量的再度增加，webserver機器的壓力在高峰會上升到比較高，這個時候開始考慮增加一臺WebServer，但是增加一臺WebServer的時候意味著要在兩臺的服務器上分別建立相同的站點，那么就會出現如下問題：

?????? 如何讓訪問分配到這兩臺機器上？Nginx

?????? 如何保持狀態信息的同步，例如用戶session等？

?????? 正常考慮的方案有寫入數據庫、開啟狀態服務器、cookie、寫入緩存等。

?????? 如何保持數據緩存信息的同步？

?????? 緩存服務器

?????? 如何讓上傳文件這些類似的功能繼續正常？

?????? 采用文件服務器統一管理

網站架構的演變過程之四分庫，分表，分布式緩存

通過增加web服務器享受了一段快速訪問的幸福后，發現系統又開始變慢了，經過查找，發現數據庫寫入、更新的這些操作的部分數據庫連接的?資源競爭非常激烈，導致了系統變慢，這下怎么辦呢？

分庫

分表

Memcache,Redis分布式緩存

水平分區 VS 垂直分區

?	水平	垂直
存儲依賴	可跨越DB 可跨越物理機器	可跨越表空間,不同的物理屬性 不能跨DB存儲
存儲方式	分布式	集中式
擴展性	Scale?Out(橫向擴展，增加便宜設備)	Scale?Up(升級設備)
可用性	無單點	存在單點(DB數據本身)
價格	低廉	適中，甚至昂貴
應用場景	web?2.0	?

架構演變過程之五Web園或增加更多WebServer

在做完分庫分表這些工作后，數據庫上的壓力已經降到比較低了,這個時候可能到了下一個瓶頸，查看windows的性能計數器發現有大量的阻塞請求，于是可以做Web園或者添加一些webserver服務器。在這個添加webserver服務器的過程，有可能會出現如下幾個問題：

一臺Nginx服務器的軟負載已經無法承擔巨大的web訪問量了，可以用硬件負載解決F5或應用從邏輯上做一定的分類，然后分散到不同的軟負載集群中

原有的一些狀態信息同步、文件共享等方案可能會出現瓶頸，需要進行改進，也許這個時候會根據情況編寫符合網站業務需求的分布式文件系統等；

在做完這些工作后，開始進入一個看似完美的無限伸縮的時代，當網站流量增加時，應對的解決方案就是不斷的添加webserver。

架構演變之六讀寫分離和廉價存儲方案

通過增加web服務器享受了一段快速訪問的幸福后，發現系統又開始變慢了，經過查找，發現數據庫寫入、更新的這些操作的部分數據庫連接的?資源競爭非常激烈，導致了系統變慢，這下怎么辦呢，讀寫分離,訂閱和發布

?

廉價存儲方案Nosql

NoSQL = Not Only SQL?指的是非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。

NoSql數據庫大量應用于微博系統等事務性不強的系統

BigTable

MongoDB?

http://tech.it168.com/topic/2011/10-1/nosqlapp/index.html

架構演變之七進入大型分布式應用時代和廉價服務器群夢想時代

經過上面這個漫長而痛苦的過程，終于再度迎來了完美的時代，不斷的增加webserver就可以支撐越來越高的訪問量了，但是原來部署在webserver上的那個web應用已經非常龐大?了，當多個團隊都開始對其進行改動時，相當的不方便，復用性也相當糟糕，基本上每個團隊都做了或多或少重復的事情，而且部署和維護也是相當的麻煩，因為龐大的應用包在N臺機器上復制、啟動都需要耗費不少的時間，出問題的時候也不是很好查，另外一個更糟糕的狀況是很有可能會出現某個應用上的bug就導?致了全站都不可用，還有其他的像調優不好操作(因為機器上部署的應用什么都要做，根本就無法進行針對性的調優)等因素，根據這樣的分析，開始痛下決心，將?系統根據職責進行拆分，于是一個大型的分布式應用就誕生了，通常，這個步驟需要耗費相當長的時間，因為會碰到很多的挑戰：
1、拆成分布式后需要提供一個高性能、穩定的通信框架，并且需要支持多種不同的通信和遠程調用方式；
2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關系的控制等；
3、如何運維(依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等)好這個龐大的分布式應用。
經過這一步，差不多系統的架構進入相對穩定的階段，同時也能開始采用大量的廉價機器來支撐著巨大的訪問量和數據量，結合這套架構以及這么多次演變過程吸取的經驗來采用其他各種各樣的方法來支撐著越來越高的訪問量。

參考：http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的网站服务架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。