負載均衡(摘抄)
DNS（Domain Name System）是因特網的一項服務，它作為域名和IP地址相互映射的一個分布式數據庫，能夠使人更方便的訪問互聯網。人們在通過瀏覽器訪問網站時只需要記住網站的域名即可，而不需要記住那些不太容易理解的IP地址。在DNS系統中有一個比較重要的的資源類型叫做主機記錄也稱為A記錄，A記錄是用於名稱解析的重要記錄，它將特定的主機名映射到對應主機的IP地址上。如果你有一個自己的域名，那麽要想別人能訪問到你的網站，你需要到特定的DNS解析服務商的服務器上填寫A記錄，過一段時間後，別人就能通過你的域名訪問你的網站了。DNS除了能解析域名之外還具有負載均衡的功能，下面是利用DNS工作原理處理負載均衡的工作原理圖：
由上圖可以看出，在DNS服務器中應該配置了多個A記錄，如：
www.apusapp.com IN A 114.100.20.201;
www.apusapp.com IN A 114.100.20.202;
www.apusapp.com IN A 114.100.20.203;
因此，每次域名解析請求都會根據對應的負載均衡算法計算出一個不同的IP地址並返回，這樣A記錄中配置多個服務器就可以構成一個集群，並可以實現負載均衡。上圖中，用戶請求www.apusapp.com，DNS根據A記錄和負載均衡算法計算得到一個IP地址114.100.20.203，並返回給瀏覽器，瀏覽器根據該IP地址，訪問真實的物理服務器114.100.20.203。所有這些操作對用戶來說都是透明的，用戶可能只知道www.apusapp.com這個域名。
DNS域名解析負載均衡有如下優點：
1. 將負載均衡的工作交給DNS，省去了網站管理維護負載均衡服務器的麻煩。
2. 技術實現比較靈活、方便，簡單易行，成本低，使用於大多數TCP/IP應用。
3. 對於部署在服務器上的應用來說不需要進行任何的代碼修改即可實現不同機器上的應用訪問。
3. 服務器可以位於互聯網的任意位置。
4. 同時許多DNS還支持基於地理位置的域名解析，即會將域名解析成距離用戶地理最近的一個服務器地址，這樣就可以加速用戶訪問，改善性能。
同時，DNS域名解析也存在如下缺點：
1. 目前的DNS是多級解析的，每一級DNS都可能緩存A記錄，當某臺服務器下線之後，即使修改了A記錄，要使其生效也需要較長的時間，這段時間，DNS任然會將域名解析到已下線的服務器上，最終導致用戶訪問失敗。
2. 不能夠按服務器的處理能力來分配負載。DNS負載均衡采用的是簡單的輪詢算法，不能區分服務器之間的差異，不能反映服務器當前運行狀態，所以其的負載均衡效果並不是太好。
3. 可能會造成額外的網絡問題。為了使本DNS服務器和其他DNS服務器及時交互，保證DNS數據及時更新，使地址能隨機分配，一般都要將DNS的刷新時間設置的較小，但太小將會使DNS流量大增造成額外的網絡問題。
事實上，大型網站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器並不是實際提供服務的物理服務器，而是同樣提供負載均衡服務器的內部服務器，這組內部負載均衡服務器再進行負載均衡，請請求發到真實的服務器上，最終完成請求。
負載均衡之反向代理
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個服務器，該服務器就可稱之為代理服務器。由於代理服務器處在最終處理請求訪問的服務器之前，因此可以在代理服務器上做負載均衡。實際上，互聯網中也大量的存在反向代理服務器提供代理功能的同時也提供負載均衡的功能。其工作原理如下圖所示：
由上圖可以推出，反向代理服務器，管理了一組服務器，可以根據對應的負載均衡算法將不同的請求轉發到不同的服務器上。服務器處理完成的響應也通過代理服務器返回給用戶。由於內部服務器不直接對外提供訪問，因此，內部服務器地址不需要使用外部IP，而反向代理服務器則需要配置雙網卡，提供內部和對外訪問的IP地址。
如上圖，用戶瀏覽器訪問請求的地址是114.100.20.200，反向代理服務器接收到請求後，根據負載均衡算法計算得到一臺真實的內部服務器地址192.168.1.1，並將用戶的請求轉發到該服務器上，192.168.1.1處理完請求後將響應返回給反相代理服務器，反相代理服務器再將該響應的內容返回給用戶。
與此同時，反相代理服務器還可以具有存儲靜態數據用於緩存的功能，從而加速處理用戶請求，提高服務器處理性能，其工作原理大概如下圖所示：
反向代理服務器轉發請求處於應用層協議上，因此，也稱之為應用層負載均衡。該負載均衡方案與反向代理服務器功能集成到了一起，部署相對簡單，但是，反向代理服務器會處理所有的請求和響應，其性能可能將會成為整個集群的瓶頸。
註：常用的代理服務器軟件有：Fikker、Nginx、Squid等
負載均衡之數據鏈路層
在TCP/IP協議中數據鏈路層處於最底層，以幀的形式傳輸和接受數據。在這一層中MAC(Media Access Control)尋址是主要功能。在網絡中MAC又稱之為MAC地址，用於表示互聯網上每個網卡的標識符，采用十六進制表示，共6個字節（48位），燒錄在網卡內部。更形象的說MAC地址就像×××號碼，全球唯一。以太網中數據幀之間是通過MAC尋址來到達對應的計算機網卡或者路由的，因此，服務器集群可以充分利用這一特性來進行負載均衡。
數據鏈路層負載均衡通過修改通信協議數據包的mac地址進行負載均衡，集群可以通過如下圖的部署來達到負載均衡：
這種數據傳輸方式又稱為三角傳輸，負載均衡數據分發過程中不修改IP地址，只修改目的MAC地址，通過配置真實物理服務器集群所有機器虛擬IP和負載均衡服務器IP一致，從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的，由於實際處理請求的真實物理服務器IP和數據請求目的IP一致，不需要通過負載均衡服務器進行地址交換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成為瓶頸。這種負載均衡方式又稱之為直接路由方式（DR）.
如上圖所示，用戶請求到達負載均衡服務器114.100.20.200後，負載均衡服務器將數據包的目的MAC地址更改為00:1e:ec:bc:5e:03，並不修改數據包目的IP，由於服務器集群所有服務器的虛擬IP地址和負載均衡服務器IP地址一致，因此數據可以正常傳輸到達MAC地址為00:1e:ec:bc:5e:03的機器上，該服務器處理完之後，將響應數據包發送到網關服務器，網關服務器直接將數據包發送給用戶瀏覽器，響應數據不需要通過負載均衡服務器，這樣就避免了負載均衡服務器成為傳輸瓶頸的可能。
使用三角傳輸模式的鏈路層負載均衡是目前大型網站使用最為廣泛的一種負載均衡手段。在Linux平臺上最好的鏈路層負載均衡開源產品是LVS(Linux Virtual Server)。
負載均衡之IP
首先讓我們來看看下面這張大家都非常熟悉的TCP/IP協議族的分層圖：
關於每層在網絡數據包傳輸過程中所起到的作用不是本文的重點，本文主要是講解如何在網絡層中使用IP來做服務器集群的負載均衡，為什麽可以在這一層來做負載均衡。下面在來看IP協議的報頭格式：
內紅色框內的源地址和目的地址是IP負載均衡功能的關鍵所在，IP負載均衡又可以稱之為網絡層負載均衡，其核心原理就是通過內核驅動更改IP的目的地址來完成數據負載均衡的，如下圖：
如上圖所示，用戶請求數據包（源地址為200.110.50.1）到達負載均衡服務器114.100.20.200後，負載均衡服務器在內核進程獲取網絡數據包，根據一定的負載均衡算法得到一臺內部的真實服務器192.168.1.1，然後將數據包的目的IP修改為192.168.1.1，此後數據包將會被發往192.168.1.1的服務器上，服務器處理完後，將向負載均衡服務器返回相應的數據包，負載均衡服務器在把源地址修改為114.100.20.200後將數據包傳輸給用戶瀏覽器。在這一整個過程中，數據包沒有通過用戶的應用進程，因此該負載均衡的性能是非常之高的。
根據以上的圖和上文的講解，大家可能會覺得這很容易實現，其實不然，在這裏需要處理關鍵的地方就是如何將集群內部服務器處理完後的數據返回給負載均衡服務器。因為，用戶請求的數據包到達負載均衡服務器前的目的地址是114.100.20.200，源地址是200.110.50.1，通過負載均衡服務器修改後的目的地址是192.168.1.1，源地址還是200.110.50.1，所以處理後返回的數據包目的地址將是200.110.50.1，源地址是192.168.1.1，最終返回的數據包要回到負載均衡服務器就成了問題。解決的辦法大概有如下兩種：一、負載均衡服務器使用雙網卡，一個對內一個對外，在修改請求數據包的目的IP的同時也修改源地址，將源地址設為自身的IP，即源地址轉換（SNAT），這樣內部集群服務器響應會再回到負載均衡服務器；二、將負載均衡服務器作為真實物理服務器集群的網關服務器，這樣所有的響應都將通過負載均衡服務器。
IP負載均衡在內核進程完成數據分發，處理性能得到了很好的提高。但是由於所有請求和響應都要經過負載均衡服務器，集群的最大響應數據吞吐量將受到負載均衡服務器網卡帶寬的限制，對於提供下載服務或者視頻服務等需要大量傳輸數據的站點而言，這是難以滿足需求的。要是能讓響應數據包繞過負載均衡服務器直接發往用戶機器上就好了，有什麽辦法可以做到呢？當然有，那就是鏈路層的負載均衡，這將在下一博文中講解。
負載均衡之HTTP重定向
由於目前現有網絡的各個核心部分隨著業務量的提高，訪問量和數據流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的服務器設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬件升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提升時，這又將導致再一次硬件升級的高額成本投入，甚至性能再卓越的設備也不能滿足當前業務量增長的需求。 針對此情況而衍生出來的一種廉價有效透明的方法以擴展現有網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性的技術就是負載均衡（Load Balance）。
一個能夠提供高並發訪問，快速響應的服務器集群不是一開始就能設計出來的，但對於軟件架構師而言，在架構設計之初就要有應付這種高並發，為集群提供水平擴展的計劃，具體何時進行擴展，就需要在後續處理業務的過程中慢慢演化了。同時，在設計之初，為了能快速擴展而不影響集群的正常使用，建議把服務器設計成無狀態的，也就是集群服務器不存儲請求上下文信息，這樣用戶的請求被發往集群中的任何一個節點所處理的返回結果都將是一樣的。因此在集群中就可以使用負載均衡技術將不同的請求發往不同的節點上進行處理。如下圖：
負載均衡服務器需要能夠感知或者可以配置集群中的服務器數量，可以及時發現集群中新上線或者下線的服務器，並能向新上線的服務器分發請求，停止向已下線的服務器分發請求，這樣就實現了服務器集群的伸縮性。負載均衡的實現技術有多種多樣，從硬件實現到軟件實現，從商業產品到開源產品，應有盡有。本文主要介紹Web服務器中HTTP反向代理機制，以此來達到服務器之間的負載均衡。
利用HTTP重定向協議實現負載均衡大概工作原理如下圖：
HTTP重定向服務器是一臺普通的應用服務器，其唯一個功能就是根據用戶的HTTP請求計算出一臺真實的服務器地址，並將該服務器地址寫入HTTP重定向響應中（重定向響應狀態碼為302）返回給用戶瀏覽器。用戶瀏覽器在獲取到響應之後，根據返回的信息，重新發送一個請求到真實的服務器上。如上圖所示，瀏覽器訪問www.apusapp.com，DNS服務器解析到IP地址為114.100.20.200，即HTTP重定向服務器的IP地址。重定向服務器計根據某種負載均衡算法算出真實的服務器地址為114.100.20.203並返回給用戶瀏覽器，用戶瀏覽器得到返回後重新對114.100.20.203發起了請求，最後完成訪問。
這種負載均衡方案的有點是比較簡單，缺點是瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差；同時，重定向服務器本身的處理能力有可能成為瓶頸，整個集群的伸縮性規模有限；使用HTTP返回碼302重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。因此實踐中很少使用這種負載均衡方案來部署。
負載均衡(摘抄)