負載均衡
環境: CentOS7、Nginx 1.16.0
1.什麼是負載均衡?
負載均衡是高可用網絡基礎架構的關鍵組件，通常用於將工作負載分佈到多個服務器來提高網站、應用、數據庫或其他服務的性能和可靠性。
一個沒有負載均衡的 web 架構類似下面這樣：
這種簡單的部署模型只適用於最初的簡單的網絡，而隨着業務的增多、客戶的海量請求，給服務端造成的極大的併發，這種單一的架構有着極大的缺點和風險。用戶是直連在web服務器上的，一旦這臺服務器宕機，用戶直接就無法訪問了。而且，一旦同時有許多用戶請求發向了這臺服務器，超過了其性能處理的極限，那麼就會出現加載緩慢或者無法訪問的情況。
而通過在後端引入一個負載均衡器和至少一個額外的 web 服務器，可以緩解這個故障。通常情況下，所有的後端服務器會保證提供相同的內容，以便用戶無論哪個服務器響應，都能收到一致的內容。
可以看出，當用戶進行請求訪問時，並不是直連web服務器，而是訪問到了中間的負載均衡器，再由負載均衡器經過轉發後到達web服務器，可能是App01,也可能是App02。這樣帶來的好處是，增大了web服務的承受能力，而且減小了癱瘓風險，當一臺web服務器宕機時，仍有另一臺可以處理請求，而對於客戶端，不用做出任何的改變。
負載均衡的關鍵技術
要做到負載均衡，需要的問題包括但不限於以下幾個方面
- 請求的分發
- 會話保持
- 服務健康監測
- 故障隔離
- 自動恢復
請求分發——負載均衡器如何選擇要轉發的後端服務器？
負載均衡器一般根據兩個因素來決定要將請求轉發到哪個服務器。首先，確保所選擇的服務器能夠對請求做出響應，然後根據預先配置的規則從健康服務器池（healthy pool）中進行選擇。
因爲，負載均衡器應當只選擇能正常做出響應的後端服務器，因此就需要有一種判斷後端服務器是否「健康」的方法。爲了監視後臺服務器的運行狀況，運行狀態檢查服務會定期嘗試使用轉發規則定義的協議和端口去連接後端服務器。如果，服務器無法通過健康檢查，就會從池中剔除，保證流量不會被轉發到該服務器，直到其再次通過健康檢查爲止。
爲了保證服務質量，需要定時進行健康檢測。我們可以利用ICMP、TCP、HTTP、FTP等協議進行檢測，即主要是在傳輸層和應用層進行檢測。
應用層的檢測顆粒更細，但對系統的要求也比較高，因爲需要針對應用層的不同的協議做不同的識別分發機制。應用層檢測用的比較多的就是HTTP協議，比如先和集羣中的設備建立連接，然後發出請求，如果收到正確應答，則說明HTTP處理正常。
傳輸層的檢測，主要在於能否建立TCP連接，迴響是否正常，等等。
知道了哪些後端服務器是健康的，那麼如何在其中做出選擇呢？
負載均衡算法決定了後端的哪些健康服務器會被選中。幾個常用的算法：
- **Round Robin（輪詢）：**爲第一個請求選擇列表中的第一個服務器，然後按順序向下移動列表直到結尾，然後循環。屬於靜態算法。
- **Least Connections（最小連接）：**優先選擇連接數最少的服務器，在普遍會話較長的情況下推薦使用。屬於動態算法
- **Source：**根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式可以一定程度上保證特定用戶能連接到相同的服務器。屬於靜態算法
如果你的應用需要處理狀態而要求用戶能連接到和之前相同的服務器。可以通過 Source 算法基於客戶端的 IP 信息創建關聯，或者使用粘性會話（sticky sessions）。
會話保持
出於一些業務的特殊要求，有時候需要進行會話保持，以保證一段時間內，某一個用戶與系統的交互（會話），只交給同一臺服務器處理。
例如，大多數電商應用需要用戶認證，而一次交易需要與服務器多次交互才能完成。這幾次交互必須由同一臺服務器處理，而不能被分散到不同服務器上。
會話保持有以下幾種方法：
- 源IP地址的持續性保持
- cookie 持續性保持
- 基於HTTP報文頭的持續性保持
最後，想要解決負載均衡器的單點故障問題，可以將第二個負載均衡器連接到第一個上，從而形成一個集羣。
當主負載均衡器發生了故障，就需要將用戶請求轉到第二個負載均衡器。因爲 DNS 更改通常會較長的時間才能生效，因此需要能靈活解決 IP 地址重新映射的方法，比如浮動 IP（floating IP）。這樣域名可以保持和相同的 IP 相關聯，而 IP 本身則能在服務器之間移動。
，因此需要能靈活解決 IP 地址重新映射的方法，比如浮動 IP（floating IP）。這樣域名可以保持和相同的 IP 相關聯，而 IP 本身則能在服務器之間移動。