網站架構演化

 

http://www.ha97.com/5095.html

 

說到大型網站，就得先說大型網站的特色：高併發、大流量、高可用、海量數據等。下面就說說大型網站的架構演化過程吧。

 

1. 初始階段的網站架構

            

初始階段都比較簡單，一般一臺服務器就能夠搞定一個網站了，看圖：

2. 應用服務和數據服務分離

        

隨着網站業務的發展，一臺服務器逐漸不能知足需求；這時候就須要將應用和數據分離，如圖：

3. 使用緩存改善網站性能

        

毫無疑問，如今的網站基本上都會使用緩存，即：80%的業務訪問都會集中在20%的數據上。

4. 使用應用服務器集羣改善網站的併發處理能力

         

由於單一應用服務器可以處理的請求鏈接有限，在網站訪問高峯時期，應用服務器會成爲整個網站的瓶頸。所以使用負載均衡處理器勢在必然。經過負載均衡調度服務器，可未來自瀏覽器的訪問請求分發到應用的集羣中的任何一臺服務器上。

 

5. 數據庫讀寫分離

         

當用戶達到必定規模後，數據庫由於負載壓力太高而成爲網站的瓶頸。而目前主流的數據庫都提供主從熱備功能，經過配置兩臺數據庫主從關係，能夠將一臺數據庫的數據更新同步到另外一臺服務器上。網站利用數據庫這一功能實現數據庫讀寫分離，從而改善數據庫負載壓力。

6. 使用反向代理和CDN加上網站相應

       

提升網站的訪問速度，主要手段有使用CDN和反向代理。

      

CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，而反向代理是部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的反向代理，若是反向代理緩存着用戶請求的資源，則直接返回給用戶。

 

 

7. 使用分佈式文件系統和分佈式數據庫系統

    

任何強大的單一服務器都知足不了大型網站持續增加的業務需求。

     

分佈式數據庫時網站數據庫拆分的最後手段，只用在單表數據規模很是大的時候才使用。不到不得已時，網站更經常使用的數據庫拆分手段是業務拆分，將不一樣業務的數據部署在不一樣的物理服務器上。

 

 

8. 使用NoSQL和搜索引擎

       

搜素引擎也基本已經造成如今大型網站必須提供的功能了，網站須要採用一些非關係數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。

 

 

9. 業務拆分

        

大型網站爲了應對日益複雜的業務場景，經過使用分而治之的手段將真個網站業務拆分紅不一樣的產品線。

         

具體到技術上，也會根據產品線話費，將一個網站拆分紅許多不一樣的應用，每一個應用獨立部署維護。應用之間能夠經過超連接創建管理，也能夠經過消息隊列進行數據分發，固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統。

 

10. 分佈式服務

       

因爲每個應用系統都須要執行許多相同的業務操做，好比用戶管理，session管理，那麼能夠將這些公用的業務提取出來，獨立部署。

 

 

每個模式描述了一個在咱們周圍不斷重複發生的問題及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而沒必要作重複工做。

          

所謂網站架構模式即爲了解決大型網站面臨的高併發訪問、海量數據、高可靠運行等一系列問題與挑戰。爲此，在實踐中提出了許多解決方案，以實現網站高性能、高可靠性、易伸縮、可擴展、安全等各類技術架構目標。

 

1. 分層

        

分詞是企業應用系統中最多見的一種架構牧師，將系統在橫向維度上切分紅幾個部分，每一個部分負責一部分相對簡單並比較單一的職責，而後經過上層對下層的依賴和調度組成一個完整的系統。

        

在網站的分層架構中，常見的爲3層，即應用層、服務層、數據層。應用層具體負責業務和視圖的展現；服務層爲應用層提供服務支持；數據庫提供數據存儲訪問服務，如數據庫、緩存、文件、搜索引擎等。

       

分層架構是邏輯上的，在物理部署上，三層架構能夠部署在同一個物理機器上，可是隨着網站業務的發展，必然須要對已經分層的模塊分離部署，即三層結構分別部署在不一樣的服務器上，是網站擁有更多的計算資源以應對愈來愈多的用戶訪問。

      

因此雖然分層架構模式最初的目的是規劃軟件清晰的邏輯結構以便於開發維護，但在網站的發展過程當中，分層結構對網站支持高併發向分佈式方向的發展相當重要。

 

2. 分隔

       

若是說分層是將軟件在橫向方面進行切分，那麼分隔就是在縱向方面對軟件進行切分。

       

網站越大，功能越複雜，服務和數據處理的種類也越多，將這些不一樣的功能和服務分隔開來，包裝成高內聚低耦合的模塊單元，不只有助於軟件的開發維護也便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展能力。

      

大型網站分隔的粒度可能會很小。好比在應用層，將不一樣業務進行分隔，例如將購物、論壇、搜索、廣告分隔成不一樣的應用，有對立的團隊負責，部署在不一樣的服務器上。

 

3. 分佈式

       

對於大型網站，分層和分隔的一個主要目的是爲了切分後的模塊便於分佈式部署，即將不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做。分佈式意味着可使用更多的計算機完一樣的工做，計算機越多，CPU、內存、存儲資源就越多，能過處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。

       

在網站應用中，經常使用的分佈式方案有一下幾種.

       

分佈式應用和服務：將分層和分隔後的應用和服務模塊分佈式部署，能夠改善網站性能和併發性、加快開發和發佈速度、減小數據庫鏈接資源消耗。

       

分佈式靜態資源：網站的靜態資源如js、CSS、Logo圖片等資源對立分佈式部署，並採用獨立的域名，即人們常說的動靜分離。靜態資源分佈式部署能夠減輕應用服務器的負載壓力；經過使用獨立域名加快瀏覽器併發加載的速度。

       

分佈式數據和存儲：大型網站須要處理以P爲單位的海量數據，單臺計算機沒法提供如此大的存儲空間，這些數據庫須要分佈式存儲。

       

分佈式計算：目前網站廣泛使用Hadoop和MapReduce分佈式計算框架進行此類批處理計算，其特色是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分佈式計算。

 

4. 集羣

       

對於用戶訪問集中的模塊須要將獨立部署的服務器集羣化，即多臺服務器部署相同的應用構成一個集羣，經過負載均衡設備共同對外提供服務。

       

服務器集羣可以爲相同的服務提供更多的併發支持，所以當有更多的用戶訪問時，只須要向集羣中加入新的機器便可；另外能夠實現當其中的某臺服務器發生故障時，能夠經過負載均衡的失效轉移機制將請求轉移至集羣中其餘的服務器上，所以能夠提升系統的可用性。

 

5. 緩存

       

緩存目的就是減輕服務器的計算，使數據直接返回給用戶。在如今的軟件設計中，緩存已經無處不在。具體實現有CDN、反向代理、本地緩存、分佈式緩存等。

       

使用緩存有兩個條件：訪問數據熱點不均衡，即某些頻繁訪問的數據須要放在緩存中；數據在某個時間段內有效，不過很快過時，否在會由於數據過時而髒讀，影響數據的正確性。

 

6. 異步

      

使用異步，業務之間的消息傳遞不是同步調用，而是將一個業務操做分紅多個階段，每一個階段之間經過共享數據的方法異步執行進行協做。

      

具體實現則在單一服務器內部可用經過多線程共享內存對了的方式處理；在分佈式系統中可用經過分佈式消息隊列來實現異步。

      

異步架構的典型就是生產者消費者方式，二者不存在直接調用。

 

7. 冗餘

      

網站須要7×24小時連續運行，那麼就得有相應的冗餘機制，以防某臺機器宕掉時沒法訪問，而冗餘則能夠經過部署至少兩臺服務器構成一個集羣實現服務高可用。數據庫除了按期備份還須要實現冷熱備份。甚至能夠在全球範圍內部署災備數據中心。

 

8. 自動化

      

具體有自動化發佈過程，自動化代碼管理、自動化測試、自動化安全檢測、自動化部署、自動化監控、自動化報警、自動化失效轉移、自動化失效恢復等。

 

9. 安全

      

網站在安全架構方面有許多模式：經過密碼和手機校驗碼進行身份認證；登陸、交易須要對網絡通訊進行加密；爲了防止機器人程序濫用資源，須要使用驗證碼進行識別；對常見的XSS攻擊、SQL注入須要編碼轉換；垃圾信息須要過濾等。

 

 

所謂架構，一種通俗的說法就是「最高層次的規劃，難以改變的決定」，這些規劃和決定奠基了事物將來發展的方向和最終的藍圖。

       

而軟件架構即「有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各方面的設計」。通常來講軟件架構須要關注性能、可用性、伸縮性、擴展性和安全性這5個架構要素。

 

1. 性能

      

性能是網站架構設計的一個重要方面，任何軟件架構設計方案都必須考慮可能帶來的性能問題。也正由於性能問題幾乎無處不在，因此優化網站性能的手段也很是多：

     

瀏覽器端：能夠經過瀏覽器緩存、頁面壓縮傳輸、合理佈局頁面、減小Cookie傳輸等手段，甚至可使用CDN加速功能。

     

應用服務器端：可使用服務器本地緩存和分佈式緩存，也能夠經過異步操做方式來加快響應，在高併發請求的狀況下，能夠將多臺應用服務器組成一個集羣共同對外服務，提升總體處理能力，改善性能。

     

數據庫服務器端：可用使用索引、緩存、SQL性能優化等手段，還可使用NoSQL數據庫來優化數據模型、存儲結構等。

     

衡量網站性能有一系列指標，重要的有響應時間、TPS、系統性能計數器等，經過這些指標以肯定系統設計是否達到目標。

 

2. 可用性

     

可用性即可以不間斷提供服務的時間。幾乎全部網站都承諾7×24小時可用，但事實上任何網站都不可能達到徹底的7×24，總會有一些故障時間，扣除這些故障時間，就是網站的可用時間。一些大型網站能夠作到4個9以上的可用性，也就是99.99%。

    

網站高可用的主要手段就是冗餘，應用部署在多臺服務器上同時提供服務，數據存儲在多臺服務器上相互備份，任何一臺服務器都不會影響應用的總體能夠，一般的實現手段即把多臺服務器經過負載均衡設備組成一個集羣。

    

衡量一個系統架構設計是否知足高可用的目標，就是假設系統中任何一臺或者多臺服務器宕機時，以及出現各類不可預期的問題時，系統總體是否依然可用。

 

3. 伸縮性

       

大型網站須要面對大量用戶的高併發訪問和存儲海量數據，網站經過集羣的方式將多臺服務器組成一個總體共同提供服務。所謂伸縮性是指經過不斷向集羣中加入服務器的手段來緩解不斷總體上市用戶併發訪問壓力和不斷增加的數據存儲需求。

       

衡量架構伸縮性的主要標準就是是否可用多臺服務器構建集羣，是否容易向集羣中添加新的服務器。加入新的服務器後是否能夠提供和原來的服務器無差異的服務。集羣中可容納的總服務器數量是否有限制。

 

4. 擴展性

        

不一樣於其餘架構要素主要關注非功能性需求，網站的擴展性架構直接關注網站的功能需求。網站快速發展，功能不斷擴展，如何設計網站的架構使其可以快速響應需求變化，是網站可擴展架構的主要目標。

        

衡量網站架構擴展性好壞的主要標準就是在網站增長新的業務產品時，是否能夠實現對現有產品透明無影響，不一樣產品之間是否不多耦合等。

        

網站可擴展架構的主要手段是事件驅動架構和分佈式服務。

        

事件驅動一般利用消息隊列實現，經過這種方式將消息生產和處理邏輯分隔開。

        

服務器服務則是將業務和可複用服務分離開來，經過分佈式服務框架調用。新增長產品可用經過調用可複用的服務來實現自身的業務邏輯，而對現有產品沒有任何影響。

 

5. 安全性

      

互聯網是開發的，任何人在任何地方均可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。

      

衡量網站安全架構的標準就是針對現存和潛在的各類攻擊和竊密手段，是否有可靠的應對策略。

 

網站性能是客觀的指標，能夠具體體現到響應時間、吞吐量、併發數、性能計數器等技術指標。

 

1. 性能測試指標

 

1.1 響應時間

      

指應用執行一個操做須要的時間，指從發出請求到最後收到響應數據所須要的時間。以下列出了系統經常使用的操做響應時間表。

 

操做	響應時間
打開一個網站	幾秒
數據庫查詢一條記錄（有索引）	十幾毫秒
機械磁盤一次尋址定位	4毫秒
從機械磁盤順序讀取1M數據	2毫秒
從SSD磁盤順序讀取1M數據	0.3毫秒
從遠程分佈式換成Redis讀取一個數據	0.5毫秒
從內存讀取1M數據	十幾微妙
Java程序本地方法調用	幾微妙
網絡傳輸2Kb數據	1微妙

 

實踐中計算響應時間一般是經過平均時間計算的平均值。

 

1.2 併發數

    

指系統可以同時處理的請求的數目，這個數字也反映了系統的負載性能。對於網站而言，併發數指網站用戶同時提交請求的用戶數目。
    

網站系統用戶數>網站在線用戶數>網站併發用戶數

 

1.3 吞吐量

 

指單位時間內系統處理的請求數量，體現系統的總體處理能力。對於網站，可用「請求數/秒」或「頁面數/秒」或「訪問人數/天」或「處理業務數/小時」等來衡量。
 

TPS(每秒事物數)是吞吐量的一個經常使用量化指標。刺蝟還有HPS（每秒HTTP請求數）、QPS(每秒查詢數)。

 

1.4 性能計數器

 

指操做系統的一些數據指標如System load(系統負載)，CPU使用率、內存使用率、磁盤等使用狀況。

 

2. 性能優化策略

 

根據網站分層架構，可分爲Web前端性能優化、應用服務器性能優化、存儲服務器性能優化。

 

2.1 Web前端優化

 

2.1.1 瀏覽器訪問優化

 

• 減小HTTP請求數,主要可經過合併CSS，JavaScript、圖片。

• 使用瀏覽器端緩存。在某些時候，靜態資源文件編寫須要及時應用到客戶端瀏覽器，這種狀況下，可經過改變文件名來實現。

• 啓用頁面壓縮，文本文件的壓縮效率可達80%以上。

• CSS放在頁面最上面，JavaScript放在頁面最下面

• 減小Cookie傳輸。能夠考慮使用獨立域名來發送Cookie等。

 

2.1.2 CDN加速

 

CDN的本質仍然是一個緩存，只是部署在離用戶最近的服務器上，通常緩存的都是靜態資源。

 

2.1.3 反向代理

 

除了可以保護網站安全的做用以及負載均衡的做用外，反向代理還可以提供緩存做用(動態資源)。

 

 

 

2.2 應用服務器性能優化

 

應用服務器就是處理網站業務的服務器，網站的業務代碼都部署在這裏，主要優化手段有緩存、集羣、異步等。

 

2.2.1 分佈式緩存

 

緩存主要用來存放哪些讀寫比很高、不多變化的數據。
 

分佈式緩存指緩存部署在多個服務器組成的集羣中，以集羣方式提供緩存服務，其具體架構有兩種，一種是以JBoss Cache僞代碼的須要更新同步的分佈式緩存， 一種是以Memcached爲表明的不互相通訊的分佈式緩存。

 

Jboss Cache 的分佈式緩存在集羣中的全部服務器中保存相同的緩存數據，當某臺服務器有緩存更新的時候，會通知集羣中其餘機器跟新緩存數據。優勢是應用程序能夠 從本地快速的獲取緩存數據，但當集羣規模較大的時候，緩存更新信息須要經過到集羣全部機器，其代價可想而知。

大型網站須要的緩存數據通常都很大，可能會有TB的內存佔用，這時候就的使用Memcached，是一中互不通訊的架構，每臺存儲的緩存數據能夠不同。

 

2.2.2 異步操做

 

爲了改善網站的擴展性，可使用消息隊列將調用異步化。

 

2.2.3 使用集羣

 

在網站高併發訪問的狀況下，使用負載均衡技術爲一個應用構建一個由多臺服務器組成的集羣，將併發訪問請求分發到多臺服務器上處理。 

 

 

2.2.4 代碼優化

 

代碼優化主要涉及多線程、資源複用（對象池或單例）、數據結構和垃圾回收。

 

2.3 存儲性能優化

 

能夠考慮使用分佈式存儲、openfiler、磁盤陣列、HDFS（Hadoop）。

 

網站的可用性（Avaliability）描述網站可有效訪問的特性。

 

1. 網站可用性的度量與考覈

      

網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點
      

網站年度不可用時間=（1-網站不可用時間/年度時間）× 100%

 

可用性指標時網站架構設計的重要指標，對外是服務承諾，對內是考覈指標，具體到每一個工程師，更多的是使用故障分。
      

所謂故障分是指對網站故障進行分類加權計算故障責任的方法。以下是個案例：

 

分類	描述	權重
事故級故障	嚴重故障，網站總體不可用	100
A類故障	網站訪問不暢或核心功能不可用	20
B類故障	非核心功能不可用，或核心功能少數用戶不能訪問	5
C類故障	其餘故障	1

 

故障分的計算公式爲：

 

故障分=故障時間（分鐘）* 故障權重

 

2. 網站的高可用架構

 

一個典型的網站設計一般遵循以下圖所示的基本分層模型。

在負載的大型網站架構中，劃分的粒度會更小，更詳細，但一般仍是可以把這些服務器劃分到這三層中。

對於應用層的服務器一般爲了應對高併發的訪問請求，會經過負載均衡設備將一組服務器組成一個集羣共同 對外提供服務，當負載均衡設備經過心跳檢測到某臺服務器不可用時，就將其從集羣列表中提出，並將請求分發到集羣中其餘 可用的服務器上，是整個集羣保存可用，從而實現應用高可用。

        

位於服務層的服務器狀況和應用層相似，也是經過集羣方式實現高可用，只是這些服務器被應用層經過分佈式服務調用框架訪問， 分佈式服務調度框架會在應用層客戶端中實現負載均衡功能。

        

位於數據層的服務器狀況比較特殊，數據服務器上存儲着數據，爲了保證數據不丟失，數據訪問服務不中斷，須要在數據寫入時進行數據同步複製，將數據寫入多臺服務器上，實現數據冗餘備份。
        

網站升級的頻率通常都很是高，每次網站發佈都須要關閉服務，從新啓動系統，至關於服務器宕機。所以網站的可用性架構還須要考慮到網站升級 發佈引發的宕機。

 

3. 高可用的應用

         

應用層主要處理網站應用的業務邏輯，也稱爲業務邏輯層，應用的一個顯著特色就是應用的無狀態行，所以實現負載均衡相對簡單一點。
         

Web應用中將這些屢次請求的上下文稱爲回話（Session），在單機狀況下，session可部署在服務器上的Web容器上管理。在使用負載均衡 的集羣環境中，因爲負載均衡服務器可能會將請求分發到集羣任何一臺應用服務器上，因此保證每次請求依然可以得到正確的session比單機 時要複雜的多。在集羣環境下，session管理主要有  如下手段。

          

3.1 Session複製

 

Session複製是早期企業應用系統使用較多的一種服務器集羣Session管理機制。應用服務器開啓Web容器的Session複製功能，在集羣中幾臺服務器之間同步Session對象，是每臺服務器上都保存全部用戶的Session信息。

        

這種方案雖然簡單，從本機讀取Session信息也很快，但當集羣規模比較大的時候會佔用服務器和網站的大量資源，在大量用戶訪問的狀況下，甚至會出現內存不夠Session使用的狀況。

         

3.2 Session綁定

        

Session綁定能夠利用負載均衡的源地址Hash算法實現，負載均衡服務器老是未來源於同一IP的請求分發到同一臺服務器上。這樣在整個回話期間，用戶全部的請求都在同一天服務器上處理，即Session綁定到某臺特定的服務器上，保證Session總能在這臺服務器上獲取，這種方法有成爲回話粘滯。

        

3.3 利用Cookie記錄Session

        

一種管理Session的方式是將Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發送給服務器，服務器處理完請求後再將修改後的Session響應給客戶端。

       

3.4 Session服務器

        

Session服務器，即把session的管理獨立部署在某一臺機器上，Web服務器不保存用戶Session信息，每次都去Session服務器取數據。

        

這種解決方案事實上是將應用服務器的狀態分離，分爲無狀態的應用服務器和有狀態的Session服務器。對於有狀態的Session服務器，一種比較簡單的方式是利用分佈式緩存、數據庫等。

 

4. 高可用的服務

      

可複用的服務模塊爲業務產品提供基礎公共服務，大型網站中這些服務一般都獨立分佈式部署，被具體應用遠程調用。可複用的服務和應用同樣，是無狀態的，所以可使用相似負載均衡的失效轉移策略實效高可用的服務。

      

除此以外，在實踐中，還有一些幾點高可用的服務策略。

 

• 分級管理

• 超時設置

• 異步調用

• 服務降級，網站高峯期間，能夠關閉一些不重要的服務，如評論。

 

5. 高可用的數據

      

保證數據存儲高可用的手段主要是數據備份和失效轉移機制。

      

CAP原理：即數據持久性、數據可訪問性、數據一致性。

 

6. 高可用的網站質量保證

     

這裏主要說下網站發佈流程吧。看圖便可：

7. 網站運行監控

    

 「不容許沒有監控的系統上線」。網站運行監控對於網站運維和架構設計優化相當重要，運維沒有監控的網站，猶如駕駛沒有儀表的飛機。

     

具體到監控哪些數據，主要有：

      

• 用戶行爲日誌收集（服務器端和瀏覽器端）

• 服務器性能監控（CPU、內存等）

• 運行數據監控（緩存命中率、平均響應延遲時間、每分鐘發送郵件數目、待處理的任務總數等）

 

監控數據採集後，除了用做系統性能評估、集羣規模伸縮性預測等，還能夠根據實時監控數據進行風險預警，並對服務器進行失效轉移，自動負載調整，最大化利用集羣全部機器的資源。

 

網站系統的伸縮性架構最重要的技術手段就是使用服務器集羣功能，經過不斷地向集羣中添加服務器來加強整個集羣的處理能力。「伸」即網站的規模和服務器的規模老是在不斷擴大。

 

1. 網站架構的伸縮性設計

 

網站的伸縮性設計能夠分紅兩類，一類是根據功能進行物理分離實現伸縮，一類是單一功能經過集羣實現伸縮。前者是不一樣的服務器部署不一樣的服務，提供不一樣的 功能；後者是集羣內的多臺服務器部署相同的服務，提供相關的功能。

 

1.1 不一樣功能進行物理分離實現伸縮

縱向分離：即分層後分離，將業務處理流程上的不一樣部分分離部署，實現系統伸縮性。

橫向分離：即分割業務後分離，將不一樣的業務模塊分離部署，實現系統伸縮性。

1.2 單一功能經過你集羣規模實現伸縮

       

當一頭牛拉不動車的時候，不要去尋找一頭更強壯的牛，而是用兩頭牛來拉車。
      

集羣伸縮性又分爲應用服務器集羣伸縮性和數據服務器集羣伸縮性。數據服務器集羣也可分爲緩存數據服務器集羣和存儲數據服務器集羣。

 

 

2. 應用服務器集羣的伸縮性設計

        

所謂應用服務器的伸縮性即：HTTP請求分發裝置能夠感知或者能夠配置集羣的服務器數量，能夠及時發現集羣中新上線或下線的服務器，並能向新上線的服務器分發請求 ，中止向已下線的服務器分發請求。這個HTTP請求分發裝置被稱爲負載均衡服務器。
       

負載均衡是網站必不可少的基礎技術手段，不但能夠實現網站的伸縮性，同時還改善網站的可用性，可謂網站的殺手鐗之一。具體的技術實現也多種多樣，從硬件實現到軟件實現， 從商業產品到開源，應有盡有，但實現負載均衡的基礎技術不外如下幾種。

 

2.1 HTTP重定向負載均衡

 

HTTP重定向服務器是一臺普通的應用服務器，其惟一的功能就是根據用戶的HTTP請求計算一臺真實的服務器地址，並將真實的服務器地址寫入HTTP重定向響應中（響應狀態嗎302）返回給瀏覽器，而後瀏覽器再自動請求真實的服務器。

        

這種負載均衡方案的優勢是比較簡單，缺點是瀏覽器須要每次請求兩次服務器才能拿完成一次訪問，性能較差；使用HTTP302響應嗎重定向，多是搜索引擎判斷爲SEO做弊，下降搜索排名。重定向服務器自身的處理能力有可能成爲瓶頸。所以這種方案在實際使用中並不見多。

 

2.2 DNS域名解析負載均衡

 

利用DNS處理域名解析請求的同時進行負載均衡是另外一種經常使用的方案。在DNS服務器中配置多個A記錄，如：www.mysite.com IN A 114.100.80.一、www.mysite.com IN A 114.100.80.二、www.mysite.com IN A 114.100.80.3.

      

每次域名解析請求都會根據負載均衡算法計算一個不一樣的IP地址返回，這樣A記錄中配置的多個服務器就構成一個集羣，並能夠實現負載均衡。

      

DNS域名解析負載均衡的優勢是將負載均衡工做交給DNS，省略掉了網絡管理的麻煩，缺點就是DNS可能緩存A記錄，不受網站控制。

     

事實上，大型網站老是部分使用DNS域名解析，做爲第一級負載均衡手段，而後再在內部作第二級負載均衡。 

 

2.3 反向代理負載均衡

      

前面咱們已經講過，反向代理能夠緩存資源，改善網站性能，事實上，反向代理業能夠作負載均衡，如圖所示。

 

因爲反向代理服務器轉發請求在HTTP協議層面，所以也叫應用層負載均衡。優勢是部署簡單，缺點是可能成功系統的瓶頸。

 

2.4 IP負載均衡

       

IP負載均衡：即在網絡層經過修改請求目標地址進行負載均衡。

 

用戶請求數據包到達負載均衡服務器後，負載均衡服務器在操做系統內核進行獲取網絡數據包，根據負載均衡算法計算獲得一臺真實的WEB服務器地址，而後將數據包的IP地址修改成真實的WEB服務器地址，不須要經過用戶進程處理。真實的WEB服務器處理完畢後，相應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改成自身的IP地址發送給用戶瀏覽器。

       

這裏的關鍵在於真實WEB服務器相應數據包如何返回給負載均衡服務器，一種是負載均衡服務器在修改目的IP地址的同時修改源地址，將數據包源地址改成自身的IP，即源地址轉換（SNAT），另外一種方案是將負載均衡服務器同時做爲真實物理服務器的網關服務器，這樣全部的數據都會到達負載均衡服務器。

       

IP負載均衡在內核進程完成數據分發，較反向代理均衡有更好的處理性能。但因爲全部請求響應的數據包都須要通過負載均衡服務器，所以負載均衡的網卡帶寬成爲系統的瓶頸。

 

2.5 數據鏈路層負載均衡

        

顧名思義：數據鏈路層負載均衡是指在通訊協議的數據鏈路層修改mac地址進行負載均衡，以下圖：

 

        

這種數據傳輸方式又稱做三角傳輸模式，負載均衡數據分發過程當中不修改IP地址，只修改目的的mac地址，經過配置真實物理服務器集羣全部機器虛擬IP和負載均衡服務器IP地址同樣，從而達到負載均衡，這種負載均衡方式又稱爲直接路由方式（DR）。

        

在上圖中，用戶請求到達負載均衡服務器後，負載均衡服務器將請求數據的目的mac地址修改成真是WEB服務器的mac地址，並不修改數據包目標IP地址，所以數據能夠正常到達目標WEB服務器，該服務器在處理完數據後能夠通過網管服務器而不是負載均衡服務器直接到達用戶瀏覽器。

        

使用三角傳輸模式的鏈路層負載均衡是目前大型網站所使用的最廣的一種負載均衡手段。在Linux平臺上最好的鏈路層負載均衡開源產品是LVS(linux virtual server)。

 

2.6 負載均衡算法

 

負載均衡服務器的實現能夠分紅兩個部分：

 

• 根據負載均衡算法和WEB服務器列表計算獲得集羣中一臺WEB服務器的地址；

• 將請求數據發送到改地址對應的WEB服務器上。

 

經常使用的負載均衡算法以下幾種：

 

• 輪詢：即將請求依次分發到每臺應用服務器上。

• 加權輪詢：根據應用服務器硬件性能狀況，在輪詢的基礎上，安裝配置的權重將請求分發到每一個服務器。

• 隨機：將請求隨機分配到各個應用服務器。

• 最少鏈接：記錄每一個服務器正在處理的鏈接數，將新到的請求分發到最少鏈接的服務器上。

• 原地址散列：根據請求來源的IP地址進行Hash計算，獲得應用服務器，這樣來自同一個IP地址請求總在同一個服務器上處理。

 

3. 分佈式緩存集羣的伸縮性設計

         

分佈式緩存服務器集羣中不一樣服務器中緩存的數據不相同，緩存訪問請求不可用在緩存服務器集羣中的任意一臺處理，必須先找到緩存有須要數據的服務器，而後才能訪問。 這個特色會嚴重製約分佈式緩存集羣的伸縮性設計，由於新上線的緩存服務器沒有緩存數據，而已下線的緩存服務器還緩存着網站的許多熱點數據。
 

分佈式緩存集羣伸縮性設計的最主要目標即：必須讓新上線的緩存服務器對整個分佈式緩存集羣影響最小，也就是說新加入緩存服務器後應使整個緩存服務器集羣中已經緩存的數據 儘量還被訪問到。

 

3.1 memcached分佈式緩存集羣訪問模型

3.2 分佈式緩存的一致性Hash算法

        

一致性hash算法經過一個叫作一致性Hash環的數據結構實現KEY到緩存服務器的Hash映射，以下圖：

若是使用上面數據結構的話，那麼當新添加一臺緩存服務器時，只是影響到了其中一臺緩存服務器，其餘兩頭緩存服務器的壓力並無獲得緩解，所以此方案仍是存在問題。 一種替代的方案就是增長一個虛擬層，即把每臺緩存服務器虛擬爲一組服務器（好比3個虛擬網元）平均放到上面的環裏面。這樣當新增長緩存服務器時，把新增長的虛擬網元平均分配 到環中，這樣就能緩解每臺緩存服務器，達到分佈式緩存集羣高伸縮性。

 

4. 數據存儲服務器集羣的伸縮性設計

        

和緩存服務器集羣的伸縮性設計不一樣，數據存儲服務器集羣的伸縮性對數據的持久性和可用性提出了更高的要求。具體來講，又可分爲關係數據庫集羣的伸縮性設計和NoSQL數據庫的伸縮性設計。

 

4.1 關係數據庫集羣的伸縮性設計

       

主要的關係數據庫都支持數據複製功能，使用這個功能能夠對數據庫進行簡單伸縮。
       

另外除了利用數據庫主從讀寫分離外，也能夠利用業務分隔模式使不一樣業務的數據表部署在不一樣的數據庫集羣上，即俗稱的數據分庫。可是這種方式的制約條件時跨庫不能進行join操做。
       

在大型網站的實際應用中，即便使用了分庫和主從複製，對一些單表數據任然很大的表還須要進行分片，將一張表拆開分別存儲在多個數據庫中。
       

目前支持分佈式數據分片的關係數據庫產品主要有開源的Amoeba和Cobar（阿里巴巴），下圖爲Cobar部署模型。

 

Cobar是一個分佈式關係數據庫訪問代理，介於應用服務器和數據庫服務器之間。應用程序經過JDBC驅動訪問Cobar集羣，Cobar服務器根據SQL和分庫規則分解SQL，分發到MySQL集羣不一樣 的數據庫實例上執行（每一個MySQL實例都部署爲主/從結構，保證數據高可用）。
       

Cobar系統組件模型以下圖：

 

       

前端通訊模塊負責和應用程序通訊，接搜到SQL請求（select * from users where userid in (12,22,23)）後轉交給SQL解析模塊，SQL解析模塊解析得到SQL中的路由規則查詢條件（userid in （12,22,23））再轉交給 SQL路由模塊，SQL路由模塊根據路由規則配置（userid爲偶數路由至數據庫A，奇數則路由至數據庫B）將應用程序提交的SQL分解成兩條SQL(select * from users where userid in (12,22)；select * from users where userid in (23))轉交給SQL執行代理模塊，發送至數據庫A和數據庫B分別執行。 數據庫A和數據庫B的執行結果返回至SQL執行模塊，經過結果合併模塊將兩個返回結果集合併成一個結果集，最終返回該應用程序，完成在分佈式關係數據庫中的一次訪問請求。

 

Cobar的伸縮有兩點：Cobar服務器集羣的伸縮和MySQL服務器集羣的伸縮。
       

Cobar服務器能夠看作是無狀態的應用服務器，所以其集羣伸縮能夠簡單實用負載均衡的手段實現。而MySQL中存儲着數據，要保證集羣擴容後數據一致負載均衡，必需要作數據遷移，以下圖（利用數據同步功能進行數據遷移）。

4.2 NoSQL數據庫的伸縮設計

 

NoSQL主要是指非關係的、分佈式的數據庫設計模式。通常而言，NoSQL數據庫產品都放棄了關係數據庫的兩大重要基礎：以關係代數爲基礎的結構化查詢語言（SQL）和事物一致性保證（ACID），而強化了高可用性和可伸縮性。目前應用最普遍的是Apache Hbase。