Web負載均衡

序：

    對Web站點擴展一開始不宜過早，除非是基於高可用性和就近部署的考慮。但對於架構師而言，在架構設計之初就要有擴展的計劃，關鍵是要清楚什麼時候進行擴展。這裏先介紹的是水平擴展，所謂的擴展是經過擴展規模來提高承載能力的本領。這種本領往體如今增長物理服務器或集羣節點，這種本領發揮強，可提高的承載空間越大，但每每也受到其它的約束好比單機的限制、成本等。

12.1 一些思考

    對於web站點的水平擴展，負載均衡是一種常見的手段。生活中典型的例子就是項目外包。

12.2 HTTP重定向

    Http重定向能夠將http請求進行轉移，通常用於自動跳轉，這種重定向由Http定義並由Http代理(如：瀏覽器)和Web服務器共同實現。正由於http重定向具有請求轉移和自動跳轉的本領，除了知足各類自動跳轉外，還能夠實現Web負載均衡達到web擴展的目的。

    鏡像下載就是Http重定向的典型案例。鏡像下載的目的就是實現負載均衡，通常也達到了就近訪問的目的，加快用戶下載速度，避免必定的帶寬浪費。經過不一樣的地域來源來轉移請求只是實現負載均衡的一種策略，但有些時候不必定合理。

    咱們須要權衡轉移請求的開銷和實際處理請求的開銷，前者對後者越小，那麼重定向的意義就越大。

    Http重定向受到主站點性能的制約，不過它的調度具備必定的靈活性，能夠經過Web程序實現調度策略。

12.3 DNS負載均衡

    DNS負責域名解析，若一個域名解析能夠對應多個IP地址，這時DNS服務器便充當了負載均衡調度器，將請求分散到多個服務器上，常見的策略是對多個A記錄進行RR(輪詢)。A記錄的功能就是將域名映射到指定的IP地址。

    和重定向相比，DNS負載均衡徹底節省了主站點或者說DNS服務器充當了主站點的職能，爲了提升此時DNS服務器的可用性，能夠同時使用多臺DNS服務器。DNS服務器能夠根據用戶IP進行智能解析，使其找到可用A記錄中離用戶最近的一臺服務器。當監測到某臺實際服務器出現故障後，可使用DNS動態協議來迅速修改DNS記錄，不過仍是有必定的延遲    

    DNS負載均衡工做在DNS層，或多或少具備必定的侷限性，好比實際服務器實時負載健康監測難等，DNS記錄緩存更新延遲等。

    所謂「均衡」不是指每臺實際服務器承擔的工做量或者說負載是同樣的，實際應該是能者多勞。

12.4 反向代理負載均衡

    反向代理服務器的核心工做就是轉發Http請求，工做在HTTP層，所以也稱爲七層負載均衡。反向代理服務器是轉發請求不是轉移，前面的都是轉移。

    在這種調度模式下，任何對實際服務器的請求都必須通過調度器，調度器必須等待實際服務器的響應並反饋給用戶。

    調度器能夠按權重分配任務給後端服務器，由於後端服務器的能力可能不同。按權重分配的配置在Nginx中使用weight參數定義，不少反向代理服務器還支持權重分配的RR調度策略。

    反向代理服務器自己的併發處理能力很重要，當反向代理服務器的吞吐率達到上限時，添加再多的後端服務器也無濟於事。反向代理服務器轉發操做自己具備必定的開銷如建立線程、與後端服務器創建TCP鏈接、接收後端服務器返回的結果、分析HTTP頭信息、用戶態和內核態的切換等。

    大多反向代理服務器自身能夠監測到後端服務器的健康情況如系統負載、響應時間、是否可用、TCP鏈接數、流量等。

    在實際應用中，咱們能夠備用必定數量的後端服務器，一旦某些後端服務器出現故障可使用備用服務器進行替換提供服務。

    使用RR調度策略時即便是同一用戶對同一內容的屢次請求有多是被轉發到不一樣的後端服務器上，這樣就會產生後端服務器本地Session不一樣步及緩存利用率降低的問題。

    解決Session一致的問題可使用在必定Session週期內使同一個用戶的請求始終轉發到同一臺後端服務器，要設計持續性調度算法，好比對用戶的IP進行hash計算或使用Cookie持久性算法。

    固然，在後端服務器本地上保存Session和緩存並非一個明智的選擇，這樣會致使爲了保證Session一致等狀況沒法作到讓後端服務器承擔不一樣的權重。應該使用分佈式的Session(多臺Session服務器)和分佈式緩存。

    反向代理服務器因爲自己開銷大等緣由存在擴展性差，性能受到極限等限制。

12.5 IP負載均衡

    網絡地址轉換(NAT)負載均衡工做在傳輸層，對數據包中的IP地址和端口進行修改，從而達到轉發的目的，稱爲四層負載均衡。

    NAT是使用用戶處在內部網絡卻能夠與互聯網進行通訊。而反向NAT就是將實際服務器放於內部網絡，將用戶的數據包轉發給內部的後端服務器。

    在Linux中修改IP數據包可經過Netfilter，Netfilter工做在內核中，咱們能夠經過iptables在用戶態對內核態的Netfilter的過濾表進行操做如刪除、插入和修改等，iptables最經常使用的應用場合就是防火牆了。

    路由器的工做就是存儲轉發，修改數據包的MAC地址。而這裏說的路由器就是要修改數據包的來源地址和端口或目標地址和端口。

    NAT服務器必須做爲實際服務器的網關，不然數據包被轉發後將一去不返。

    IPVS不只能夠實現基於NAT的負載均衡，還能夠實現直接路由和IP隧道等負載均衡。IPVS的管理工具是ipvsadm，也稱爲LVS。

    RR是靜態調度策略，LVS除了支持RR外，還支持許多動態調度策略如最小鏈接、帶權重的最小鏈接、最短時間望時間延遲等。

    NAT服務器將會制約集羣擴展，它不只要轉發用戶的請求給實際服務器，也要將實際服務器的響應轉發給用戶，顯然它將會是一個瓶頸。解決這個瓶頸的簡單辦法是提升 NAT服務器的帶寬或將基於NAT的集羣和DNS的RR混合使用或使用直接路由等負載均衡方式。

12.6 直接路由

    這種方式工做在數據鏈路層。它修改數據包的目標MAC地址，並無修改目標IP，而後發給實際的服務器，實際服務器的響應數據直接發回給用戶，而不用通過調度器。但實際服務器必須接入外網，並且不能將調度器做爲默認網關，要給實際服務器添加和調度器IP地址相同的IP別名。

    一個物理網卡擁有一個IP地址，但能夠爲它配置更多個IP，這裏配置的IP就是IP別名。一個網卡接口最多能夠設置256個IP別名。

    使用直接路由轉發無需修改數據包的目的端口，由於這種轉發工做在數據鏈路層，它對上層端口無能爲力。

   越是響應數據包遠遠超過請求數據包的服務就越應該下降調度器轉移請求的開銷，也就越能提升總體擴展能力，最終也就越依賴於WAN的出口帶寬。

    LVS－DR很是適合搭建可擴展有負載均衡系統，不管是web服務器仍是文件服務器以及視頻服務器，都有不錯的出色表現。

12.7 IP隧道

    基於IP隧道的負載均衡系統也可使用LVS來實現，稱爲LVS－TUN，與LVS－DR不一樣的是，實際服務器和調度器能夠不在同一個WAN網段，調度器經過IP隧道技術來轉發請求到實際服務器，因此實際服務器必須有合法的IP地址。

    基於IP隧道的請求轉發機制是將調度器收到的IP數據包封裝在一個新的IP數據包中，轉交給實際服務器，而後實際服務器的響應數據包能夠直接到達用戶端。

    要使用IP隧道則全部的服務器必須支持IP隧道協議。基於IP隧道的獨特方式，能夠將實際服務器部署在不一樣的地域並根據就近原則轉移請求，好比一些CDN服務器就是基於IP隧道技術實現的。

12.8 考慮可用性

    在負載均衡系統中多臺服務器分散開銷的同時，自己也提升了實際服務器的可用性。爲避免大量的請求形成的血崩效應，通常將實際服務器的數量大於實際數目。爲實現調度器的故障平滑轉移，保證調度器的可用性，可使用heartbeat解決這個問題，即準備備用調度器，作到出故障時進行替換。