集羣、分佈式、負載均衡區別（轉）

集羣

集羣的概念

　　計算機集羣經過一組鬆散集成的計算機軟件和/或硬件鏈接起來高度緊密地協做完成計算工做。在某種意義上，他們能夠被看做是一臺計算機。集羣系統中的單個計算機一般稱爲節點，一般經過局域網鏈接，但也有其它的可能鏈接方式。集羣計算機一般用來改進單個計算機的計算速度和/或可靠性。通常狀況下集羣計算機比單個計算機，好比工做站或超級計算機性能價格比要高得多。
　　好比單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。通常分爲幾種：

• 高可用性集羣：通常是指當集羣中有某個節點失效的狀況下，其上的任務會自動轉移到其餘正常的節點上。還指能夠將集羣中的某節點進行離線維護再上線，該過程並不影響整個集羣的運行。
• 負載均衡集羣：負載均衡集羣運行時，通常經過一個或者多個前端負載均衡器，將工做負載分發到後端的一組服務器上，從而達到整個系統的高性能和高可用性。
• 高性能計算集羣：高性能計算集羣採用將計算任務分配到集羣的不一樣計算節點而提升計算能力，於是主要應用在科學計算領域。

分佈式

　　集羣：同一個業務，部署在多個服務器上。分佈式：一個業務分拆成多個子業務，或者自己就是不一樣的業務，部署在不一樣的服務器上。
　　簡單說，分佈式是以縮短單個任務的執行時間來提高效率的，而集羣則是經過提升單位時間內執行的任務數來提高效率。舉例：就好比新浪網，訪問的人多了，他能夠作一個羣集，前面放一個均衡服務器，後面幾臺服務器完成同一業務，若是有業務訪問的時候，響應服務器看哪臺服務器的負載不是很重，就將給哪一臺去完成，而且一臺服務器垮了，其它的服務器能夠頂上來。分佈式的每個節點，都完成不一樣的業務，一個節點垮了，那這個業務可能就失敗了。

負載均衡

概念

　　隨着業務量的提升，現有網絡的各個核心部分訪問量和數據流量的快速增加，其處理能力和計算強度也相應地增大，使得單一的服務器設備根本沒法承擔。在此狀況下，若是扔掉現有設備去作大量的硬件升級，這樣將形成現有資源的浪費，並且若是再面臨下一次業務量的提高時，這又將致使再一次硬件升級的高額成本投入，甚至性能再卓越的設備也不能知足當前業務量增加的需求。
　　負載均衡技術經過設置虛擬服務器IP（VIP），將後端多臺真實服務器的應用資源虛擬成一臺高性能的應用服務器，經過負載均衡算法，將用戶的請求轉發給後臺內網服務器，內網服務器將請求的響應返回給負載平衡器，負載平衡器再將響應發送到用戶，這樣就向互聯網用戶隱藏了內網結構，阻止了用戶直接訪問後臺（內網）服務器，使得服務器更加安全，能夠阻止對核心網絡棧和運行在其它端口服務的攻擊。而且負載均衡設備（軟件或硬件）會持續的對服務器上的應用狀態進行檢查，並自動對無效的應用服務器進行隔離，實現了一個簡單、擴展性強、可靠性高的應用解決方案，解決了單臺服務器處理性能不足，擴展性不夠，可靠性較低的問題。
　　系統的擴展可分爲縱向（垂直）擴展和橫向（水平）擴展。縱向擴展，是從單機的角度經過增長硬件處理能力，好比CPU處理能力，內存容量，磁盤等方面，實現服務器處理能力的提高，不能知足大型分佈式系統（網站），大流量，高併發，海量數據的問題。所以須要採用橫向擴展的方式，經過添加機器來知足大型網站服務的處理能力。好比：一臺機器不能知足，則增長兩臺或者多臺機器，共同承擔訪問壓力。

　　負載平衡最重要的一個應用是利用多臺服務器提供單一服務，這種方案有時也稱之爲服務器農場。一般，負載平衡主要應用於Web網站，大型的Internet Relay Chat網絡，高流量的文件下載網站，NNTP（Network News Transfer Protocol）服務和DNS服務。如今負載平衡器也開始支持數據庫服務，稱之爲數據庫負載平衡器。
　　服務器負載均衡有三大基本Feature：負載均衡算法，健康檢查和會話保持，這三個Feature是保證負載均衡正常工做的基本要素。其餘一些功能都是在這三個功能之上的一些深化。下面咱們具體介紹一下各個功能的做用和原理。
　　在沒有部署負載均衡設備以前，用戶直接訪問服務器地址（中間或許有在防火牆上將服務器地址映射成別的地址，但本質上仍是一對一的訪問）。當單臺服務器因爲性能不足沒法處理衆多用戶的訪問時，就要考慮用多臺服務器來提供服務，實現的方式就是負載均衡。負載均衡設備的實現原理是把多臺服務器的地址映射成一個對外的服務IP（咱們一般稱之爲VIP，關於服務器的映射能夠直接將服務器IP映射成VIP地址，也能夠將服務器IP:Port映射成VIP:Port，不一樣的映射方式會採起相應的健康檢查，在端口映射時，服務器端口與VIP端口能夠不相同）,這個過程對用戶端是不可見的，用戶實際上不知道服務器是作了負載均衡的，由於他們訪問的仍是一個目的IP，那麼用戶的訪問到達負載均衡設備後，如何把用戶的訪問分發到合適的服務器就是負載均衡設備要作的工做了，具體來講用到的就是上述的三大Feature。
咱們來作一個詳細的訪問流程分析:

　　用戶(IP:207.17.117.20)訪問域名www.a10networks.com，首先會經過DNS查詢解析出這個域名的公網地址：199.237.202.124，接下來用戶207.17.117.20會訪問199.237.202.124這個地址，所以數據包會到達負載均衡設備，接下來負載均衡設備會把數據包分發到合適的服務器，看下圖：

　　負載均衡設備在將數據包發給服務器時，數據包是作了一些變化的，如上圖所示，數據包到達負載均衡設備以前，源地址是：207.17.117.20，目的地址是：199.237.202.124，當負載均衡設備將數據包轉發給選中的服務器時，源地址仍是：207.17.117.20，目的地址變爲172.16.20.1，咱們稱這種方式爲目的地址NAT(DNAT，目的地址轉換)。通常來講，在服務器負載均衡中DNAT是必定要作的（還有另外一種模式叫作服務器直接返回-DSR，是不作DNAT的，咱們將另行討論），而源地址根據部署模式的不一樣，有時候也須要轉換成別的地址，咱們稱之爲：源地址NAT(SNAT)，通常來講，旁路模式須要作SNAT，而串接模式不須要，本示意圖爲串接模式，因此源地址沒作NAT。
　　咱們再看服務器的返回包，以下圖所示，也通過了IP地址的轉換過程，不過應答包中源/目的地址與請求包正好對調，從服務器回來的包源地址爲172.16.20.1，目的地址爲207.17.117.20，到達負載均衡設備後，負載均衡設備將源地址改成199.237.202.124，而後轉發給用戶，保證了訪問的一致性。

負載均衡算法

　　通常來講負載均衡設備都會默認支持多種負載均衡分發策略，例如：

• 輪詢（RoundRobin）將請求順序循環地發到每一個服務器。當其中某個服務器發生故障，AX就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。
• 比率（Ratio）：給每一個服務器分配一個加權值爲比例，根椐這個比例，把用戶的請求分配到每一個服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
• 優先權（Priority）：給全部服務器分組，給每一個組定義優先權，將用戶的請求分配給優先級最高的服務器組（在同一組內，採用預先設定的輪詢或比率算法，分配用戶的請求）；當最高優先級中全部服務器或者指定數量的服務器出現故障，AX將把請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。
• 最少鏈接數（LeastConnection）：AX會記錄當前每臺服務器或者服務端口上的鏈接數，新的鏈接將傳遞給鏈接數最少的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
• 最快響應時間（Fast Reponse time）：新的鏈接傳遞給那些響應最快的服務器。當其中某個服務器發生故障，AX就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
• 哈希算法( hash): 將客戶端的源地址，端口進行哈希運算，根據運算的結果轉發給一臺服務器進行處理，當其中某個服務器發生故障，就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
• 基於數據包的內容分發：例如判斷HTTP的URL，若是URL中帶有.jpg的擴展名，就把數據包轉發到指定的服務器。

健康檢查

　　健康檢查用於檢查服務器開放的各類服務的可用狀態。負載均衡設備通常會配置各類健康檢查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。Ping屬於第三層的健康檢查，用於檢查服務器IP的連通性，而TCP/UDP屬於第四層的健康檢查，用於檢查服務端口的UP/DOWN，若是要檢查的更準確，就要用到基於7層的健康檢查，例如建立一個HTTP健康檢查，Get一個頁面回來，而且檢查頁面內容是否包含一個指定的字符串，若是包含，則服務是UP的，若是不包含或者取不回頁面，就認爲該服務器的Web服務是不可用（DOWN）的。好比，負載均衡設備檢查到172.16.20.3這臺服務器的80端口是DOWN的，負載均衡設備將不把後面的鏈接轉發到這臺服務器，而是根據算法將數據包轉發到別的服務器。建立健康檢查時能夠設定檢查的間隔時間和嘗試次數，例如設定間隔時間爲5秒，嘗試次數爲3，那麼負載均衡設備每隔5秒發起一次健康檢查，若是檢查失敗，則嘗試3次，若是3次都檢查失敗，則把該服務標記爲DOWN，而後服務器仍然會每隔5秒對DOWN的服務器進行檢查，當某個時刻發現該服務器健康檢查又成功了，則把該服務器從新標記爲UP。健康檢查的間隔時間和嘗試次數要根據綜合狀況來設置，原則是既不會對業務產生影響，又不會對負載均衡設備形成較大負擔。

會話保持

　　如何保證一個用戶的兩次http請求轉發到同一個服務器，這就要求負載均衡設備配置會話保持。
　　會話保持用於保持會話的連續性和一致性，因爲服務器之間很難作到實時同步用戶訪問信息，這就要求把用戶的先後訪問會話保持到一臺服務器上來處理。舉個例子，用戶訪問一個電子商務網站，若是用戶登陸時是由第一臺服務器來處理的，但用戶購買商品的動做卻由第二臺服務器來處理，第二臺服務器因爲不知道用戶信息，因此本次購買就不會成功。這種狀況就須要會話保持，把用戶的操做都經過第一臺服務器來處理才能成功。固然並非全部的訪問都須要會話保持，例如服務器提供的是靜態頁面好比網站的新聞頻道，各臺服務器都有相同的內容，這種訪問就不須要會話保持。
　　絕大多數的負載均衡產品都支持兩類基本的會話保持方式：源/目的地址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較經常使用的方式，但不是全部設備都支持。基於不一樣的應用要配置不一樣的會話保持，不然會引發負載的不均衡甚至訪問異常。咱們主要分析B/S結構的會話保持。

基於B/S結構的應用：

　　對於普通B/S結構的應用內容，例如網站的靜態頁面，能夠不用配置任何的會話保持，可是對於一個基於B/S結構尤爲是中間件平臺的業務系統來講，必須配置會話保持，通常狀況下，咱們配置源地址會話保持能夠知足需求，可是考慮到客戶端可能有上述不利於源地址會話保持的環境，採用Cookie會話保持是一個更好的方式。Cookie會話保持會把負載均衡設備選擇的Server信息保存在Cookie中發送到客戶端，客戶端持續訪問時，會把該Cookie帶來，負載均衡器經過分析Cookie把會話保持到以前選定的服務器。Cookie分爲文件Cookie和內存cookie，文件cookie保存在客戶端計算機硬盤上，只要該cookie文件不過時，則不管是否重複關閉開放瀏覽器都能保持到同一臺服務器。內存Cookie則是把Cookie信息保存在內存中，Cookie的生存時間從打開瀏覽器訪問開始，關閉瀏覽器結束。因爲如今的瀏覽器對Cookie都有必定默認的安全設置，有些客戶端可能規定不許使用文件Cookie，因此如今的應用程序開發多使用內存Cookie。
　　然而，內存Cookie也不是萬能的，好比瀏覽器爲了安全可能會徹底禁用Cookie，這樣Cookie會話保持就失去了做用。咱們能夠經過Session-id來實現會話保持，即將session-id做爲url參數或者放在隱藏字段<input type="hidden">中，而後分析Session-id進行分發。
　　另外一種方案是：將每一會話信息保存到一個數據庫中。因爲這個方案會增長數據庫的負載，因此這個方案對性能的提升並很差。數據庫最好是用來存儲會話時間比較長的會話數據。爲了不數據庫出現單點故障，而且提升其擴展性，數據庫一般會複製到多臺服務器上，經過負載均衡器來分發請求到數據庫服務器上。
　　基於源/目的地址會話保持其實不太好用，由於客戶多是經過DHCP，NAT或者Web代理來鏈接Internet的，其IP地址可能常常變換，這使得這個方案的服務質量沒法保障。
NAT(Network Address Translation，網絡地址轉換):當在專用網內部的一些主機原本已經分配到了本地IP地址(即僅在本專用網內使用的專用地址)，但如今又想和因特網上的主機通訊(並不須要加密)時，可以使用NAT方法。這種方法須要在專用網鏈接到因特網的路由器上安裝NAT軟件。裝有NAT軟件的路由器叫作NAT路由器，它至少有一個有效的外部全球IP地址。這樣，全部使用本地地址的主機在和外界通訊時，都要在NAT路由器上將其本地地址轉換成全球IP地址，才能和因特網鏈接。

負載均衡的其餘好處

高擴展性

　　經過添加或減小服務器數量，能夠更好的應對高併發請求。

（服務器）健康檢查

　　負載均衡器能夠檢查後臺服務器應用層的健康情況並從服務器池中移除那些出現故障的服務器，提升可靠性。

TCP 鏈接複用（TCP Connection Reuse）

　　TCP鏈接複用技術經過將前端多個客戶的HTTP請求複用到後端與服務器創建的一個TCP鏈接上。這種技術可以大大減少服務器的性能負載，減小與服務器之間新建TCP鏈接所帶來的延時，並最大限度的下降客戶端對後端服務器的併發鏈接數請求，減小服務器的資源佔用。
　　通常狀況下，客戶端在發送HTTP請求以前須要先與服務器進行TCP三次握手，創建TCP鏈接，而後發送HTTP請求。服務器收到HTTP請求後進行處理，並將處理的結果發送回客戶端，而後客戶端和服務器互相發送FIN並在收到FIN的ACK確認後關閉鏈接。在這種方式下，一個簡單的HTTP請求須要十幾個TCP數據包才能處理完成。
　　採用TCP鏈接複用技術後，客戶端（如：ClientA）與負載均衡設備之間進行三次握手併發送HTTP請求。負載均衡設備收到請求後，會檢測服務器是否存在空閒的長鏈接，若是不存在，服務器將創建一個新鏈接。當HTTP請求響應完成後，客戶端則與負載均衡設備協商關閉鏈接，而負載均衡則保持與服務器之間的這個鏈接。當有其它客戶端（如：ClientB）須要發送HTTP請求時，負載均衡設備會直接向與服務器之間保持的這個空閒鏈接發送HTTP請求，避免了因爲新建TCP鏈接形成的延時和服務器資源耗費。

　　在HTTP 1.1中，客戶端能夠在一個TCP鏈接中發送多個HTTP請求，這種技術叫作HTTP複用（HTTP Multiplexing）。它與TCP鏈接複用最根本的區別在於，TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端TCP鏈接上，而HTTP複用則是一個客戶端的多個HTTP請求經過一個TCP鏈接進行處理。前者是負載均衡設備的獨特功能；然後者是HTTP 1.1協議所支持的新功能，目前被大多數瀏覽器所支持。

HTTP緩存

　　負載均衡器能夠存儲靜態內容，當用戶請求它們時能夠直接響應用戶而沒必要再向後臺服務器請求。

TCP緩衝

　　TCP緩衝是爲了解決後端服務器網速與客戶的前端網絡速度不匹配而形成的服務器資源浪費的問題。客戶端與負載均衡之間採用的鏈路具備較高的時延和較低的帶寬，而負載均衡與服務器之間採用時延較低和高帶寬的局域網鏈接。因爲負載均衡器能夠暫存後臺服務器對客戶的響應數據，再將它們轉發給那些響應時間較長網速較慢的客戶，如此後臺Web服務器就能夠釋放相應的線程去處理其它任務。

SSL加速

　　通常狀況下，HTTP採用明文的方式在網絡上傳輸，有可能被非法竊聽，尤爲是用於認證的口令信息等。爲了不出現這樣的安全問題，通常採用SSL協議（即：HTTPS）對HTTP協議進行加密，以保證整個傳輸過程的安全性。在SSL通訊中，首先採用非對稱密鑰技術交換認證信息，並交換服務器和瀏覽器之間用於加密數據的會話密鑰，而後利用該密鑰對通訊過程當中的信息進行加密和解密。
　　SSL是須要耗費大量CPU資源的一種安全技術。目前，大多數負載均衡設備均採用SSL加速芯片（硬件負載均衡器）進行SSL信息的處理。這種方式比傳統的採用服務器的SSL加密方式提供更高的SSL處理性能，從而節省大量的服務器資源，使服務器可以專一於業務請求的處理。另外，採用集中的SSL處理，還可以簡化對證書的管理，減小平常管理的工做量。

內容過濾

　　有些負載均衡器能夠按要求修改經過它的數據。

入侵阻止功能

　　在防火牆保障網絡層/傳輸層安全的基礎上，提供應用層安全防範。

分類

　　下面從不一樣層次討論負載均衡的實現：

DNS 負載均衡

　　DNS負責提供域名解析服務，當訪問某個站點時，實際上首先須要經過該站點域名的DNS服務器來獲取域名指向的IP地址，在這一過程當中，DNS服務器完成了域名到IP地址的映射，一樣，這樣映射也能夠是一對多的，這時候，DNS服務器便充當了負載均衡調度器，將用戶的請求分散到多臺服務器上。使用dig命令來看下」baidu」的DNS設置：

　　可見baidu擁有三個A記錄。

　　這種技術的優勢是，實現簡單、實施容易、成本低、適用於大多數TCP/IP應用，而且DNS服務器能夠在全部可用的A記錄中尋找離用戶最近的一臺服務器。可是，其缺點也很是明顯，首先這種方案不是真正意義上的負載均衡，DNS服務器將Http請求平均地分配到後臺的Web服務器上（或者根據地理位置），而不考慮每一個Web服務器當前的負載狀況；若是後臺的Web服務器的配置和處理能力不一樣，最慢的Web服務器將成爲系統的瓶頸，處理能力強的服務器不能充分發揮做用；其次未考慮容錯，若是後臺的某臺Web服務器出現故障，DNS服務器仍然會把DNS請求分配到這臺故障服務器上，致使不能響應客戶端。最後一點是致命的，有可能形成至關一部分客戶不能享受Web服務，而且因爲DNS緩存的緣由，所形成的後果要持續至關長一段時間(通常DNS的刷新週期約爲24小時)。因此在國外最新的建設中心Web站點方案中，已經不多采用這種方案了。

鏈路層（OSI 第二層）負載均衡

　　在通訊協議的數據鏈路層修改mac地址，進行負載均衡。
　　數據分發時，不修改ip地址（由於還看不到ip地址），只修改目標mac地址，而且配置全部後端服務器虛擬ip和負載均衡器ip地址一致，達到不修改數據包的源地址和目標地址，進行數據分發的目的。
　　實際處理服務器ip和數據請求目的ip一致，不須要通過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成爲瓶頸。也稱爲直接路由模式（DR模式）。以下圖：

　　性能很好，可是配置複雜，目前應用比較普遍。

傳輸層（OSI 第四層）負載均衡

　　傳輸層是 OSI 第四層，包括 TCP 和 UDP。流行的傳輸層負載均衡器有 HAProxy（這個也用於應用層負載均衡）和 IPVS。
　　主要經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
　　以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即經過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改成後端服務器IP），直接轉發給該服務器。TCP的鏈接創建，即三次握手是客戶端和服務器直接創建的，負載均衡設備只是起到一個相似路由器的轉發動做。在某些部署狀況下，爲保證服務器回包能夠正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

應用層（OSI 第七層）負載均衡

　　應用層是 OSI 第七層。它包括 HTTP、HTTPS 和 WebSockets。一款很是流行又久經考驗的應用層負載均衡器就是 Nginx[恩靜埃克斯 = Engine X]。
　　所謂七層負載均衡，也稱爲「內容交換」，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。注意此時能夠看到具體的http請求的完整url，所以能夠實現下圖所示的分發：

　　以常見的TCP爲例，負載均衡設備若是要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端創建鏈接(三次握手)後，才能看到客戶端發送的真正應用層內容的報文，而後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種狀況下，更相似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別創建TCP鏈接。因此從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。那麼，爲何還須要七層負載均衡呢？

　　七層負載均衡的好處，是使得整個網絡更"智能化"，好比上面列舉的負載均衡的好處，大部分都基於七層負載均衡。例如訪問一個網站的用戶流量，能夠經過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可使用緩存技術；將對文字類的請求能夠轉發到特定的文字服務器並可使用壓縮技術。固然這只是七層應用的一個小案例，從技術原理上，這種方式能夠對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提高了應用系統在網絡層的靈活性。　　另一個經常被提到功能就是安全性。網絡中最多見的SYN Flood攻擊，即黑客控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，一般這種攻擊會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也能夠看出，四層模式下這些SYN攻擊都會被轉發到後端的服務器上；而七層模式下這些SYN攻擊天然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備能夠在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提升系統總體安全。　　如今的七層負載均衡，主要仍是着重於應用普遍的HTTP協議，因此其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 四層負載均衡則對應其餘TCP應用，例如基於C/S開發的ERP等系統。