負載均衡是高可用網絡基礎架構的的一個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用服務器部署多臺，然後通過負載均衡將用戶的請求分發到不同的服務器用來提高網站、應用、數據庫或其他服務的性能以及可靠性。
爲什麼要引入負載均衡
先看一個沒有負載均衡機制的web架構：
上圖中的架構有什麼缺陷了？首先，用戶是通過網絡直接和web服務器相連，想象一下，如果這個服務器掛了（這種情況隨時都可能發生的)，那麼用戶的請求就會得不到響應，將無法訪問該網站，這就是著名的單點故障問題，這肯定是不行的，一般而言，商業上的網站其可靠性需要達到至少4個9，也就是99.99&以上。
其次，即使服務器是正常工作的情況，但是如果很多用戶在同一時間內訪問服務器，超過了服務器的處理能力，那麼會出現響應速度慢甚至無法連接的情況，這也是用戶無法接受的。
負載均衡的出現可以很好的解決上面兩個問題，通過引入一個負載均衡器和至少兩個web 服務器，可以有效的解決上面兩個問題。注：通常情況下，所有的後端服務器會保證提供相同的內容，以便用戶無論哪個服務器響應，都能收到一致的內容。
如上圖架構，現在，即使App 01即使掛了，負載均衡會將用戶的請求轉發到正常工作的App 02上，這解決了上面的第一個問題；其次，根據業務需要，負載均衡後端的App可以很方便的擴展，這樣就能解決第上面的第二個問題。但是，現在單點故障問題轉移到了負載均衡器，可以通過引入第二個負載均衡器來緩解，後面還會講到。
負載均衡如何選擇要轉發的後端服務器
負載均衡器一般根據兩個因素來決定要將請求轉發到哪個服務器。
1：確保所選擇的後端服務器是正常工作的，能給對用戶的請求做出響應；
2：根據預先設置的負載均衡算法從健康服務器池中進行選擇。
由於負載均衡器只應當選擇能正常做出響應的後端服務器，因此就需要有一種機制能判斷它所連的後端服務器是否正常工作。爲了監視後臺服務器的運行狀況，運行狀態檢查服務會定期嘗試使用轉發規則定義的協議和端口去連接後端服務器。如果某個服務器沒有通過健康檢查，就會從健康池中剔除，保證流量不會被轉發到該服務器，直到其再次通過健康檢查爲止。
負載均衡算法
負載均衡算法決定了後端的哪些健康服務器會被選中。下面是幾個常用的算法，這裏只是簡單介紹，不具體研究其算法實現了，後面會專門用一篇文章來總結：
輪詢：爲第一個請求選擇健康池中的第一個後端服務器，然後按順序往後依次選擇，直到最後一個，然後循環。
最小連接：優先選擇連接數最少，也就是壓力最小的後端服務器，在會話較長的情況下可以考慮採取這種方式。
散列：根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器。如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器，可以考慮採取這種方式。
最後，想要解決負載均衡器的單點故障問題，可以將第二個負載均衡器連接到第一個上，從而形成一個集羣。如下圖所示：
當主負載均衡器發生了故障，就需要將用戶請求轉到第二個負載均衡器。由於 DNS 更改通常會在較長的時間才能生效，因此需要有一種能靈活解決 IP 地址重新映射的方法，比如浮動 IP（floating IP）。這樣域名可以保持和相同的 IP 相關聯，而 IP 本身則能在服務器之間移動。下面就是一個使用浮動 IP 的負載均衡架構動態示意圖：
