首頁技術(shù)文章正文

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

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

交流目標:

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

高性能Web站點

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

高性能Web站點

高性能Web站點

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

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

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

高性能Web站點

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

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

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

高性能Web站點

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

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

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

問題:

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

高性能Web站點

2、 Sesssion共享的問題

解決:

1、什么是session?

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

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

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

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

方法二:session replication 共享

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

高性能Web站點

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

高性能Web站點

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ù)庫

高性能Web站點

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、專庫專用,垂直拆分

高性能Web站點

垂直拆分帶來的影響:

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

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

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

高性能Web站點

水平拆分帶來的影響:

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)……)

高性能Web站點

1513671058643_13.png

服務(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)。

高性能Web站點

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)中剔除,當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)用信息的到達為止。當一個調(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é)合是時下最流行的流式計算框架之一。

緩存篇

高性能Web站點

為什么要緩存?

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

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

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

將動態(tài)內(nèi)容的HTML輸出結(jié)果緩存起來(頁面緩存),在隨后的一段時間內(nèi),當有用戶訪問時變跳過重復(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)建一個目錄,用戶存放緩存文件,并給每個緩存文件上一些必要的標記,比如過期時間等。

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

瀏覽器緩存原理

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

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

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

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

如何標記哪些內(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ù)器端為文件生成一個標識號 ,放在HTTP響應(yīng)頭中

ETag:“744177-b-21aa21cd232ee34”

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

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

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

高性能Web站點

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

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

對于靜態(tài)內(nèi)容,Web服務(wù)器默認情況下回開啟Expires標記,瀏覽器不需要重復(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)存中,當需要訪問這個文件時,直接對應(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反向代理的配置一項。

高性能Web站點

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ù)庫查詢緩存

當你的數(shù)據(jù)庫打開了Query Cache(簡稱QC)功能后,數(shù)據(jù)庫在執(zhí)行SELECT語句時,會將查詢結(jié)果放到QC中,當下一次處理同樣的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ù)少,能力差,能力強。(負載均衡)

高性能Web站點

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、 當HTTP代理(瀏覽器)向Web服務(wù)器請求某個URL后,Web服務(wù)器可以通過HTTP的響應(yīng)頭信息中的location標記來返回一個新的URL

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

案例展示:

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

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

高性能Web站點

高性能Web站點

除了按照地域就近分配外,還可以使用輪詢(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負責提供域名解析,當我們訪問某個站點時,實際上需要通過該站點的域名的DNS服務(wù)器來獲取域名指定的IP地址,這一過程中,DNS服務(wù)器完成了域名到IP地址的映射,這種映射也是一對多的。

這時候,DNS便充當了負載均衡調(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

高性能Web站點

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

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

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

高性能Web站點

結(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)充當了主站點的職責。

不過,盡管基于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)核空間的頻繁切換等,雖然這部分時間并不長,但是當后端服務(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)嚴重制約了可擴展性,從而也限制了它的性能極限。那能否在HTTP層面以下實現(xiàn)負載均衡呢?

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

高性能Web站點

從 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負載均衡。

高性能Web站點

總結(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ù)包的目標MAC地址(沒有修改目標IP),將數(shù)據(jù)包轉(zhuǎn)發(fā)到實際服務(wù)器上,不同的是,實際服務(wù)器的響應(yīng)數(shù)據(jù)包將直接發(fā)送給客戶端,而不經(jīng)過調(diào)度器。

高性能Web站點

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)用盡量與本地無關(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ù)包的目標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)重輪循算法,不過在處理請求分擔時是個隨機選擇的過程。

5、響應(yīng)速度均衡(Response Time):負載均衡設(shè)備對內(nèi)部各服務(wù)器發(fā)出一個探測請求(例如Ping),然后根據(jù)內(nèi)部中各服務(wù)器對探測請求的最快響應(yīng)時間來決定哪一臺服務(wù)器來響應(yīng)客戶端的服務(wù)請求。此種均衡算法能較好的反映服務(wù)器的當前運行狀態(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ù)記錄,記錄當前該服務(wù)器正在處理的連接數(shù)量,當有新的服務(wù)連接請求時,將把當前請求分配給連接數(shù)最少的服務(wù)器,使均衡更加符合實際情況,負載更加均衡。此種均衡算法適合長時處理的請求服務(wù),如FTP。

7、處理能力均衡:此種均衡算法將把服務(wù)請求分配給內(nèi)部中處理負荷(根據(jù)服務(wù)器CPU型號、CPU數(shù)量、內(nèi)存大小及當前連接數(shù)等換算而成)最輕的服務(wù)器,由于考慮到了內(nèi)部服務(wù)器的處理能力及當前網(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ù)器。

當請求來到時,Diretor server上處理的程序?qū)?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肯定會不堪重負。

高性能Web站點

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

IP隧道(IP tunneling)是將一個IP報文封裝在另一個IP報文的技術(shù),這可以使得目標為一個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)段上。

高性能Web站點

2.2.5、LVS配置

CentOS 6.3下部署LVS(NAT)+keepalived實現(xiàn)高性能高可用負載均衡

http://www.cnblogs.com/mchina/archive/2012/08/27/2644391.html

2.3、Nginx反向代理

2.3.1、Nginx簡介

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

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

2.3.2、基礎(chǔ)功能

反向代理加速,簡單的負載均衡和容錯;

2.3.3、優(yōu)勢

1、Nginx專為性能優(yōu)化而開發(fā),性能是其最重要的考量, 實現(xiàn)上非常注重效率 。有報告表明能支持高達 50,000 個并發(fā)連接數(shù)。

2、Nginx具有很高的穩(wěn)定性。其它HTTP服務(wù)器,當遇到訪問的峰值,或者有人惡意發(fā)起慢速連接時,也很可能會導(dǎo)致服務(wù)器物理內(nèi)存耗盡頻繁交換,失去響應(yīng),只能重啟服務(wù)器。

例如當前apache一旦上到200個以上進程,web響應(yīng)速度就明顯非常緩慢了。而Nginx采取了分階段資源分配技術(shù),使得它的CPU與內(nèi)存占用率非常低。

3、nginx官方表示保持10,000個沒有活動的連接,它只占2.5M內(nèi)存,就穩(wěn)定性而言, nginx比其他代理服務(wù)器更勝一籌。

4、Nginx支持熱部署。它的啟動特別容易, 并且?guī)缀蹩梢宰龅?*24不間斷運行,即使運行數(shù)個月也不需要重新啟動。你還能夠在不間斷服務(wù)的情況下,對軟件版本進行進行升級。

5、Nginx采用C進行編寫, 不論是系統(tǒng)資源開銷還是CPU使用效率都高很多。

2.3.4、配置

Nginx安裝與使用

http://www.cnblogs.com/skynet/p/4146083.html

Nginx配置文件詳細說明

http://www.cnblogs.com/xiaogangqq123/archive/2011/03/02/1969006.html


本文版權(quán)歸黑馬程序員云計算大數(shù)據(jù)學(xué)院所有,歡迎轉(zhuǎn)載,轉(zhuǎn)載請注明作者出處。謝謝!


作者:黑馬程序員云計算大數(shù)據(jù)培訓(xùn)學(xué)院


首發(fā):http://cloud.itheima.com/


分享到:
在線咨詢 我要報名
和我們在線交談!