負載均衡是高可用網路基礎架構的的一個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用伺服器部署多臺，然後通過負載均衡將使用者的請求分發到不同的伺服器用來提高網站、應用、資料庫或其他服務的效能以及可靠性。

為什麼要引入負載均衡

先看一個沒有負載均衡機制的web架構：

上圖中的架構有什麼缺陷了？首先，使用者是通過網路直接和web伺服器相連，想象一下，如果這個伺服器掛了（這種情況隨時都可能發生的)，那麼使用者的請求就會得不到響應，將無法訪問該網站，這就是著名的單點故障問題，這肯定是不行的，一般而言，商業上的網站其可靠性需要達到至少4個9，也就是99.99&以上。

其次，即使伺服器是正常工作的情況，但是如果很多

負載均衡的出現可以很好的解決上面兩個問題，通過引入一個負載均衡器和至少兩個web 伺服器，可以有效的解決上面兩個問題。注：通常情況下，所有的後端伺服器會保證提供相同的內容，以便使用者無論哪個伺服器響應，都能收到一致的內容。

如上圖架構，現在，即使App 01即使掛了，負載均衡會將使用者的請求轉發到正常工作的App 02上，這解決了上面的第一個問題；其次，根據業務需要，負載均衡後端的App可以很方便的擴充套件，這樣就能解決第上面的第二個問題。但是，現在單點故障問題轉移到了負載均衡器，可以通過引入第二個負載均衡器來緩解，後面還會講到。

負載均衡如何選擇要轉發的後端伺服器

負載均衡器一般根據兩個因素來決定要將請求轉發到哪個伺服器。

1：確保所選擇的後端伺服器是正常工作的，能給對使用者的請求做出響應；

2：根據預先設定的負載均衡演算法從健康伺服器池中進行選擇。

由於負載均衡器只應當選擇能正常做出響應的後端伺服器，因此就需要有一種機制能判斷它所連的後端伺服器是否正常工作。為了監視後臺伺服器的執行狀況，執行狀態檢查服務會定期嘗試使用轉發規則定義的協議和埠去連線後端伺服器。如果某個伺服器沒有通過健康檢查，就會從健康池中剔除，保證流量不會被轉發到該伺服器，直到其再次通過健康檢查為止。

負載均衡演算法

負載均衡演算法

輪詢：為第一個請求選擇健康池中的第一個後端伺服器，然後按順序往後依次選擇，直到最後一個，然後迴圈。

最小連線：優先選擇連線數最少，也就是壓力最小的後端伺服器，在會話較長的情況下可以考慮採取這種方式。

雜湊：根據請求源的 IP 的雜湊（hash）來選擇要轉發的伺服器。這種方式可以一定程度上保證特定使用者能連線到相同的伺服器。如果你的應用需要處理狀態而要求使用者能連線到和之前相同的伺服器，可以考慮採取這種方式。

最後，想要解決負載均衡器的單點故障問題，可以將第二個負載均衡器連線到第一個上，從而形成一個叢集。如下圖所示：

當主負載均衡器發生了故障，就需要將使用者請求轉到第二個負載均衡器。由於 DNS 更改通常會在較長的時間才能生效，因此需要有一種能靈活解決 IP 地址重新對映的方法，比如浮動 IP（floating IP）。這樣域名可以保持和相同的 IP 相關聯，而 IP 本身則能在伺服器之間移動。下面就是一個使用浮動 IP 的負載均衡架構動態示意圖：