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

[[250711]]

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

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

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

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

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

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

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

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

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

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

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