淺析負載均衡與應用路由

負載均衡和應用路由可能由同一服務提供，但是它們彼此有一些關鍵的區別和不同的目的。

由於現代應用程式架構高度分散的模式，DevOps和NetOps(網路運維)之間的界限變得模糊不清，因此需要了解負載均衡和應用路由之間的區別。 它們是不一樣的，即使它們可能由同一服務提供。

負載均衡旨在通過水平擴充套件實現可用性。要擴充套件應用程式，負載均衡器會通過分發請求到應用程式(或服務)的池(伺服器群，叢集等)。 哪個池成員對請求做出響應的決定是基於一種演算法。 該演算法對於所選擇的池成員是能夠響應還是能夠對其決策進行“智慧化”，對響應時間，當前負載進行分解，甚至基於上述所有權重決策，可能是相當準確的。 這是現有的最基本的負載均衡模式。 自1996年以來，它一直是可用性(規模和故障轉移)的基礎。

這種負載均衡是我們經常(喜歡的)稱為“笨蛋”。 這是因為它幾乎總是基於TCP(OSI堆疊的第4層)。 像蜂蜜獾一樣，它根本不在乎應用程式(或其協議)。 所有它擔心的是接收TCP連線請求並將其與適當池中的其中一個成員進行匹配。 這不一定是有效的，但天啊，它是有效的，它的運作良好。 系統已經發展到專門設計的軟體，除了負載均衡之外，還可以同時管理數百萬個連線。 真的很驚奇，如果你完全知道，早在2000年代初，大多數系統只能處理數千個併發請求的順序。

現在，應用路由則是完全不同的。 首先，它要求系統關心應用程式及其協議。 這是因為為了路由應用程式請求，必須首先能夠識別目標。 這個標識可以像“什麼是主機名”一樣複雜，像“JSON物件或XML元素形式的有效內容隱藏的元素的價值是多少”。 最通用的是應用程式識別符號 - URI。

應用“路由”可以通過檢查其路徑並提取某些片段從URI中推匯出來。 這類似於Express中的路由(流行的node.js API框架之一)。 形式為：/ user / profile / xxxxx(其中xxxxx是實際使用者名稱或帳號)的URI路徑可以拆分並用於將請求“路由”到用於負載均衡的特定池或指定的成員 (應用/服務例項)。 這種情況發生在使用某種策略或程式碼的負載均衡器的“虛擬伺服器”結構中。

應用路由發生在負載均衡決定之前。 實際上，應用程式路由使單個負載均衡器能夠在多個應用程式或服務中智慧地分發請求。 如果您將現有的基於微服務的應用程式與API(表示特定請求的URI)結合使用，您可以看到這種功能如何變得有用。 API可以表示為客戶端的單個域(api.example.com)，但在幕後，實際上由使用應用路由和負載均衡的組合單獨調整的多個應用程式或服務組成。

瞭解應用路由和負載均衡之間的區別的原因之一(除了我的迂腐性質)是兩者不可互換。 路由決定在哪裡轉發某些內容 - 資料包，應用程式請求，以及業務流程中的批准。 負載均衡將一些(資料包，請求，批准)分配到一組旨在處理該事物的資源。 你真的不能(不應該)替換另一個。 但這也意味著你可以自由地混合和匹配這兩者之間相互作用的方式。

例如，您可以使用簡單的舊負載均衡(POLB)進行入口負載均衡，然後使用應用程式路由(第7層)分發請求(可能在容器叢集內)。 您還可以切換，並使用應用程式路由進入流量，通過應用程式架構中的POLB進行分發。

負載均衡和應用路由也可以分層，以實現可用性和規模方面的具體目標。 我更喜歡在入口處使用應用程式路由，因為它可以實現更加多樣化和細粒度的實現運維和應用程式架構更支援現代部署模式。

關於使用POLB和應用路由的決定在很大程度上取決於應用程式架構和要求。 儘管在不同層面上效率不一樣，但兩者都可以達到擴充套件性。 這個討論超出了今天職位的範圍，但有權衡。

縮放應用程式的關鍵是架構而不是演算法。 瞭解應用路由和負載均衡的差異應為設計高可擴充套件架構提供堅實的基礎。