云計算大數(shù)據(jù)：構(gòu)建高性能Web站點

更新時間:2017-12-19 來源:黑馬程序員瀏覽量:

交流目標(biāo)：

1、熟悉網(wǎng)站演進過程中的各個階段及技術(shù)方案(重要)

2、熟悉大型網(wǎng)站中緩存的應(yīng)用

3、熟悉常見負載均衡的手段

4、熟悉內(nèi)存數(shù)據(jù)庫Redis

http://item.jd.com/1027067140.html

http://item.jd.com/11449803.html

大型網(wǎng)站及其架構(gòu)的演進過程

1、什么是大型網(wǎng)站

訪問量大、數(shù)據(jù)量大、業(yè)務(wù)復(fù)雜度高、分布式

網(wǎng)站是用來訪問的，訪問量大就應(yīng)該是大型網(wǎng)站?!

大量的數(shù)據(jù)，或者說海量數(shù)據(jù)。從數(shù)據(jù)中分析業(yè)務(wù)和系統(tǒng)的復(fù)雜性。

總結(jié)：

那么要支持海量的數(shù)據(jù)和非常高的并發(fā)量，那么他可能是一個分布式系統(tǒng)。

2、網(wǎng)站的架構(gòu)演進

2.1、構(gòu)建網(wǎng)站技術(shù)手段

發(fā)布一個網(wǎng)站需要哪些要素?

一個物理機、一個WEB容器、一個數(shù)據(jù)庫

開發(fā)網(wǎng)站的技術(shù)手段?

SpringMVC/Spring/Ibatis/JDBC/Mysql

2.2、業(yè)務(wù)系統(tǒng)-電商網(wǎng)站

l 各個功能模塊通過JVM內(nèi)部方法調(diào)用來進行交付

l 訪問數(shù)據(jù)庫通過JDBC的方式鏈接

2.3、單機負載告警、數(shù)據(jù)庫與應(yīng)用分離

l 隨著業(yè)務(wù)量的發(fā)展，單臺物理機不能支撐。

l 重新購置一臺物理機，將數(shù)據(jù)庫服務(wù)器遷移出去。

2.4、應(yīng)用服務(wù)器負載告警、如何讓應(yīng)用服務(wù)器走向集群

l 應(yīng)用服務(wù)器壓力變大，從一臺變成兩臺。

l 他們都依賴底層數(shù)據(jù)庫對外提供服務(wù)。

l 應(yīng)用負載均衡一般使用Nginx或者apache

問題：

1、用戶的請求應(yīng)該打在哪臺應(yīng)用服務(wù)器上?(負載均衡服務(wù))

2、 Sesssion共享的問題

解決：

1、什么是session?

在會話開始時，HTTP協(xié)議的會話機制分配一個唯一的會話標(biāo)志(SessionId)，通過Cookie把這個標(biāo)志告訴瀏覽器，以后每次請求的時候瀏覽器都會帶上這個標(biāo)志來告訴Web服務(wù)器請求是屬于哪個會話的。(比如保持登陸狀態(tài)、購物車數(shù)據(jù))

2、為什么有session共享的問題?

用戶通過負載均衡的方式，隨機訪問到服務(wù)器A，sessionId就會創(chuàng)建到A服務(wù)器上，如果不做處理就不能保證接下來的每次請求都落在A服務(wù)器上。

方法一：讓同樣的seesionId每次都打在一臺服務(wù)器上。(宕機怎么辦?)

方法二：session replication 共享

方法三：使用cookies保存session中的信息

2.5、數(shù)據(jù)庫壓力變大、讀寫分離

l 寫操作主要走主庫，事物中的查詢也要走主庫。

l 搜索引擎也是一個讀庫

1、搜索一個商品的名稱，like

2、根據(jù)被搜索的數(shù)據(jù)來創(chuàng)建索引(被搜索的數(shù)據(jù)變化時，索引也變化)

搜索引擎提供了站內(nèi)搜索的某些場景讀的問題，提供了更好的查詢效果。

2.6、彌補關(guān)系型數(shù)據(jù)庫的不足，引入分布式存儲系統(tǒng)(Redis)

分布式文件系統(tǒng)、分布式Key-Value系統(tǒng)和分布式數(shù)據(jù)庫

2.7、讀寫分離后數(shù)據(jù)庫又遇到瓶頸

數(shù)據(jù)拆分有兩種方式，一個是垂直拆分，一個是水平拆分。垂直拆分就是把一個數(shù)據(jù)庫中不同業(yè)務(wù)單的數(shù)據(jù)分到不同的數(shù)據(jù)庫里面，水平拆分是根據(jù)一定的規(guī)則把同一業(yè)務(wù)單元的數(shù)據(jù)拆分到多個數(shù)據(jù)庫中。

2.7.1、專庫專用，垂直拆分

垂直拆分帶來的影響：

l 一些join操作會變得比較困難，因為數(shù)據(jù)可能已經(jīng)在兩個數(shù)據(jù)庫中了。

需要應(yīng)用或者其他方案解決

2.7.2、表中的數(shù)據(jù)量比較大，水平拆分

水平拆分帶來的影響：

l 訪問用戶信息的應(yīng)用系統(tǒng)需要解決sql路由的問題

l 主鍵的處理也會不同，不能依靠數(shù)據(jù)庫的自增長序列了

l 查詢分頁的問題

l 包含垂直拆分的影響

2.8、分庫分表之后，應(yīng)用面對新的挑戰(zhàn)-服務(wù)化

前面所講的讀寫分離、分布式存儲、數(shù)據(jù)分庫分表都是在解決數(shù)據(jù)方面的問題。

隨著應(yīng)用的的發(fā)展，應(yīng)用的功能會越來越多，應(yīng)用越來越大。我們需要考慮不讓應(yīng)用持續(xù)變大，就需要把應(yīng)用拆開。

將應(yīng)用拆分開來。

1、按照業(yè)務(wù)的特性把應(yīng)用拆分，(用戶系統(tǒng)、商品系統(tǒng)，訂單系統(tǒng))

2、按照功能進行拆分，(用戶注冊系統(tǒng)、用戶登陸系統(tǒng)、用戶信息系統(tǒng)、商品展示系統(tǒng)、商品管理系統(tǒng)……)

服務(wù)化之后，涉及到應(yīng)用與應(yīng)用之間的通信。即進程與進程間的通信。

遠程過程調(diào)用(RPC、Netty等)

3、分布式網(wǎng)站介紹

3.1、分布式網(wǎng)站的整體結(jié)構(gòu)

在分布式網(wǎng)站中，我們會將web服務(wù)器和數(shù)據(jù)庫服務(wù)器做整體的規(guī)劃，并非采用某一臺機器做web服務(wù)器或者數(shù)據(jù)庫服務(wù)器，而是采用集群的架構(gòu)。

3.2、分布式網(wǎng)站中的服務(wù)化框架

在分布式網(wǎng)站中，會出現(xiàn)很多為了負載均衡和failover做支持而出現(xiàn)的框架，還有為項目解耦而出現(xiàn)的大量的RPC框架，例如做主備的keepalived、做反向代理的nginx、做負載均衡的lvs、做RPC的dubbo、netty、thrift等等。

Nginx是一個自由、開源、高性能及輕量級的HTTP服務(wù)器及反轉(zhuǎn)代理服務(wù)器。Nginx以其高性能、穩(wěn)定、功能豐富、配置簡單及占用系統(tǒng)資源少而著稱。

Nginx 超越 Apache 的高性能和穩(wěn)定性，使得國內(nèi)使用 Nginx 作為 Web 服務(wù)器的網(wǎng)站也越來越多.

Keepalived的作用是檢測web服務(wù)器的狀態(tài)，如果有一臺web服務(wù)器死機，或工作出現(xiàn)故障，Keepalived將檢測到，并將有故障的web服務(wù)器從系統(tǒng)中剔除，當(dāng)web服務(wù)器工作正常后Keepalived自動將web服務(wù)器加入到服務(wù)器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復(fù)故障的web服務(wù)器。

LVS的英文全稱是Linux Virtual Server，即Linux虛擬服務(wù)器。

這些框架會在接下來的學(xué)習(xí)中一一涉獵。

RPC(Remote Procedure Call Protocol)：遠程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

RPC采用客戶機/服務(wù)器模式。請求程序就是一個客戶機，而服務(wù)提供程序就是一個服務(wù)器。首先，客戶機調(diào)用進程發(fā)送一個有進程參數(shù)的調(diào)用信息到服務(wù)進程，然后等待應(yīng)答信息。在服務(wù)器端，進程保持睡眠狀態(tài)直到調(diào)用信息的到達為止。當(dāng)一個調(diào)用信息到達，服務(wù)器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個調(diào)用信息，最后，客戶端調(diào)用進程接收答復(fù)信息，獲得進程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進行。

3.3、分布式網(wǎng)站中的消息機制

在分布式的網(wǎng)站中，消息機制不可或缺，消息機制的出現(xiàn)不僅為項目的解耦做了不可磨滅的共現(xiàn)，也為消息的傳遞提供了另一種解決途徑。

在常用的消息機制中，ActiveMQ，RabbitMQ等簡單的基于JMS規(guī)范的消息機制被廣泛應(yīng)用，而最近幾年，一種非JMS的消息機制也在互聯(lián)網(wǎng)市場上崛起，名為kafka。

kafka在互聯(lián)網(wǎng)中最為一種非JMS規(guī)范的消息機制，應(yīng)用越來越廣，此外，在大數(shù)據(jù)的生態(tài)圈里，kafka也有一席之地。kafka和flume、storm的結(jié)合是時下最流行的流式計算框架之一。

緩存篇

為什么要緩存?

減少數(shù)據(jù)庫訪問(減少文件IO操作)

1.1、動態(tài)內(nèi)容緩存

動態(tài)內(nèi)容緩存

將動態(tài)內(nèi)容的HTML輸出結(jié)果緩存起來(頁面緩存)，在隨后的一段時間內(nèi)，當(dāng)有用戶訪問時變跳過重復(fù)的動態(tài)內(nèi)容計算而直接輸出。

緩存信息可以保存在文件系統(tǒng)中，也可以保存在內(nèi)存中。

需要尋找和判斷是否過期。需要更新緩存。

動態(tài)內(nèi)容緩存技術(shù) CSI,SSI,ESI介紹 http://my.oschina.net/coldlemon/blog/341269

動態(tài)內(nèi)容靜態(tài)化

動態(tài)內(nèi)容緩存，雖然可以避免重復(fù)的計算，但是每次還需要調(diào)用動態(tài)腳本的解釋器來判斷緩存是否過期以及如何讀取緩存，消耗了不少時間。

直接將內(nèi)容生成HTML文件，做成靜態(tài)頁面，返回給瀏覽器。

不是所有的內(nèi)容都能做成HTML,該技術(shù)主要使用在CMS等內(nèi)容管理系統(tǒng)上。

局部緩存

對頁面靜態(tài)資源生成HTML，動態(tài)內(nèi)容使用異步加載(ajax)的技術(shù)。

目前該技術(shù)使用在主流的電商網(wǎng)站中。

1.2、瀏覽器緩存

對于一些CSS樣式、圖片、腳本等靜態(tài)資源，告知瀏覽器緩存起來，不要重復(fù)請求。

瀏覽器一般會在用戶的文件系統(tǒng)中創(chuàng)建一個目錄，用戶存放緩存文件，并給每個緩存文件上一些必要的標(biāo)記，比如過期時間等。

IE保存在磁盤，火狐在使用磁盤的同時也使用了內(nèi)存，將命中率較高的緩存內(nèi)容保存在內(nèi)存。

瀏覽器緩存原理

1、當(dāng)瀏覽器向Web服務(wù)器請求一些內(nèi)容是，Web服務(wù)器需要告訴瀏覽器哪些內(nèi)容可以被緩存。

2、瀏覽器將可以被緩存的內(nèi)容緩存起來。

3、當(dāng)下次請求內(nèi)容時，瀏覽器不會直接請求內(nèi)容，而是詢問Web服務(wù)器是否需要更新本地緩存。

4、 Web服務(wù)器做出應(yīng)答，是否需要更新，如需要更新就將最新的內(nèi)容返回。

如何標(biāo)記哪些內(nèi)容可以被緩存?

1、在HTTP響應(yīng)都中增加last-modified關(guān)鍵詞即可。

2、瀏覽器發(fā)送請求是，攜帶：If-modied-sine: {時間}

3、Web服務(wù)器檢查文件最后修改的時間，特別是靜態(tài)文件，只需要判斷兩個時間是否一致。如果沒有修改攜帶：HTTP/1.1 304 Not Modified

304意味著沒有修改。

另一種方法：(ETag)

1、由服務(wù)器端為文件生成一個標(biāo)識號，放在HTTP響應(yīng)頭中

ETag：“744177-b-21aa21cd232ee34”

2、瀏覽器在下次請求的時候，攜帶ETag

If –node-match: 744177-b-21aa21cd232ee34

3、 Web服務(wù)器重新計算文件的ETAG，然后與接受到的ETG比較。如果同，及返回304，不同就返回新的內(nèi)容。

有沒有最優(yōu)解?

直接給文件標(biāo)記Expires,是否過期。

對于靜態(tài)內(nèi)容，Web服務(wù)器默認情況下回開啟Expires標(biāo)記，瀏覽器不需要重復(fù)請求。

谷歌日歷的CSS樣式表設(shè)置的expires 為1年，js腳本設(shè)置為1個月。

Http://www.baidu.com/css/1.css?v=2

Apache服務(wù)器如何設(shè)置js css 圖片等在本地緩存

配置文件中打開過期擴展#LoadModule expires_module modules/mod_expires.so

在.htaccess中加入ExpiresActive OnExpiresDefault "access plus 30 days"

1.3、 Web服務(wù)器緩存

緩存URL映射

將url地址轉(zhuǎn)換成資源路徑

www.baidu.com/12306.html à /data/www/12306.html

經(jīng)rewrite重寫的地址指向?qū)?yīng)的靜態(tài)資源路徑

www.baidu.com/12306.html à /data/www/product/12306.html

經(jīng)rewrite重寫的地址指向?qū)?yīng)的動態(tài)資源地址

www.baidu.com/12306.html à www.baidu.com/?prodcutId=12306

緩存URL 重寫到Real Server的真實地址

www.baidu.com/12306.html à www.back-end.com/?prodcutId=12306

緩存響應(yīng)內(nèi)容

緩存靜態(tài)文件

緩存變更較小的動態(tài)資源

緩存有效期控制，和HTTP緩存一樣的邏輯。設(shè)置expire即可。

緩存存放在哪里?開啟磁盤緩存或者內(nèi)存緩存。

緩存文件描述符

大量靜態(tài)的小文件，需要打開。每個文件占用一個文件描述符。

可以將文件描述符緩存在內(nèi)存中，當(dāng)需要訪問這個文件時，直接對應(yīng)到文件描述符。

Apache中關(guān)于頁面緩存的設(shè)置

http://www.cnblogs.com/yyyyy5101/articles/1899350.html

1.4、反向代理緩存

正向代理：

用戶主動使用代理服務(wù)，服務(wù)器不知道用戶在哪里。Web服務(wù)器只知道代理服務(wù)器或者網(wǎng)關(guān)發(fā)來的請求，并不知道幕后還存在操作者

反向代理：

反向代理服務(wù)器的特點與正向代理正好相反，Web服務(wù)器隱藏在代理服務(wù)器之后。

反向代理的特點

調(diào)度器扮演的是用戶和實際服務(wù)器中間人的角色：

1、任何對于實際服務(wù)器的HTTP請求都必須經(jīng)過調(diào)度器

2、調(diào)度器必須等待實際服務(wù)器的HTTP響應(yīng)，并將它反饋給用戶

內(nèi)容緩存

正向代理服務(wù)器可以設(shè)置緩存，比如一個機構(gòu)內(nèi)部網(wǎng)絡(luò)通過代理上網(wǎng)，一旦某個用戶訪問的網(wǎng)頁被緩存在代理服務(wù)器，內(nèi)部往來的其他用戶就可以快速的獲得這個網(wǎng)頁。

反向代理服務(wù)器同樣可以緩存內(nèi)容，所有的緩存機制使用仍然是使用HTTP/1.1協(xié)議。和WEB服務(wù)器緩存、瀏覽器緩存一樣。在選用反向代理服務(wù)器配置即可。

詳見Nginx反向代理的配置一項。

1.5、應(yīng)用邏輯緩存

將動態(tài)內(nèi)容中訪問數(shù)據(jù)庫的操作，提取到內(nèi)存數(shù)據(jù)庫中，比如Redis，減少數(shù)據(jù)庫訪問的次數(shù)，即減少文件IO操作。

實際的操作中，可以將用戶基礎(chǔ)信息、商品的基礎(chǔ)信息、收貨地址、購物車數(shù)據(jù)、歷史購買記錄，保存在Redis中。

將大字段保存在Mongodb(分布式文檔存儲數(shù)據(jù)庫)。

是我們能夠自定義的，詳見Redis數(shù)據(jù)結(jié)構(gòu)及案例分享

1.6、數(shù)據(jù)庫查詢緩存

當(dāng)你的數(shù)據(jù)庫打開了Query Cache(簡稱QC)功能后，數(shù)據(jù)庫在執(zhí)行SELECT語句時，會將查詢結(jié)果放到QC中，當(dāng)下一次處理同樣的SELECT請求時，數(shù)據(jù)庫就會從QC取得結(jié) 果，而不需要去數(shù)據(jù)表中查詢。

mysql的cache功能的key的生成原理是：把select語句按照一定的hash規(guī)則生成唯一的key，select的結(jié)果生成value，即 key=>value。

注意，所以對于cache而言，select語句是區(qū)分大小寫的，也區(qū)分空格的。兩個select語句必須完完全全一致，才能夠獲取到同一個cache。

生成cache之后，只要該select中涉及到的table有任何的數(shù)據(jù)變動(insert，update，delete操作等),相關(guān)的所有cache都會被刪除。

因此只有數(shù)據(jù)很少變動的table，引入mysql 的cache才較有意義

1.7、前端優(yōu)化

1、設(shè)計更加簡單的網(wǎng)頁，時期包含較少的圖片和腳本，犧牲美觀和交互

2、將多個圖片合并為一個文件，使用CSS背景偏移的技術(shù)呈現(xiàn)

3、合并JavaScript腳本或者CSS樣式表，減少瀏覽器下載次數(shù)

4、充分利用HTTP中的瀏覽器Cache策略，減少重復(fù)下載。

5、將網(wǎng)站資源分布在多個域名之下，增加瀏覽器的并發(fā)下載。

默認情況下，瀏覽器對一個域名下的資源下載有并發(fā)數(shù)據(jù)限制，從2-6不等。

通過將css樣式，圖片，js代碼放在不同的域名下，可以增加并發(fā)。

負載均衡篇

2.1、Web負載均衡

不能狹義地理解為分配給所有實際服務(wù)器一樣多的工作量，因為多臺服務(wù)器的承載能力各不相同，這可能體現(xiàn)在硬件配置、網(wǎng)絡(luò)帶寬的差異，也可能因為某臺服務(wù)器身兼多職，我們所說的“均衡”，也就是希望所有服務(wù)器都不要過載，并且能夠最大程序地發(fā)揮作用。

接口人故事

公司有團隊，各盡其能，工作量增加，外包。

外包接口人管理，接口人休假任務(wù)無法溝通，單點故障。助理。

接口人工作量分配，有的外包公司任務(wù)多，任務(wù)少，能力差，能力強。(負載均衡)

2.1.1、HTTP重定向

Http重定向，它可以將HTTP請求進行轉(zhuǎn)移，在Web開發(fā)中我們經(jīng)常會用它來完成自動跳轉(zhuǎn)，比如用戶登陸成功后跳轉(zhuǎn)到相應(yīng)的管理頁面。

這種重定向完全由HTTP定義，并且由HTTP代理和Web服務(wù)器共同實現(xiàn)。原理如下：

1、當(dāng)HTTP代理(瀏覽器)向Web服務(wù)器請求某個URL后，Web服務(wù)器可以通過HTTP的響應(yīng)頭信息中的location標(biāo)記來返回一個新的URL

2、 HTTP代理(瀏覽器)接收到響應(yīng)頭中的location標(biāo)記，會接著請求location中URL，便完成了自動跳轉(zhuǎn)。

案例展示：

http://www.php.net/downloads.php

http://php.net/get/php-7.0.2.tar.bz2/from/a/mirror

除了按照地域就近分配外，還可以使用輪詢(Round Robin)的方式請求方式打到不同的域名上，還以使用隨機分配等策略。

隨著吞吐率的增加，隨機調(diào)度也會逐漸趨近于順序調(diào)度的均衡效果。

結(jié)論：

不同用戶對站點內(nèi)頁的訪問深度是不同的，也是我們無法控制的，如此，多臺實際服務(wù)器的實際負載差異是不可預(yù)料的，而主站點卻對此一無所知。

所以，在大多數(shù)情況下通過重定向來實現(xiàn)整個站點的負載均衡并不那么讓人滿意。但對于文件下載、廣告展示等一次性的請求，主站點調(diào)度程序可以牢牢把握控制，實際服務(wù)器的URL甚至可以含蓄的隱藏起來。

在實際的的使用中，對于不同的應(yīng)用場景，我們?nèi)匀恍枰J真考慮基于重定向的負載均衡是否適用，權(quán)衡轉(zhuǎn)移請求的開銷和實際請求的開銷，前者的開銷越小，越有意義。

2.1.2、DNS負載均衡

我們知道DNS負責(zé)提供域名解析，當(dāng)我們訪問某個站點時，實際上需要通過該站點的域名的DNS服務(wù)器來獲取域名指定的IP地址，這一過程中，DNS服務(wù)器完成了域名到IP地址的映射，這種映射也是一對多的。

這時候，DNS便充當(dāng)了負載均衡調(diào)度器，如同HTTP的請求一樣，起到了重定轉(zhuǎn)移策略。

多個A記錄

在DNS的各種記錄類型中，A記錄用來指定域名對應(yīng)的IP地址。

常見的比較成熟的DNS系統(tǒng)如linux的bind，windows的DNS服務(wù)都支持一個域名指定多個IP地址，并且可以選擇使用各種調(diào)度策略，常見的便是RR(Round Robin)方式。

下圖中百度使用的最近地域(根據(jù)用戶的IP地址智能解析)

在linux下使用命令： dig baidu.com

一般情況下，可以給域名綁定多個A記錄，在實際的使用中，建議如下配置：先為每個域名配置多個CNAME,然后給CNAME指定的域名配置A記錄。這樣至少能兼顧兩個問題：

1、老用戶如果收藏了你的www1.baidu.com的域名，還能繼續(xù)提供服務(wù)。

2、當(dāng)你擁有很多DNS記錄時，這樣做更容易維護。比如，你希望多個二級域名都指向同一個IP地址，那么你只需要添加一個別名來代替IP地址，隨后當(dāng)你需要修改IP地址，只需要修改別名的IP地址即可。

結(jié)論：

DNS負載均衡的實現(xiàn)主要依賴DNS服務(wù)器的設(shè)置，如果你的站點擁有自己的DNS服務(wù)器，那么以上設(shè)置對于DNS管理員來說，并不困難，但是，大多數(shù)站點仍然使用第三方DNS服務(wù)商，幸運的是，現(xiàn)在有很多DNS服務(wù)商完全支持多個A記錄的輪詢設(shè)置，我們可以根據(jù)需要設(shè)置。

對比HTTP重定向

和前面HTTP重定向相比，基于DNS的方案完全節(jié)省了所謂的主站點，或者說DNS服務(wù)器已經(jīng)充當(dāng)了主站點的職責(zé)。

不過，盡管基于HTTP重定向的負載均衡系統(tǒng)受到主站點性能的制約，但是不可否認重定向的方案中的調(diào)度策略具有非常好的靈活性，完全可以通過Web應(yīng)用程序?qū)崿F(xiàn)任務(wù)和你能想到的調(diào)度策略。

相比之下，為DNS服務(wù)器讓開發(fā)自定義的調(diào)度策略就不是那么容易了，但幸運的是，類似linux bind這樣的DNS服務(wù)軟件提供了豐富的調(diào)度策略供你選擇，其中最常用的就是根據(jù)用戶IP來進行只能解析(上文中的百度就是如此)，這意味著DNS服務(wù)器可以再所有可用的A記錄中尋找用戶最近的一臺服務(wù)器。

如何利用這種策略，完全取決于業(yè)務(wù)的狀況，可以為用戶比較集中的的一些城市提供專用的服務(wù)器，接入城市核心節(jié)點。也可以為為各互聯(lián)網(wǎng)運營商網(wǎng)絡(luò)中的用戶提供專用的服務(wù)器(聯(lián)通的歸聯(lián)通，電信的歸電信)，并接入運營商骨干網(wǎng)絡(luò)。

2.1.3、反向代理負載均衡

幾乎所有主流的Web服務(wù)器都熱衷于支持基于反向代理的負載均衡。它的核心工作就是轉(zhuǎn)發(fā)HTTP請求。

相比前面的HTTP重定向和DNS解析，反向代理的調(diào)度器扮演的是用戶和實際服務(wù)器中間人的角色：

1、任何對于實際服務(wù)器的HTTP請求都必須經(jīng)過調(diào)度器

2、調(diào)度器必須等待實際服務(wù)器的HTTP響應(yīng)，并將它反饋給用戶

特性：

1、調(diào)度策略豐富。例如可以為不同的實際服務(wù)器設(shè)置不同的權(quán)重，以達到能者多勞的效果。

2、對反向代理服務(wù)器的并發(fā)處理能力要求高，因為它工作在HTTP層面。

3、反向代理服務(wù)器進行轉(zhuǎn)發(fā)操作本身是需要一定開銷的，比如創(chuàng)建線程、與后端服務(wù)器建立TCP連接、接收后端服務(wù)器返回的處理結(jié)果、分析HTTP頭部信息、用戶空間和內(nèi)核空間的頻繁切換等，雖然這部分時間并不長，但是當(dāng)后端服務(wù)器處理請求的時間非常短時，轉(zhuǎn)發(fā)的開銷就顯得尤為突出。例如請求靜態(tài)文件，更適合使用前面介紹的基于DNS的負載均衡方式。

4、反向代理服務(wù)器可以監(jiān)控后端服務(wù)器，比如系統(tǒng)負載、響應(yīng)時間、是否可用、TCP連接數(shù)、流量等，從而根據(jù)這些數(shù)據(jù)調(diào)整負載均衡的策略。

5、反射代理服務(wù)器可以讓用戶在一次會話周期內(nèi)的所有請求始終轉(zhuǎn)發(fā)到一臺特定的后端服務(wù)器上(粘滯會話)，這樣的好處一是保持session的本地訪問，二是防止后端服務(wù)器的動態(tài)內(nèi)存緩存的資源浪費

2.1.4、IP負載均衡

因為反向代理服務(wù)器工作在HTTP層，其本身的開銷就已經(jīng)嚴(yán)重制約了可擴展性，從而也限制了它的性能極限。那能否在HTTP層面以下實現(xiàn)負載均衡呢?

NAT服務(wù)器:它工作在傳輸層，它可以修改發(fā)送來的IP數(shù)據(jù)包，將數(shù)據(jù)包的目標(biāo)地址修改為實際服務(wù)器地址。

從 Linux2.4內(nèi)核開始，其內(nèi)置的Neftilter模塊在內(nèi)核中維護著一些數(shù)據(jù)包過濾表，這些表包含了用于控制數(shù)據(jù)包過濾的規(guī)則?？上驳氖?，Linux提供了iptables來對過濾表進行插入、修改和刪除等操作。更加令人振奮的是，Linux2.6.x內(nèi)核中內(nèi)置了IPVS模塊，它的工作性質(zhì)類型于Netfilter模塊，不過它更專注于實現(xiàn)IP負載均衡。

總結(jié)：

實驗證明使用基于NAT的負載均衡系統(tǒng)。作為調(diào)度器的NAT服務(wù)器可以將吞吐率提升到一個新的高度，幾乎是反向代理服務(wù)器的兩倍以上，這大多歸功于在內(nèi)核中進行請求轉(zhuǎn)發(fā)的較低開銷。但是一旦請求的內(nèi)容過大時，不論是基于反向代理還是NAT，負載均衡的整體吞吐量都差距不大，這說明對于一些開銷較大的內(nèi)容，使用簡單的反向代理來搭建負載均衡系統(tǒng)是值考慮的。

使用策略：

一個簡單有效的辦法就是將基于NAT的集群和前面的DNS混合使用，比如5個100Mbps出口寬帶的集群，然后通過DNS來將用戶請求均衡地指向這些集群，同時，你還可以利用DNS智能解析實現(xiàn)地域就近訪問。這樣的配置對于大多數(shù)業(yè)務(wù)是足夠了，但是對于提供下載或視頻等服務(wù)的大規(guī)模站點，NAT服務(wù)器還是不夠出色

2.1.5、直接路由

NAT是工作在網(wǎng)絡(luò)分層模型的傳輸層(第四層)，而直接路由是工作在數(shù)據(jù)鏈路層(第二層)，貌似更屌些。它通過修改數(shù)據(jù)包的目標(biāo)MAC地址(沒有修改目標(biāo)IP)，將數(shù)據(jù)包轉(zhuǎn)發(fā)到實際服務(wù)器上，不同的是，實際服務(wù)器的響應(yīng)數(shù)據(jù)包將直接發(fā)送給客戶端，而不經(jīng)過調(diào)度器。

2.1.6、IP隧道

基于IP隧道的請求轉(zhuǎn)發(fā)機制：將調(diào)度器收到的IP數(shù)據(jù)包封裝在一個新的IP數(shù)據(jù)包中，轉(zhuǎn)交給實際服務(wù)器，然后實際服務(wù)器的響應(yīng)數(shù)據(jù)包可以直接到達用戶端。目前Linux大多支持，可以用LVS來實現(xiàn)，稱為LVS-TUN，與LVS-DR不同的是，實際服務(wù)器可以和調(diào)度器不在同一個WANt網(wǎng)段，調(diào)度器通過 IP隧道技術(shù)來轉(zhuǎn)發(fā)請求到實際服務(wù)器，所以實際服務(wù)器也必須擁有合法的IP地址。

總體來說，LVS-DR和LVS-TUN都適合響應(yīng)和請求不對稱的Web服務(wù)器，如何從它們中做出選擇，取決于你的網(wǎng)絡(luò)部署需要，因為LVS-TUN可以將實際服務(wù)器根據(jù)需要部署在不同的地域，并且根據(jù)就近訪問的原則來轉(zhuǎn)移請求，所以有類似這種需求的，就應(yīng)該選擇LVS-TUN。

2.1.7、負載均衡總結(jié)

l HTTP重定向負載均衡，通過HTTP協(xié)議進行轉(zhuǎn)發(fā)，常用的技術(shù)點是一次性下載。分配策略自己定義。

l DNS負載均衡，通過DNS服務(wù)器對域名進行解析，按照一定的分配策略進行分配，如就近分配和輪詢分配。靈活性沒有HTTP重定向負載均衡高。

l 反向代理負載均衡，是通過一組基于Web服務(wù)器與用戶之間的服務(wù)器來進行的，可以配置靜態(tài)和動態(tài)兩種策略方式來實現(xiàn)負載均衡。一般會遇到黏滯會話的問題，需要考慮是否通過實現(xiàn)黏滯會話來遷就系統(tǒng)的特殊需求，可以考慮使用cookie、分布式session、分布式緩存的技術(shù)手段，讓后端服務(wù)器的應(yīng)用盡量與本地?zé)o關(guān)。

l IP負載均衡(DNAT端口映射)，通過修改數(shù)據(jù)包請求轉(zhuǎn)發(fā)的IP地址，避免網(wǎng)絡(luò)數(shù)據(jù)包進入用戶進程，直接在Linux內(nèi)核階段就轉(zhuǎn)發(fā)到實際服務(wù)器上。收到時候服務(wù)的反饋之后，再修改返回數(shù)據(jù)包的的IP地址將返回數(shù)據(jù)包執(zhí)行用戶的真正請求。常見的技術(shù)手段是Linux內(nèi)核模塊NetFilter。常用的框架就是LVS，LVS不僅可以用來做IP負載均衡，還可以使用用來做直接路由和IP隧道。

l 直接路由，通過修改數(shù)據(jù)包的目標(biāo)MAC地址，將實際服務(wù)器的響應(yīng)數(shù)據(jù)包將直接發(fā)送給用戶端，而不經(jīng)過調(diào)度器。在LVS框架中叫做LVS-DR。直接路由是基于IP別名的實現(xiàn)。

l IP隧道(IP Tunneling),簡單的說，它價格調(diào)度器收到的IP數(shù)據(jù)包封裝在一個新的IP數(shù)據(jù)包中，轉(zhuǎn)交給實際服務(wù)器，然后實際服務(wù)器的響應(yīng)數(shù)據(jù)包可以直接到達客戶端。

2.1.8、負載均衡策略總結(jié)

1、輪循均衡(Round Robin)：每一次來自網(wǎng)絡(luò)的請求輪流分配給內(nèi)部中的服務(wù)器，從1至N然后重新開始。此種均衡算法適合于服務(wù)器組中的所有服務(wù)器都有相同的軟硬件配置并且平均服務(wù)請求相對均衡的情況。

2、權(quán)重輪循均衡(Weighted Round Robin)：根據(jù)服務(wù)器的不同處理能力，給每個服務(wù)器分配不同的權(quán)值，使其能夠接受相應(yīng)權(quán)值數(shù)的服務(wù)請求。例如：服務(wù)器A的權(quán)值被設(shè)計成1，B的權(quán)值是3，C的權(quán)值是6，則服務(wù)器A、B、C將分別接受到10%、30%、60%的服務(wù)請求。此種均衡算法能確保高性能的服務(wù)器得到更多的使用率，避免低性能的服務(wù)器負載過重。

3、隨機均衡(Random)：把來自網(wǎng)絡(luò)的請求隨機分配給內(nèi)部中的多個服務(wù)器。

4、權(quán)重隨機均衡(Weighted Random)：此種均衡算法類似于權(quán)重輪循算法，不過在處理請求分擔(dān)時是個隨機選擇的過程。

5、響應(yīng)速度均衡(Response Time)：負載均衡設(shè)備對內(nèi)部各服務(wù)器發(fā)出一個探測請求(例如Ping)，然后根據(jù)內(nèi)部中各服務(wù)器對探測請求的最快響應(yīng)時間來決定哪一臺服務(wù)器來響應(yīng)客戶端的服務(wù)請求。此種均衡算法能較好的反映服務(wù)器的當(dāng)前運行狀態(tài)，但這最快響應(yīng)時間僅僅指的是負載均衡設(shè)備與服務(wù)器間的最快響應(yīng)時間，而不是客戶端與服務(wù)器間的最快響應(yīng)時間。

6、最少連接數(shù)均衡(Least Connection)：客戶端的每一次請求服務(wù)在服務(wù)器停留的時間可能會有較大的差異，隨著工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一臺服務(wù)器上的連接進程可能會產(chǎn)生極大的不同，并沒有達到真正的負載均衡。最少連接數(shù)均衡算法對內(nèi)部中需負載的每一臺服務(wù)器都有一個數(shù)據(jù)記錄，記錄當(dāng)前該服務(wù)器正在處理的連接數(shù)量，當(dāng)有新的服務(wù)連接請求時，將把當(dāng)前請求分配給連接數(shù)最少的服務(wù)器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務(wù)，如FTP。

7、處理能力均衡：此種均衡算法將把服務(wù)請求分配給內(nèi)部中處理負荷(根據(jù)服務(wù)器CPU型號、CPU數(shù)量、內(nèi)存大小及當(dāng)前連接數(shù)等換算而成)最輕的服務(wù)器，由于考慮到了內(nèi)部服務(wù)器的處理能力及當(dāng)前網(wǎng)絡(luò)運行狀況，所以此種均衡算法相對來說更加精確，尤其適合運用到第七層(應(yīng)用層)負載均衡的情況下。

8、DNS響應(yīng)均衡(Flash DNS)：在Internet上，無論是HTTP、FTP或是其它的服務(wù)請求，客戶端一般都是通過域名解析來找到服務(wù)器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負載均衡設(shè)備收到同一個客戶端的域名解析請求，并在同一時間內(nèi)把此域名解析成各自相對應(yīng)服務(wù)器的IP地址(即與此負載均衡設(shè)備在同一位地理位置的服務(wù)器的IP地址)并返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續(xù)請求服務(wù)，而忽略其它的IP地址響應(yīng)。在種均衡策略適合應(yīng)用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。

服務(wù)故障的檢測方式和能力：

1、Ping偵測：通過ping的方式檢測服務(wù)器及網(wǎng)絡(luò)系統(tǒng)狀況，此種方式簡單快速，但只能大致檢測出網(wǎng)絡(luò)及服務(wù)器上的操作系統(tǒng)是否正常，對服務(wù)器上的應(yīng)用服務(wù)檢測就無能為力了。

2、TCP Open偵測：每個服務(wù)都會開放某個通過TCP連接，檢測服務(wù)器上某個TCP端口(如Telnet的23口，HTTP的80口等)是否開放來判斷服務(wù)是否正常。

3、HTT PURL偵測：比如向HTTP服務(wù)器發(fā)出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為服務(wù)器出現(xiàn)故障。

2.2、LVS負載均衡

2.2.1、LVS是什么

1、LVS的英文全稱是Linux Virtual Server，即Linux虛擬服務(wù)器。

2、它是我們國家的章文嵩博士的一個開源項目。

2.2.2、LVS能干什么

1、 LVS主要用于多服務(wù)器的負載均衡。

2、它工作在網(wǎng)絡(luò)層，可以實現(xiàn)高性能，高可用的服務(wù)器集群技術(shù)。

3、它可把許多低性能的服務(wù)器組合在一起形成一個超級服務(wù)器。

4、它配置非常簡單，且有多種負載均衡的方法。

5、它穩(wěn)定可靠，即使在集群的服務(wù)器中某臺服務(wù)器無法正常工作，也不影響整體效果。

6、可擴展性也非常好。

2.2.3、Nginx和lvs作對比的結(jié)果

1、nginx工作在網(wǎng)絡(luò)的應(yīng)用層，主要做反向代理;lvs工作在網(wǎng)絡(luò)層，主要做負載均衡。Nginx也同樣能承受很高負載且穩(wěn)定，但負載度和穩(wěn)定度不及l(fā)vs。

2、nginx對網(wǎng)絡(luò)的依賴較小，lvs就比較依賴于網(wǎng)絡(luò)環(huán)境。

3、在使用上，一般最前端所采取的策略應(yīng)是lvs。 nginx可作為lvs節(jié)點機器使用。

2.2.4、負載均衡機制

前面我們說了LVS是工作在網(wǎng)絡(luò)層。相對于其它負載均衡的解決辦法，它的效率是非常高的。LVS的通過控制IP來實現(xiàn)負載均衡。IPVS是其具體的實現(xiàn)模塊。IPVS的主要作用：安裝在Director Server上面，在Director Server虛擬一個對外訪問的IP(VIP)。用戶訪問VIP，到達Director Server，Director Server根據(jù)一定的規(guī)則選擇一個Real Server，處理完成后然后返回給客戶端數(shù)據(jù)。這些步驟產(chǎn)生了一些具體的問題，比如如何選擇具體的Real Server，Real Server如果返回給客戶端數(shù)據(jù)等等。IPVS為此有三種機制：

1. VS/NAT(Virtual Server via Network Address Translation)，即網(wǎng)絡(luò)地址翻轉(zhuǎn)技術(shù)實現(xiàn)虛擬服務(wù)器。

當(dāng)請求來到時，Diretor server上處理的程序?qū)?shù)據(jù)報文中的目標(biāo)地址(即虛擬IP地址)改成具體的某臺Real Server,端口也改成Real Server的端口，然后把報文發(fā)給Real Server。Real Server處理完數(shù)據(jù)后，需要返回給Diretor Server，然后Diretor server將數(shù)據(jù)包中的源地址和源端口改成VIP的地址和端口，最后把數(shù)據(jù)發(fā)送出去。由此可以看出，用戶的請求和返回都要經(jīng)過Diretor Server，如果數(shù)據(jù)過多，Diretor Server肯定會不堪重負。

2. VS/TUN(Virtual Server via IP Tunneling),即IP隧道技術(shù)實現(xiàn)虛擬服務(wù)器。

IP隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術(shù)，這可以使得目標(biāo)為一個IP地址的數(shù)據(jù)報文能被封裝和轉(zhuǎn)發(fā)到另一個IP地址。IP隧道技術(shù)亦稱為IP封裝技術(shù)(IP encapsulation)。它跟VS/NAT基本一樣，但是Real server是直接返回數(shù)據(jù)給客戶端，不需要經(jīng)過Diretor server,這大大降低了Diretor server的壓力。

3. VS/DR(Virtual Server via Direct Routing)，即用直接路由技術(shù)實現(xiàn)虛擬服務(wù)器。

跟前面兩種方式，它的報文轉(zhuǎn)發(fā)方法有所不同，VS/DR通過改寫請求報文的MAC地址，將請求發(fā)送到Real Server，而Real Server將響應(yīng)直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調(diào)度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網(wǎng)卡連在同一物理網(wǎng)段上。