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

[[250711]]

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

負載均衡旨在通過水平擴展實現(xiàn)可用性。要擴展應用程序，負載均衡器會通過分發(fā)請求到應用程序(或服務)的池(服務器群，集群等)。 哪個池成員對請求做出響應的決定是基于一種算法。 該算法對于所選擇的池成員是能夠響應還是能夠?qū)ζ錄Q策進行“智能化”，對響應時間，當前負載進行分解，甚至基于上述所有權(quán)重決策，可能是相當準確的。 這是現(xiàn)有的最基本的負載均衡模式。 自1996年以來，它一直是可用性(規(guī)模和故障轉(zhuǎn)移)的基礎(chǔ)。

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

現(xiàn)在，應用路由則是完全不同的。 首先，它要求系統(tǒng)關(guān)心應用程序及其協(xié)議。 這是因為為了路由應用程序請求，必須首先能夠識別目標。 這個標識可以像“什么是主機名”一樣復雜，像“JSON對象或XML元素形式的有效內(nèi)容隱藏的元素的價值是多少”。 最通用的是應用程序標識符 - URI。

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

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

了解應用路由和負載均衡之間的區(qū)別的原因之一(除了我的迂腐性質(zhì))是兩者不可互換。 路由決定在哪里轉(zhuǎn)發(fā)某些內(nèi)容 - 數(shù)據(jù)包，應用程序請求，以及業(yè)務流程中的批準。 負載均衡將一些(數(shù)據(jù)包，請求，批準)分配到一組旨在處理該事物的資源。 你真的不能(不應該)替換另一個。 但這也意味著你可以自由地混合和匹配這兩者之間相互作用的方式。

例如，您可以使用簡單的舊負載均衡(POLB)進行入口負載均衡，然后使用應用程序路由(第7層)分發(fā)請求(可能在容器集群內(nèi))。 您還可以切換，并使用應用程序路由進入流量，通過應用程序架構(gòu)中的POLB進行分發(fā)。

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

關(guān)于使用POLB和應用路由的決定在很大程度上取決于應用程序架構(gòu)和要求。 盡管在不同層面上效率不一樣，但兩者都可以達到擴展性。 這個討論超出了今天職位的范圍，但有權(quán)衡。

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