負載均衡幾乎與全球互聯(lián)網(wǎng)同時出現(xiàn)。傳入的數(shù)據(jù)包、連接和請求從網(wǎng)絡(luò)層到TCP到HTTP，通常在資源之間分布，以確保應(yīng)用性能和可用性。

這些差異可能看起來微不足道，但實際上它們非常重要，因為這些將直接影響企業(yè)可以實現(xiàn)的部署模式類型。畢竟，如果企業(yè)對于HTTP沒有可見性，就不能采用更多依賴于URI或內(nèi)容類型的高級模式。

[[226642]]

所有的負載均衡都需要決定轉(zhuǎn)發(fā)分組/請求的位置，這就是網(wǎng)絡(luò)、連接和應(yīng)用程序負載均衡之間的區(qū)別變得重要的地方。每個人都根據(jù)可能導致或阻礙企業(yè)實施特定類型的部署模式的特征做出決策。

適當?shù)木W(wǎng)絡(luò)負載均衡依賴于網(wǎng)絡(luò)層信息。而源端和目標端IP以及TCP端口(在某些情況下)構(gòu)成決策的基礎(chǔ)。

當網(wǎng)絡(luò)負載均衡服務(wù)收到請求時，它通常會散列源端IP和目標端IP(以及TCP端口)，然后選擇目標資源。這個請求然后被發(fā)送到資源。

網(wǎng)絡(luò)負載均衡具有作為所有負載均衡算法中最快決策者的優(yōu)勢，但它具有不能平衡流量的缺點。這意味著網(wǎng)絡(luò)負載均衡(NLB)更關(guān)心路由流量，而不是跨資源平衡流量。它會進行嘗試，但有些情況下會因為“超級代理”問題而失敗。

當大量流量來自同一范圍的網(wǎng)絡(luò)地址時，就會出現(xiàn)超級代理問題。這會導致所有流量發(fā)送到相同的資源，因為散列變量之間沒有足夠的分化來分配多個資源。精明的開發(fā)人員會認識到這是一個沖突，這是基于哈希算法的常見問題。由于性能受到目標資源負載的影響，其沖突問題更加惡化。隨著負載的增加(在任何系統(tǒng)上)，其性能會下降。

所以，如果企業(yè)打算使用這種消費，可能會經(jīng)歷糟糕的分布，并因此表現(xiàn)不佳。這是因為大多數(shù)企業(yè)流量都來自同一個范圍的IP地址。然而，對于消費者來說，這不應(yīng)該是一個問題。

企業(yè)也無法根據(jù)應(yīng)用程序(或API)版本引導流量，也無法使用它來分割跨多個服務(wù)的API流量，因為它無法考慮基于HTTP的變量(如URI或Cookie)。

簡單舊式負載均衡(POLB)是負載均衡的原始形式，其中企業(yè)所熟悉的實際負載均衡算法發(fā)揮作用。輪詢調(diào)度(Round Robin)、最少連接(Least Connections)、最快回應(yīng)(Fastest Response)都是至今仍在使用的大規(guī)模算法。

POLB是基于協(xié)議的，支持UDP(用于流式傳輸)和TCP(面向連接)。它的決定基于所選擇的算法，僅此而已。

簡單舊式負載均衡(POLB)接收請求，并根據(jù)算法從資源池(有時稱為服務(wù)器場或集群)中選擇資源。然后，它轉(zhuǎn)發(fā)請求，然后退出。

這種負載均衡的好處是速度相對較快，并有多種算法選項可供選擇。如果性能至關(guān)重要，請選擇最快回應(yīng)(Fastest Response)。如果企業(yè)只想快速輕松地進行擴展，請選擇輪詢調(diào)度(Round Robin)。

簡單舊式負載均衡(POLB)的缺點是，如果決策基于HTTP標頭中的某些內(nèi)容(如cookie或URI)，則只能實現(xiàn)部署模式。根據(jù)負載均衡服務(wù)，企業(yè)可以使用諸如時間或計數(shù)器之類的變量來實現(xiàn)A/B測試等模式，以確定選擇哪個資源。它不一定像使用HTTP負載均衡一樣簡易，但仍然可以獲得相同的結(jié)果。

簡單舊式負載均衡(POLB)可能是透明的，也可能是不透明的，具體取決于配置。使用網(wǎng)絡(luò)負載均衡(NLB)，企業(yè)可以確信其應(yīng)用程序接收的客戶端(用戶和設(shè)備)的IP地址是客戶端的實際IP地址。使用POLB的一些配置，企業(yè)的應(yīng)用程序收到的IP地址實際上是提供負載均衡服務(wù)的代理的IP地址。這意味著其應(yīng)用程序需要更多的工作來挖掘真實的客戶端IP地址。所以如果企業(yè)需要這些信息，應(yīng)該知道它可能需要在HTTP標題中挖掘才能找到它。

HTTP負載均衡需要HTTP請求，并且在大多數(shù)實踐中實際上做出兩個不同的決定：***個基于HTTP變量，第二個基于算法。

為了準確，HTTP負載均衡實際上是路由和轉(zhuǎn)發(fā)的組合。也就是說，它首先路由請求，然后根據(jù)資源的算法選擇轉(zhuǎn)發(fā)請求。這就是像Canary和Blue/Green Deployments這樣的部署模式以及更強大的A/B測試。

這種類型的負載均衡問題在于它增加了等式的延遲。對HTTP請求越深入，延遲越多。一些負載均衡器具有“快速”模式，只允許基于HTTP標頭進行負載均衡，以糾正此問題，但請注意，如果試圖根據(jù)某個POST變量做出決定，該變量隱藏在HTTP負載的深處，這需要更多時間做決定。

另一個問題與簡單舊式負載均衡(POLB)分享，即透明度。企業(yè)可能會也有可能不會收到每個請求的客戶端的實際IP地址，因此請務(wù)必檢查其應(yīng)用中是否需要該信息。

選擇企業(yè)的負載均衡，以便在規(guī)模和速度方面與其應(yīng)用架構(gòu)和特定目標相匹配。選擇錯誤的負載均衡和算法可能會對企業(yè)實現(xiàn)這些目標的能力產(chǎn)生重大影響。