當一個網站變得非常流行時，網站上的流量增加，單個服務器的負載也增加。并發流量超過單個服務器的處理能力，導致網站變得對用戶響應緩慢。為了應對這些高數據量的請求，以快速可靠的方式返回正確的響應，我們需要對服務器進行擴展。這可以通過向網絡中添加更多的服務器，并將所有請求分布到這些服務器上來實現。但是...誰來決定將哪個請求路由到哪個服務器呢...???
Load-Balancer-System-Design-Interview.png
答案是...負載均衡器。讓我們詳細了解一下負載均衡器的概念...
什么是負載均衡器？
負載均衡器就像站在服務器前面的“交通警察”，將客戶端請求分配到所有服務器上。它會有效地分發一組請求操作（如數據庫寫請求、緩存查詢）到多個服務器上，并確保沒有任何單個服務器承受過多的請求，從而降低應用程序的整體性能。負載均衡器可以是一個物理設備，也可以是運行在專用硬件上的虛擬實例，或者是一個軟件進程。
考慮一個場景，一個應用程序在單個服務器上運行，客戶端直接連接到該服務器而沒有負載均衡。它看起來可能像下面這樣...
我們需要討論一下這種模型的兩個主要問題...
•單點故障：如果服務器崩潰或出現問題，整個應用程序將中斷，對用戶在一段時間內不可用。這會給用戶創建一個不良的體驗，這對于服務提供商來說是不可接受的。•服務器過載：一個Web服務器可以處理的請求數量是有限的。如果業務增長，請求數量增加，服務器將會過載。為了解決不斷增加的請求，我們需要添加更多的服務器，并將請求分發到這些服務器集群上。
為了解決上述問題，并分發請求的數量，我們可以在Web服務器前添加負載均衡器，通過將請求分發到多個服務器上，允許我們的服務通過在網絡中添加任意數量的Web服務器來處理任何數量的請求。我們可以將請求分散到多個服務器上。如果由于某種原因，其中一個服務器下線，服務仍將繼續。此外，每個請求的延遲將降低，因為每個服務器不再受限于RAM/磁盤/CPU。
•負載均衡器可以最小化服務器響應時間，最大化吞吐量。•負載均衡器通過僅將請求發送到在線服務器，確保高可用性和可靠性。•負載均衡器進行持續的健康檢查，監視服務器處理請求的能力。•根據請求數量或需求，負載均衡器添加或刪除服務器數量。
負載均衡器通常放置在哪里？
下面是負載均衡器可能放置的位置的圖示...
•客戶端應用程序/用戶和服務器之間•服務器和應用程序/作業服務器之間•應用程序服務器和緩存服務器之間•緩存服務器和數據庫服務器之間
負載均衡器的類型
我們可以通過三種方式實現負載均衡。它們是...
1. 客戶端中的軟件負載均衡器
顧名思義，所有負載均衡的邏輯位于客戶端應用程序中（例如移動應用程序）。應用程序將獲得要與之交互的一組Web服務器/應用程序服務器的列表。應用程序選擇列表中的第一個服務器，并請求從服務器獲取數據。如果持續出現故障（在可配置的重試次數之后）且服務器變得不可用，則丟棄該服務器并選擇列表中的其他服務器以繼續處理過程。這是實施負載均衡的一種較便宜的方法。
2. 服務中的軟件負載均衡器
這些負載均衡器是一種接收一組請求并根據一組規則重定向這些請求的軟件。這種負載均衡器提供了更大的靈活性，因為它可以安裝在任何標準設備上（例如windows或linux機器）。它也更便宜，因為無需購買或維護物理設備，與硬件負載均衡器不同。您可以選擇使用
現成的軟件負載均衡器，也可以編寫自己的自定義軟件（例如，為Microsoft office365的負載均衡負載活動目錄查詢）。
3. 硬件負載均衡器
顧名思義，我們使用物理設備來將流量分布到網絡服務器的集群中。這些負載均衡器也稱為第4-7層路由器，可以處理各種HTTP、HTTPS、TCP和UDP流量。HLD（硬件負載均衡器）為外部世界提供虛擬服務器地址。當來自客戶端應用程序的請求到達時，它將連接轉發到最適合的實際服務器，執行雙向網絡地址轉換（NAT）。HLD可以處理大量的流量，但價格昂貴，靈活性有限。
HLD會持續對每個服務器進行健康檢查，確保每個服務器都能正確響應。如果任何服務器沒有產生期望的響應，它會立即停止向服務器發送流量。這些負載均衡器難以獲取和配置，這就是很多服務提供商只將它們用作用戶請求的第一個入口點的原因。隨后，內部軟件負載均衡器用于將數據重定向到基礎設施墻后面。
負載均衡的不同類別
通常，負載均衡器分為三個類別...
1. 第4層（L4）負載均衡器
在OSI模型中，第4層是傳輸層（TCP/SSL），路由決策在此層進行。第4層負載均衡器也稱為網絡負載均衡器，顧名思義，它利用網絡層信息來進行流量路由決策。它可以控制每秒數百萬次的請求，并處理所有形式的TCP/UDP流量。決策將基于數據包使用的TCP或UDP端口以及其源和目標IP地址。第4層負載均衡器還對請求數據包執行網絡地址轉換（NAT），但它不會檢查每個數據包的實際內容。這種負載均衡器的類別通過將流量分布到IP地址、交換機和路由器上來最大化利用率和可用性。
2. 第7層（L7）負載均衡器
第7層負載均衡器也稱為應用程序負載均衡器或HTTP（S）負載均衡器。這是最古老的負載均衡形式之一。在OSI模型中，第7層是應用層（HTTP/HTTPS），路由決策在此層執行。第7層添加了內容切換以進行負載均衡，它使用諸如HTTP頭、Cookie、統一資源標識符、SSL會話ID和html表單數據等信息來決定路由請求的服務器。
3. 全局服務器負載均衡（GSLB）
如今，許多應用程序在多個地理位置的云數據中心中托管。這是很多組織轉向不同負載均衡器的原因，它可以以更大的可靠性和較低的延遲向任何設備或位置交付應用程序。隨著負載均衡器功能的顯著變化，GSLB滿足了IT組織的這些期望。GSLB在不同地理位置擴展了L4和L7服務器的功能，并有效地分發大量流量到多個數據中心。在用戶在數字工作空間中導航多個應用程序和服務時，它還確保了一致的用戶體驗。
負載均衡算法
我們需要一種負載均衡算法來決定將哪個請求重定向到哪個后端服務器。不同的系統使用不同的方式從負載均衡器中選擇服務器。根據配置，公司使用各種負載均衡算法技術。以下是一些常見的負載均衡算法：
1. 輪詢法（Round Robin）
請求在服務器之間按順序或輪換方式分發。例如，第一個請求發送到第一個服務器，第二個請求發送到第二個服務器，第三個請求發送到第三個服務器，依此類推，對所有請求進行處理。這種方法容易實現，但它不考慮服務器上的負載，因此存在一個風險，即一個服務器接收到大量請求并變得過載。
2. 加權輪詢法（Weighted Round Robin）
這與輪詢技術非常相似。唯一的區別在于，列表中的每個資源都被賦予加權分數。根據加權分數，請求將分發到這些服務器。因此，在這種方法中，一些服務器獲得整體請求的較大份額。
3. 最少連接法（Least Connection Method）
在此方法中，請求將被定向到具有最少請求或活動連接數量的服務器。為了執行此操作，負載均衡器需要進行一些額外的計算，以識別具有最少連接數的服務器。與輪詢方法相比，這可能會稍微昂貴一些，但評估是基于服務器上的當前負載。當在流量在服務器之間不均勻分布時，這種算法非常有用。
4. 最短響應時間法（Least Response Time Method）
這種技術比最少連接法更復
雜。在這種方法中，請求將被轉發到具有最少活動連接和最少平均響應時間的服務器。服務器的響應時間代表了服務器的負載和整體預期用戶體驗。
5. 源IP哈希（Source IP Hash）
在這種方法中，請求將根據客戶端的IP地址發送到服務器。客戶端的IP地址和接收計算實例的IP地址將使用密碼算法進行計算。
