首頁大數(shù)據(jù)技術文章正文

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

更新時間:2017年12月19日15時18分來源:傳智播客瀏覽次數(shù):

交流目標：

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

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

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

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

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

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

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

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

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

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

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

總結：

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

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

2.1、構建網(wǎng)站技術手段

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

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

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

SpringMVC/Spring/Ibatis/JDBC/Mysql

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

l 各個功能模塊通過JVM內部方法調用來進行交付

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

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

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

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

2.4、應用服務器負載告警、如何讓應用服務器走向集群

l 應用服務器壓力變大，從一臺變成兩臺。

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

l 應用負載均衡一般使用Nginx或者apache

問題：

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

2、 Sesssion共享的問題

解決：

1、什么是session?

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

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

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

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

方法二：session replication 共享

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

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

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

l 搜索引擎也是一個讀庫

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

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

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

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

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

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

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

2.7.1、專庫專用，垂直拆分

垂直拆分帶來的影響：

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

需要應用或者其他方案解決

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

水平拆分帶來的影響：

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

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

l 查詢分頁的問題

l 包含垂直拆分的影響

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

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

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

將應用拆分開來。

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

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

服務化之后，涉及到應用與應用之間的通信。即進程與進程間的通信。

遠程過程調用(RPC、Netty等)

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

3.1、分布式網(wǎng)站的整體結構

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

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

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

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

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

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

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

這些框架會在接下來的學習中一一涉獵。

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

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

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

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

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

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

緩存篇

為什么要緩存?

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

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

動態(tài)內容緩存

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

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

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

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

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

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

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

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

局部緩存

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

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

1.2、瀏覽器緩存

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

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

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

瀏覽器緩存原理

1、當瀏覽器向Web服務器請求一些內容是，Web服務器需要告訴瀏覽器哪些內容可以被緩存。

2、瀏覽器將可以被緩存的內容緩存起來。

3、當下次請求內容時，瀏覽器不會直接請求內容，而是詢問Web服務器是否需要更新本地緩存。

4、 Web服務器做出應答，是否需要更新，如需要更新就將最新的內容返回。

如何標記哪些內容可以被緩存?

1、在HTTP響應都中增加last-modified關鍵詞即可。

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

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

304意味著沒有修改。

另一種方法：(ETag)

1、由服務器端為文件生成一個標識號，放在HTTP響應頭中

ETag：“744177-b-21aa21cd232ee34”

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

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

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

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

直接給文件標記Expires,是否過期。

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

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

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

Apache服務器如何設置js css 圖片等在本地緩存

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

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

1.3、 Web服務器緩存

緩存URL映射

將url地址轉換成資源路徑

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

經(jīng)rewrite重寫的地址指向對應的靜態(tài)資源路徑

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

經(jīng)rewrite重寫的地址指向對應的動態(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

緩存響應內容

緩存靜態(tài)文件

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

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

緩存存放在哪里?開啟磁盤緩存或者內存緩存。

緩存文件描述符

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

可以將文件描述符緩存在內存中，當需要訪問這個文件時，直接對應到文件描述符。

Apache中關于頁面緩存的設置

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

1.4、反向代理緩存

正向代理：

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

反向代理：

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

反向代理的特點

調度器扮演的是用戶和實際服務器中間人的角色：

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

2、調度器必須等待實際服務器的HTTP響應，并將它反饋給用戶

內容緩存

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

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

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

1.5、應用邏輯緩存

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

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

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

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

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

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

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

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

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

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

1.7、前端優(yōu)化

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

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

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

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

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

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

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

負載均衡篇

2.1、Web負載均衡

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

接口人故事

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

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

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

2.1.1、HTTP重定向

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

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

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

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

案例展示：

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

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

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

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

結論：

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

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

在實際的的使用中，對于不同的應用場景，我們仍然需要認真考慮基于重定向的負載均衡是否適用，權衡轉移請求的開銷和實際請求的開銷，前者的開銷越小，越有意義。

2.1.2、DNS負載均衡

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

這時候，DNS便充當了負載均衡調度器，如同HTTP的請求一樣，起到了重定轉移策略。

多個A記錄

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

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

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

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

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

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

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

結論：

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

對比HTTP重定向

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

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

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

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

2.1.3、反向代理負載均衡

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

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

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

2、調度器必須等待實際服務器的HTTP響應，并將它反饋給用戶

特性：

1、調度策略豐富。例如可以為不同的實際服務器設置不同的權重，以達到能者多勞的效果。

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

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

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

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

2.1.4、IP負載均衡

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

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

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

總結：

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

使用策略：

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

2.1.5、直接路由

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

2.1.6、IP隧道

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

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

2.1.7、負載均衡總結

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

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

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

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

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

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

2.1.8、負載均衡策略總結

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

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

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

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

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

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

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

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

服務故障的檢測方式和能力：

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

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

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

2.2、LVS負載均衡

2.2.1、LVS是什么

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

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

2.2.2、LVS能干什么

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

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

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

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

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

6、可擴展性也非常好。

2.2.3、Nginx和lvs作對比的結果

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

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

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

2.2.4、負載均衡機制

前面我們說了LVS是工作在網(wǎng)絡層。相對于其它負載均衡的解決辦法，它的效率是非常高的。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)絡地址翻轉技術實現(xiàn)虛擬服務器。

當請求來到時，Diretor server上處理的程序將數(shù)據(jù)報文中的目標地址(即虛擬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隧道技術實現(xiàn)虛擬服務器。

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

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

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