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

[[250711]]

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

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

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

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

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

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

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

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

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

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

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