大業務上雲，難免要用到LB。可是，您是否了解LB的來龍去脈？本文淺談一下LB，從硬件走到軟件，他們經歷了什麽轉變。

幾年前，剛接觸網絡的時候，就聽過一個稱呼：四層交換。

四層交換，顧名思義，就是基於傳輸層的TCP/UDP協議進行數據交換的，利用端口信息區分報文，可進行數據包過濾、服務質量（QoS）、負載均衡、主機備用連接、統計和報告等。而我們使用最頻繁的，便是負載均衡（LB）。

盒子時代，業界最出名的三家四層交換廠商：F5、citrix、radware。至今還稱霸著負載均衡的市場。

四層交換在負載均衡另有，主要提供三大類負載均衡服務：

l LSLB：Local Server Load Balance

l GSLB：Global Service Load Balance

l LLB：Link Load Balance

LSLB（本地負載均衡）：給本地集群部署的多臺服務器提供流量負載分擔能力。應用的V-IP在四層交換上，四層交換根據配置的負載均衡算法和會話保持算法分發給後端服務區。

這裏提到2個概念，負載均衡算法和會話保持算法

負載均衡算法：即流量到了LB以後，應該分給誰，常見的算法有輪詢、最小用戶數、最小流量、哈希等

會話保持算法：首包通過負載均衡算法確定發給具體那一臺後端以後，要生成session，以指導後續報文轉發。而生成的session可以根據配置只記錄某些信息，比如只記錄源地址而不紀錄端口，這樣相同的源的不同請求（源port不一樣）也會發給相同的後端

GSLB（全局負載均衡）：應用在多站點部署，GSLB可根據訪問者的位置，提供就近接入能力。其實GSLB更多地是一種DNS重定向能力。

如圖，訪問者在廣州，要去訪問www.huawei.Com，請求本地DNS解析時，DNS通過遞歸查詢發現域名是托管在GSLB的，於是向GSLB發出申請，GSLB通過測試自己到DNS的延遲，識別出來廣州站點離用戶最近，於是將廣州的IP地址返回給用戶。用戶請求被重定向給廣州站點。

LLB（鏈路負載均衡）：當訪問一個應用，有多條線路可以同時到達時，LLB會提供線路優選，根據訪問者或者線路的負載情況選擇最有線路。常用於優選電信和聯通都存在線路接入的場景

這幾種負載均衡場景，都是IT行業裏最普遍的場景。而F5、Radware、Citrix也是IT界大名鼎鼎的公司。並且隨著技術的演進，四層交換設備已經不僅僅只能提供四層的LB，七層的能力已經逐步完善。

可是為何到了雲時代以後，他們的名聲雖然依舊響亮，但是始終感覺不如從前了呢？而上面的幾種功能，在雲時代又是如何提供的呢？

再強大的盒子，能支撐的流量也不過百G級別。而在互聯網迅速崛起的年代，100G流量根本不算什麽，王者榮耀據說流量總和已經達到了800G（小道消息，待考證）。而類似於google的8.8.8.8，對流量和可靠性的需求，根本不是一個盒子可以承擔的起的

於是近幾年，負載均衡軟件蓬勃發展，結合動態路由協議實現anycast等能力後，拓展性和可靠性達到了一個質的飛躍。

LSLB逐步被 HA proxy、LVS、nginx等軟件代替，各大互聯網公司也紛紛基於開源軟件進一步開發加固，做出了自己的LB集群。比如騰訊的TGW，還有阿裏的LVS集群等。

而GSLB，其實也只是承擔了一個DNS重定向的能力，也逐步被智能DNS解析服務所取代，比如AWS敢於承諾100%可用性的Router53、騰訊的dnspod等。

LLB呢？被運營商提供的BGP線路所取代。傳統的LLB還需要每一個運營商1個IP，而BGP直接允許相同的IP在不同的運營商網絡裏廣播，根據BGP協議自己實現就近接入。

當然，雲還是比較包容的。盒子可能不太適合大規模服務化，但是給某一些企業使用還是很不錯的選擇，AWS跟F5合作，可以將F5軟件化，部署到VM中，在雲的模式下還可以繼續提供服務。

資料來源：https://bbs.huaweicloud.com/blogs/caf97cef9bac11e89fc57ca23e93a89f

LB服務：硬件如何被軟件取代（上）