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

[[250711]]

由于現代應用程序架構高度分散的模式，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和應用路由的決定在很大程度上取決于應用程序架構和要求。 盡管在不同層面上效率不一樣，但兩者都可以達到擴展性。 這個討論超出了今天職位的范圍，但有權衡。

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