企業在云計算中遇到的三種負載均衡
負載均衡幾乎與全球互聯網同時出現。傳入的數據包、連接和請求從網絡層到TCP到HTTP，通常在資源之間分布，以確保應用性能和可用性。
這些差異可能看起來微不足道，但實際上它們非常重要，因為這些將直接影響企業可以實現的部署模式類型。畢竟，如果企業對于HTTP沒有可見性，就不能采用更多依賴于URI或內容類型的高級模式。
所有的負載均衡都需要決定轉發分組/請求的位置，這就是網絡、連接和應用程序負載均衡之間的區別變得重要的地方。每個人都根據可能導致或阻礙企業實施特定類型的部署模式的特征做出決策。
適當的網絡負載均衡依賴于網絡層信息。而源端和目標端IP以及TCP端口(在某些情況下)構成決策的基礎。
當網絡負載均衡服務收到請求時，它通常會散列源端IP和目標端IP(以及TCP端口)，然后選擇目標資源。這個請求然后被發送到資源。
網絡負載均衡具有作為所有負載均衡算法中最快決策者的優勢，但它具有不能平衡流量的缺點。這意味著網絡負載均衡(NLB)更關心路由流量，而不是跨資源平衡流量。它會進行嘗試，但有些情況下會因為“超級代理”問題而失敗。
當大量流量來自同一范圍的網絡地址時，就會出現超級代理問題。這會導致所有流量發送到相同的資源，因為散列變量之間沒有足夠的分化來分配多個資源。精明的開發人員會認識到這是一個沖突，這是基于哈希算法的常見問題。由于性能受到目標資源負載的影響，其沖突問題更加惡化。隨著負載的增加(在任何系統上)，其性能會下降。
所以，如果企業打算使用這種消費，可能會經歷糟糕的分布，并因此表現不佳。這是因為大多數企業流量都來自同一個范圍的IP地址。然而，對于消費者來說，這不應該是一個問題。
企業也無法根據應用程序(或API)版本引導流量，也無法使用它來分割跨多個服務的API流量，因為它無法考慮基于HTTP的變量(如URI或Cookie)。
簡單舊式負載均衡(POLB)是負載均衡的原始形式，其中企業所熟悉的實際負載均衡算法發揮作用。輪詢調度(Round Robin)、最少連接(Least Connections)、最快回應(Fastest Response)都是至今仍在使用的大規模算法。
POLB是基于協議的，支持UDP(用于流式傳輸)和TCP(面向連接)。它的決定基于所選擇的算法，僅此而已。
簡單舊式負載均衡(POLB)接收請求，并根據算法從資源池(有時稱為服務器場或集群)中選擇資源。然后，它轉發請求，然后退出。
這種負載均衡的好處是速度相對較快，并有多種算法選項可供選擇。如果性能至關重要，請選擇最快回應(Fastest Response)。如果企業只想快速輕松地進行擴展，請選擇輪詢調度(Round Robin)。
簡單舊式負載均衡(POLB)的缺點是，如果決策基于HTTP標頭中的某些內容(如cookie或URI)，則只能實現部署模式。根據負載均衡服務，企業可以使用諸如時間或計數器之類的變量來實現A/B測試等模式，以確定選擇哪個資源。它不一定像使用HTTP負載均衡一樣簡易，但仍然可以獲得相同的結果。
簡單舊式負載均衡(POLB)可能是透明的，也可能是不透明的，具體取決于配置。使用網絡負載均衡(NLB)，企業可以確信其應用程序接收的客戶端(用戶和設備)的IP地址是客戶端的實際IP地址。使用POLB的一些配置，企業的應用程序收到的IP地址實際上是提供負載均衡服務的代理的IP地址。這意味著其應用程序需要更多的工作來挖掘真實的客戶端IP地址。所以如果企業需要這些信息，應該知道它可能需要在HTTP標題中挖掘才能找到它。
HTTP負載均衡需要HTTP請求，并且在大多數實踐中實際上做出兩個不同的決定：***個基于HTTP變量，第二個基于算法。
為了準確，HTTP負載均衡實際上是路由和轉發的組合。也就是說，它首先路由請求，然后根據資源的算法選擇轉發請求。這就是像Canary和Blue/Green Deployments這樣的部署模式以及更強大的A/B測試。
這種類型的負載均衡問題在于它增加了等式的延遲。對HTTP請求越深入，延遲越多。一些負載均衡器具有“快速”模式，只允許基于HTTP標頭進行負載均衡，以糾正此問題，但請注意，如果試圖根據某個POST變量做出決定，該變量隱藏在HTTP負載的深處，這需要更多時間做決定。
另一個問題與簡單舊式負載均衡(POLB)分享，即透明度。企業可能會也有可能不會收到每個請求的客戶端的實際IP地址，因此請務必檢查其應用中是否需要該信息。
選擇企業的負載均衡，以便在規模和速度方面與其應用架構和特定目標相匹配。選擇錯誤的負載均衡和算法可能會對企業實現這些目標的能力產生重大影響。
