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