作者：Matt Klein

譯者：崔秀龍

原題：Introduction to modern network load balancing and proxying

最近我注意到疮装，針對(duì)負(fù)載均衡和代理這兩項(xiàng)現(xiàn)代網(wǎng)絡(luò)技術(shù)，有教育意義的介紹性材料相當(dāng)稀缺间景。這引起我的思考：為什么會(huì)這樣订晌？在可靠的分布系統(tǒng)的架構(gòu)中，負(fù)載均衡是核心概念之一饿自，這一地位要求有對(duì)應(yīng)的高質(zhì)量信息汰翠。

然而經(jīng)過(guò)搜索之后，發(fā)現(xiàn)這方面的內(nèi)容的確匱乏璃俗。Wikipedia 上的 負(fù)載均衡 和 代理服務(wù)器 頁(yè)面只包含了一些相關(guān)主題的概念，這些概念的闡述悉默，尤其是微服務(wù)架構(gòu)相關(guān)的部分顯得相當(dāng)概括和晦澀城豁。Google 搜索 Load Balancing，則會(huì)出現(xiàn)一些供應(yīng)商頁(yè)面抄课，充斥了各種時(shí)髦用詞唱星，卻罕有細(xì)節(jié)。

本文里我會(huì)嘗試對(duì)現(xiàn)代網(wǎng)絡(luò)負(fù)載均衡和代理技術(shù)進(jìn)行一些講解跟磨，來(lái)彌補(bǔ)上述的材料缺失间聊。平心而論，相關(guān)內(nèi)容中的大量主題足以支撐起一本專(zhuān)著抵拘。為了符合我對(duì)博客長(zhǎng)度的控制習(xí)慣哎榴，我會(huì)將其中一些復(fù)雜主題進(jìn)行概括和提煉，用簡(jiǎn)單的概要方式進(jìn)行陳述僵蛛；根據(jù)讀者的興趣和反饋尚蝌，我可能會(huì)在后續(xù)文章中對(duì)某些話題的細(xì)節(jié)進(jìn)行更多的闡述。

上面的內(nèi)容就是我開(kāi)始寫(xiě)作本文的動(dòng)機(jī)充尉，下面開(kāi)始正式內(nèi)容飘言。

1

網(wǎng)絡(luò)負(fù)載均衡和代理是什么？

Wikipedia 對(duì)負(fù)載均衡的定義 是：

In computing, load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process.

中文版：

負(fù)載平衡（Load balancing）是一種計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)驼侠，用來(lái)在多個(gè)計(jì)算機(jī)（計(jì)算機(jī)集群）姿鸿、網(wǎng)絡(luò)連接、CPU倒源、磁盤(pán)驅(qū)動(dòng)器或其他資源中分配負(fù)載苛预，以達(dá)到最優(yōu)化資源使用、最大化吞吐率笋熬、最小化響應(yīng)時(shí)間碟渺、同時(shí)避免過(guò)載的目的。使用帶有負(fù)載平衡的多個(gè)服務(wù)器組件，取代單一的組件苫拍，可以通過(guò)冗余提高可靠性芜繁。負(fù)載平衡服務(wù)通常是由專(zhuān)用軟件和硬件來(lái)完成。

上面的定義不僅包含了網(wǎng)絡(luò)绒极，還包含了計(jì)算的所有方面骏令。操作系統(tǒng)、網(wǎng)絡(luò)以及容器編排器等都有各自的負(fù)載均衡技術(shù)垄提，用于使用各自的資源進(jìn)行各自的任務(wù)調(diào)度榔袋。本文僅就網(wǎng)絡(luò)負(fù)載均衡進(jìn)行探討。

image.gif

圖 1：網(wǎng)絡(luò)負(fù)載均衡概覽

圖 1 對(duì)網(wǎng)絡(luò)負(fù)載均衡進(jìn)行了一個(gè)高層次的概括铡俐。多個(gè)客戶端向多個(gè)后端發(fā)起資源請(qǐng)求凰兑，負(fù)載均衡器處于客戶端和后端之間，簡(jiǎn)單來(lái)說(shuō)完成如下任務(wù)：

• 服務(wù)發(fā)現(xiàn)：系統(tǒng)中有哪些后端可用审丘？這些后端的地址（也就是：負(fù)載均衡器如何同這些后端通信）吏够？

• 健康檢查：哪些后端是健康的可以用于接收請(qǐng)求？

• 負(fù)載均衡：用什么算法來(lái)把獨(dú)立的請(qǐng)求分發(fā)給健康的后端滩报？

在分布式系統(tǒng)中合理的使用負(fù)載均衡能帶來(lái)很多好處：

• 命名抽象：每個(gè)客戶端不再需要知道每一個(gè)后端(服務(wù)發(fā)現(xiàn))锅知，客戶端可以通過(guò)預(yù)定義的機(jī)制來(lái)找到負(fù)載均衡器，然后讓負(fù)載均衡器完成命名解析功能脓钾。這些機(jī)制包括內(nèi)置庫(kù)售睹，以及路人皆知的 DNS/IP/端口 地址，后面會(huì)深入討論可训。

• 錯(cuò)誤隔離：通過(guò)健康檢查以及一些其他的算法和技術(shù)昌妹，負(fù)載均衡器的路由方法能夠有效的繞過(guò)癱瘓或過(guò)載的后端。這樣運(yùn)維人員在面對(duì)系統(tǒng)故障時(shí)握截，就可以更加從容的進(jìn)行錯(cuò)誤處理捺宗。

• 成本和性能收益：分布式系統(tǒng)的網(wǎng)絡(luò)的一致性比較差。系統(tǒng)通常要跨越多個(gè)網(wǎng)絡(luò)區(qū)域川蒙。同一區(qū)域內(nèi)蚜厉，網(wǎng)絡(luò)資源通常是低售的；而在跨區(qū)域的情況下畜眨，超售則是常態(tài)（超售和低售的鑒別昼牛，是通過(guò)網(wǎng)卡上可消耗的帶寬和路由器之間的可用帶寬進(jìn)行比對(duì)得出的結(jié)論）。智能的負(fù)載均衡會(huì)盡可能保證通信在同一區(qū)域內(nèi)進(jìn)行康聂，從而提高性能(降低延遲)并降低總體系統(tǒng)成本(降低區(qū)域間的帶寬和光纖需求)贰健。

負(fù)載均衡器 vs 代理服務(wù)器

業(yè)內(nèi)談到網(wǎng)絡(luò)負(fù)載均衡器，Load Balancer 以及 Proxy 這兩個(gè)術(shù)語(yǔ)經(jīng)常會(huì)同樣對(duì)待恬汁，本文中也把這兩個(gè)詞條等價(jià)處理（賣(mài)弄一下：并非所有的代理都是負(fù)載均衡器伶椿，但是負(fù)載均衡是主流代理的首要功能）。

有人可能會(huì)問(wèn)，有的負(fù)載均衡功能是作為客戶端庫(kù)的內(nèi)置功能完成的脊另，這種負(fù)載均衡器就不是代理服務(wù)器导狡。這一話題本就容易混淆，這一質(zhì)問(wèn)更加讓人糊涂偎痛。文中會(huì)詳述這種負(fù)載均衡器的拓?fù)浜蹬酰@種嵌入的負(fù)載均衡方式只是代理的一種特例，應(yīng)用通過(guò)內(nèi)嵌的庫(kù)來(lái)完成代理職能踩麦，跟典型的負(fù)載均衡器的區(qū)別僅在于進(jìn)程內(nèi)外而已枚赡，其整體抽象是一致的。

四層(連接/會(huì)話)負(fù)載均衡

業(yè)界在討論負(fù)載均衡技術(shù)的時(shí)候谓谦，經(jīng)常會(huì)分為兩類(lèi)：L4 和 L7贫橙。這一分類(lèi)來(lái)源于 OSI 模型的四層和七層的定義。OSI 模型無(wú)法很好的描述負(fù)載均衡方案中的復(fù)雜性反粥，一個(gè)四層負(fù)載均衡在完成傳統(tǒng)的四層協(xié)議任務(wù)例如 UDP 和 TCP 之外卢肃，往往還會(huì)加入了其他層次的內(nèi)容。例如一個(gè)四層的 TCP 負(fù)載均衡還支持 TLS 功能星压，這算七層負(fù)載均衡了么践剂？

image.gif

圖 2：TCP 終端四層負(fù)載均衡

圖 2 展示了一個(gè)傳統(tǒng)的四層 TCP 負(fù)載均衡器鬼譬。這個(gè)例子中娜膘，客戶端向負(fù)載均衡器發(fā)起了一個(gè) TCP 連接，負(fù)載均衡器 終結(jié) 了這一連接(也就是說(shuō)直接響應(yīng)了 SYN)优质，接下來(lái)選擇一個(gè)后端竣贪，然后創(chuàng)建了到后端的新的 TCP 連接(就是發(fā)起了新的 SYN)。圖中的細(xì)節(jié)不需太過(guò)關(guān)注巩螃，后面的四層負(fù)載均衡章節(jié)會(huì)進(jìn)行詳細(xì)討論演怎。

本節(jié)的關(guān)鍵點(diǎn)是四層負(fù)載均衡一般只在四層的 TCP/UDP 進(jìn)行操作”芊Γ籠統(tǒng)的說(shuō)爷耀，負(fù)載均衡器負(fù)責(zé)操作這些字節(jié)，保證同一會(huì)話的字節(jié)們只跟同一個(gè)后端打交道拍皮。四層負(fù)載均衡對(duì)通信中的應(yīng)用細(xì)節(jié)是一無(wú)所知的歹叮。通信內(nèi)容可以是 HTTP、Redis铆帽、MongoDB 或者任何應(yīng)用協(xié)議咆耿。

七層(應(yīng)用)負(fù)載均衡

四層負(fù)載均衡很簡(jiǎn)單，目前還在大面積使用爹橱。四層負(fù)載均衡有什么短處萨螺，以至于需要七層(應(yīng)用)負(fù)載均衡呢？例如下面幾個(gè)四層的案例：

• 兩個(gè) gRPC/HTTP2 客戶端要連接到后端，所以通過(guò)四層負(fù)載均衡器來(lái)完成這一過(guò)程慰技。

• 四層負(fù)載均衡器為每個(gè)接入的 TCP 連接創(chuàng)建一個(gè)外發(fā)的 TCP 連接椭盏，這樣就有了兩個(gè)接入、兩個(gè)外發(fā)的連接惹盼。

• 然而客戶端 A 的請(qǐng)求頻率是每分鐘 1 請(qǐng)求庸汗，而客戶端 B 的頻率是每秒鐘 50 請(qǐng)求。

在上述場(chǎng)景中手报，為客戶端 A 服務(wù)的后端蚯舱，其負(fù)載水平僅相當(dāng)于為客戶端 B 服務(wù)的后端的約 1/3000 左右，這明顯違背了負(fù)載均衡器的初衷掩蛤。在所有多工枉昏、保持連接的協(xié)議中都會(huì)發(fā)生這樣的情況（多工意思是在單一四層連接中并行發(fā)送應(yīng)用請(qǐng)求；保持連接則意味著在沒(méi)有活動(dòng)請(qǐng)求的情況下揍鸟，也不會(huì)關(guān)閉連接）兄裂。出于性能方面的考慮（創(chuàng)建連接的成本通常較高，尤其是當(dāng)使用 TLS 對(duì)連接進(jìn)行加密的情況下）阳藻，所有的現(xiàn)代協(xié)議都包含這兩個(gè)特性晰奖，所以隨著時(shí)間的推移，四層負(fù)載均衡的負(fù)載不均的情況會(huì)越發(fā)明顯腥泥。七層負(fù)載均衡能夠解決這一問(wèn)題匾南。

image.gif

圖三：HTTP/2 七層終端負(fù)載均衡

圖 3 描述了七層的 HTTP/2 負(fù)載均衡。這里客戶端發(fā)起了對(duì)負(fù)載均衡的單個(gè)連接蛔外。負(fù)載均衡器連接到了兩個(gè)后端蛆楞。當(dāng)客戶端向負(fù)載均衡器發(fā)送兩個(gè) HTTP/2 流的時(shí)候，兩個(gè)流會(huì)分別送往不同后端夹厌。這樣多工客戶端的大量不同的請(qǐng)求會(huì)被高效的分發(fā)給多個(gè)后端豹爹。這就是七層負(fù)載均衡對(duì)現(xiàn)代協(xié)議的重要性的來(lái)由（因?yàn)閷?duì)應(yīng)用流量的洞察能力，七層負(fù)載均衡還有很多其他好處矛纹，后面會(huì)詳細(xì)描述）臂聋。

七層負(fù)載均衡和 OSI 模型

之前四層負(fù)載均衡章節(jié)中說(shuō)過(guò)，用 OSI 模型來(lái)描述負(fù)載均衡是有困難的或南。OSI 描述的第七層孩等，涵蓋了負(fù)載均衡的多方面功能的臭顯。比如對(duì) HTTP 來(lái)說(shuō)迎献，有以下幾個(gè)低級(jí)一些的層次：

• 可選的 TLS瞎访。網(wǎng)絡(luò)界對(duì) TLS 究竟應(yīng)該屬于 OSI 模型的哪一層素有爭(zhēng)議。為討論方便吁恍，我們放在七層扒秸。

• 物理的 HTTP 協(xié)議(HTTP/1或 HTTP/2)播演。

• 邏輯 HTTP 協(xié)議(Header、Body 和 Trailer)伴奥。

• 消息協(xié)議(gRPC写烤、REST 等)。

一個(gè)成熟的的七層負(fù)載均衡器應(yīng)該照顧到上面描述的每一層次拾徙。另一個(gè)七層負(fù)載均衡器可能只支持七層分類(lèi)中的特性的一個(gè)子集洲炊。總而言之尼啡，七層負(fù)載均衡器的范疇包含了遠(yuǎn)超四層的為數(shù)眾多的功能（例子中只提到了了 HTTP暂衡；Redis、Kafka崖瞭、MongoDB 等也都是七層應(yīng)用協(xié)議的例子狂巢，也都應(yīng)受益于七層負(fù)載均衡）。

2

負(fù)載均衡器特性

下面簡(jiǎn)單匯總一下負(fù)載均衡器的高層功能书聚。并非所有負(fù)載均衡器都提供了所有功能唧领。

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)就是負(fù)載均衡器用于決定可用后臺(tái)列表的過(guò)程。這一功能的實(shí)現(xiàn)方式花樣百出雌续，下面舉一些例子：

• 靜態(tài)配置文件斩个。

• DNS。

• Zookeeper驯杜、Etcd受啥、Consul 等。

• Envoy 的 統(tǒng)一數(shù)據(jù)平面 API艇肴。

健康檢查

負(fù)載均衡器使用健康檢查功能腔呜，來(lái)檢測(cè)后端是否可用叁温。健康檢查有兩種實(shí)現(xiàn)思路：

• 主動(dòng)式：負(fù)載均衡器周期性的向后端發(fā)送 ping (例如一個(gè)發(fā)送到/healthcheck端點(diǎn)的 HTTP 請(qǐng)求)再悼，以此判斷后端的健康情況。

• 被動(dòng)式：負(fù)載均衡器通過(guò)對(duì)主數(shù)據(jù)流的分析來(lái)確定健康情況膝但。比如一個(gè)四層負(fù)載均衡器冲九，在發(fā)現(xiàn)連續(xù)三個(gè)連接錯(cuò)誤的情況下，就會(huì)判定一個(gè)后端不可用跟束；七層負(fù)載均衡可能會(huì)在連續(xù)三個(gè) HTTP 503 響應(yīng)之后判定這一后端為不健康狀態(tài)莺奸。

負(fù)載均衡

是的，負(fù)載均衡器必須為負(fù)載做均衡冀宴。有了一系列的健康后端灭贷，如何選擇后端來(lái)響應(yīng)一個(gè)請(qǐng)求或者連接呢？負(fù)載均衡算法是一個(gè)活躍的研究領(lǐng)域略贮，有 Round Robin 這樣的簡(jiǎn)單辦法甚疟，也有通過(guò)延遲和后端負(fù)載情況進(jìn)行判斷的復(fù)雜方案仗岖。 Power of 2 least request load balancing 一文，介紹了最流行的兼顧性能和簡(jiǎn)易的負(fù)載均衡算法之一览妖。

隨機(jī)選擇兩個(gè)后端轧拄，進(jìn)一步選擇其中負(fù)載較低的一個(gè)。

Session 粘連

在某些應(yīng)用中有一個(gè)重要需求：同一會(huì)話的請(qǐng)求需要到達(dá)同一后端讽膏。對(duì)于緩存檩电、臨時(shí)復(fù)雜狀態(tài)等場(chǎng)景來(lái)說(shuō)這是很必要的。對(duì)于“同一會(huì)話”的定義有多種形式府树，可能包括 HTTP Cookie俐末、客戶端連接的屬性以及其他屬性。很多七層負(fù)載均衡器具有一些對(duì)會(huì)話粘連的支持奄侠。然而我認(rèn)為會(huì)話粘連是一種天然易碎的情況（處理會(huì)話的后端可能會(huì)癱瘓）鹅搪，所以對(duì)于依賴(lài)會(huì)話的系統(tǒng)設(shè)計(jì)應(yīng)該多加小心。

TLS 終端

TLS 這一話題遭铺，不管是邊緣服務(wù)還是服務(wù)間通訊丽柿，都值得大書(shū)特書(shū)。因此很多七層負(fù)載均衡器在 TLS 處理方面都做了大量工作魂挂，其中包含終端甫题、證書(shū)校驗(yàn)和綁定，使用 SNI 提供證書(shū)等功能涂召。

觀測(cè)性

我常說(shuō)：“觀測(cè)性坠非、觀測(cè)性、觀測(cè)性果正⊙茁耄”，網(wǎng)絡(luò)是一個(gè)天生不可靠的東西秋泳，負(fù)載均衡器應(yīng)該提供狀態(tài)潦闲、跟蹤以及日志，協(xié)助運(yùn)維人員甄別故障迫皱，從而進(jìn)行修復(fù)歉闰。負(fù)載均衡器的檢測(cè)輸出差距很大。高級(jí)的負(fù)載均衡器供應(yīng)包含數(shù)字統(tǒng)計(jì)卓起、分布式跟中和自定義日志的大量輸出和敬。我認(rèn)為增強(qiáng)的觀測(cè)性并不是從天而降的，負(fù)載均衡器需要做出很多附加工作來(lái)完成這一任務(wù)戏阅。對(duì)性能造成的負(fù)面影響昼弟，相對(duì)于這一系列數(shù)據(jù)的好處來(lái)說(shuō)，不值一提奕筐。

安全性和拒絕服務(wù)攻擊防范

在邊緣部署拓?fù)洌ê竺鏁?huì)講解）中舱痘，負(fù)載均衡器經(jīng)常需要實(shí)現(xiàn)各種包含頻率限制蚕键、認(rèn)證以及 DoS 防范（例如 IP 地址的標(biāo)記和辨識(shí)、Tarpitting等方式）等在內(nèi)的安全功能衰粹。

配置和控制平面

負(fù)載均衡器應(yīng)該是可配置的锣光。在大規(guī)模部署中，這是一個(gè)重要的工作量铝耻。通常來(lái)說(shuō)誊爹，用來(lái)配置負(fù)載均衡器的系統(tǒng)被稱(chēng)為“控制平面”，會(huì)有多種實(shí)現(xiàn)瓢捉。拙作 Service Mesh Data Plan vs Control Plan 中對(duì)這一部分內(nèi)容作了更深入的探討频丘。

還有很多

這部分只是對(duì)于負(fù)載均衡器的功能層面作了一些介紹。下面還會(huì)在七層負(fù)載均衡器方面做更多的深入討論泡态。

3

負(fù)載均衡器的拓?fù)浞诸?lèi)

我們已經(jīng)對(duì)負(fù)載均衡器的概念作了一些概括的介紹搂漠，四層和七層負(fù)載均衡器的區(qū)別，以及負(fù)載均衡器特性的匯總某弦，接下來(lái)我們會(huì)針對(duì)分布式系統(tǒng)中的負(fù)載均衡器部署拓?fù)溥M(jìn)行一些探討（下面的每一種拓?fù)涠际沁m用于四層和七層負(fù)載均衡器的）桐汤。

中間代理

image.gif

圖 4：中間代理負(fù)載均衡拓?fù)?/p>

圖 4 描述的這種拓?fù)鋵?duì)多數(shù)讀者來(lái)說(shuō)都是最熟悉的。這一類(lèi)別包括了 Cisco靶壮、Juniper怔毛、F5 等硬件產(chǎn)品；云軟件解決方案例如 Amazone 的 ALB 和 NLB 以及 Google 的 Cloud Load Balancer腾降，還有 HAProxy拣度、NGINX 以及 Envoy 這樣的純軟件自主方案。中間代理方案的優(yōu)勢(shì)在于對(duì)用戶提供的簡(jiǎn)便性螃壤。

一般情況下用戶只要通過(guò) DNS 連接到負(fù)載均衡器即可抗果，無(wú)需擔(dān)心其他情況；弱勢(shì)在于奸晴，負(fù)載均衡器存在單點(diǎn)失敗的風(fēng)險(xiǎn)冤馏，同時(shí)也是可能的性能瓶頸。中間代理通常是一個(gè)不便運(yùn)維的黑盒子蚁滋。問(wèn)題出現(xiàn)在哪里宿接？是客戶端還是物理網(wǎng)絡(luò)赘淮？是中間代理還是后端辕录？很難界定。

邊緣代理

image.gif

圖 5：邊緣代理負(fù)載均衡拓?fù)?/p>

圖 5 實(shí)際上是中間代理的一種變體梢卸，這種負(fù)載均衡器可以通過(guò) Internet 進(jìn)行訪問(wèn)走诞。在這一場(chǎng)景下，負(fù)載均衡器通常需要提供一些附加的 “API 網(wǎng)關(guān)”類(lèi)功能蛤高，例如 TLS 終端蚣旱、頻率限制碑幅、認(rèn)證以及流量路由等。優(yōu)勢(shì)和劣勢(shì)跟中間服代理類(lèi)似塞绿。在一個(gè)大的面向 Internet 的分布式系統(tǒng)中沟涨，邊緣服務(wù)器通常是一個(gè)必要的組成部分。

客戶端通常會(huì)使用某個(gè)不受服務(wù)提供商控制的網(wǎng)絡(luò)庫(kù)异吻，通過(guò) DNS 來(lái)訪問(wèn)這一系統(tǒng)(后面將會(huì)討論的嵌入客戶庫(kù)或者 Sidecar 代理拓?fù)涠疾贿m合直接運(yùn)行在客戶端)裹赴。另外為了安全方面的考慮，為所有的面向 Internet 的流量使用單一的網(wǎng)關(guān)來(lái)提供入站流量是一個(gè)普遍要求诀浪。

嵌入式客戶庫(kù)

image.gif

圖 6：通過(guò)嵌入客戶端庫(kù)實(shí)現(xiàn)負(fù)載均衡

為了克服隨中間代理而出現(xiàn)的單點(diǎn)失敗以及性能問(wèn)題棋返，很多成熟架構(gòu)把負(fù)載均衡直接植入如圖 6 所示的客戶端庫(kù)中。不同的庫(kù)所支持的功能差別很大宾舅，此類(lèi)產(chǎn)品中最知名的功能豐富的包括 Finagle闰渔、Eureka/Ribbon/Hystrix 以及 gRPC（大致基于 Google 的一個(gè)稱(chēng)為 Stubby 的內(nèi)部系統(tǒng)）罩抗。這種方式的好處是把所有負(fù)載均衡特性完全分布到每個(gè)客戶端，從而避免了前面說(shuō)到的單點(diǎn)失敗和性能瓶頸射沟。

這種做法的弱勢(shì)也很明顯，一個(gè)組織使用的所有語(yǔ)言与境，都需要實(shí)現(xiàn)這種客戶端庫(kù)躏惋。分布式架構(gòu)下，這種多語(yǔ)言支持的要求會(huì)越來(lái)越多嚷辅。這種環(huán)境里簿姨，每種語(yǔ)言的網(wǎng)絡(luò)庫(kù)實(shí)現(xiàn)造成的成本會(huì)讓人望而卻步。最后簸搞，在大的服務(wù)架構(gòu)中進(jìn)行庫(kù)升級(jí)也是一個(gè)很大的挑戰(zhàn)扁位，而在生產(chǎn)環(huán)境中并行運(yùn)行不同的版本，又會(huì)給運(yùn)維造成更大壓力趁俊。

結(jié)合上面的優(yōu)劣勢(shì)分析域仇，可以知道，在能夠限制編程語(yǔ)言使用寺擂，并克服升級(jí)痛苦的情況下暇务，這種架構(gòu)是可以獲得成功的。

Sidecar 代理

image.gif

圖 7：Sidecar 代理實(shí)現(xiàn)負(fù)載均衡

嵌入式客戶庫(kù)的一個(gè)變體就是圖 7 中的 Sidecar 代理拓?fù)湔怼＝陙?lái)垦细，這一拓?fù)湟?“Service Mesh” 的概念日益流行。Sidecar 代理背后的思路是挡逼，以進(jìn)程間通信造成的些許延遲為代價(jià)括改，在無(wú)需顧慮編程語(yǔ)言鎖定的情況下獲得嵌入客戶端庫(kù)的各種優(yōu)點(diǎn)。目前流行的 Sidecar 負(fù)載均衡包括 Envoy家坎、NGINX嘱能、HAProxy 以及 Linkerd吝梅，我的兩篇文章：Introducing Envoy 和 Service Mesh Data Plan vs Control Plan 對(duì)這種結(jié)構(gòu)進(jìn)行了更細(xì)致的描寫(xiě)。

不同負(fù)載均衡器拓?fù)涞目偨Y(jié)和優(yōu)劣勢(shì)

• 中間代理拓?fù)涫亲詈?jiǎn)單的最典型的方式惹骂。他的弱點(diǎn)在于：故障單點(diǎn)苏携、伸縮瓶頸以及黑箱操作。

• 邊緣代理拓?fù)浜椭虚g代理類(lèi)似对粪，通常無(wú)法忽略兜叨。

• 嵌入客戶端庫(kù)的方式提供了最好的性能和伸縮性，不過(guò)面向多種語(yǔ)言的開(kāi)發(fā)衩侥，和升級(jí)所有服務(wù)的庫(kù)都是很大的挑戰(zhàn)国旷。

• Sidecar 代理拓?fù)浔惹度胧娇蛻舳藥?kù)要弱，但也避免了這種方式的兩大難點(diǎn)茫死。

總的來(lái)說(shuō)跪但，我認(rèn)為在服務(wù)對(duì)服務(wù)的情況下，Sidecar 代理拓?fù)洌⊿ervice Mesh）會(huì)逐漸代替所有其他拓?fù)湫问铰臀榱颂幚磉M(jìn)入 Service Mesh 之前的流量屡久，邊緣代理拓?fù)鋾?huì)長(zhǎng)期存在。

4

四層負(fù)載均衡的現(xiàn)狀

四層負(fù)載均衡器還有用么爱榔？

本文已經(jīng)談?wù)摿撕芏嗥邔迂?fù)載均衡器對(duì)現(xiàn)代協(xié)議的好處被环，后面還會(huì)談到七層負(fù)載均衡的功能細(xì)節(jié)。這是否意味著四層負(fù)載均衡器無(wú)需存在了详幽？不是的筛欢。雖然我認(rèn)為最終七層負(fù)載均衡會(huì)完全在服務(wù)對(duì)服務(wù)的場(chǎng)景中取代四層負(fù)載均衡器，但四層負(fù)載均衡器對(duì)邊緣通信還是非常有意義的唇聘，這是因?yàn)樗鞋F(xiàn)代的大型分布式架構(gòu)都是用了兩層的四層/七層負(fù)載均衡架構(gòu)來(lái)處理互聯(lián)網(wǎng)流量版姑。在七層負(fù)載均衡器之前部署獨(dú)立的四層負(fù)載均衡器的好處是：

• 七層負(fù)載均衡器要在應(yīng)用層面進(jìn)行更多的精密分析、變換以及路由工作迟郎，對(duì)于原始流量（每秒數(shù)據(jù)包或每秒字節(jié)數(shù)）的負(fù)載剥险，其能力要弱于優(yōu)化過(guò)的四層負(fù)載均衡器。這一現(xiàn)實(shí)使得四層負(fù)載均衡器更便于應(yīng)對(duì)拒絕服務(wù)攻擊（例如 SYN flood宪肖、通用包 flood 攻擊等）表制。

• 相對(duì)于四層負(fù)載均衡器，七層負(fù)載均衡器的開(kāi)發(fā)更加活躍控乾，部署更加頻繁么介，也會(huì)有更多 Bug。有了前置的四層負(fù)載均衡器阱持，就可以在七層負(fù)載均衡器升級(jí)期間進(jìn)行健康檢查和排空夭拌，現(xiàn)代四層負(fù)載均衡器通常使用 BGP 和 ECMP(后續(xù)章節(jié)會(huì)詳細(xì)講解)，七層負(fù)載均衡的部署通常會(huì)較為簡(jiǎn)單衷咽。最后因?yàn)槠邔迂?fù)載均衡器相對(duì)來(lái)說(shuō)復(fù)雜度較高鸽扁，因此也更容易出現(xiàn)問(wèn)題，有了前端的四層負(fù)載均衡镶骗，就可以在出現(xiàn)問(wèn)題的時(shí)候利用路由功能繞過(guò)故障節(jié)點(diǎn)桶现，提高系統(tǒng)的總體穩(wěn)定性。

下文中我會(huì)講到集中不同設(shè)計(jì)的中間/邊緣四層負(fù)載均衡器鼎姊。后面提到的設(shè)計(jì)通常是無(wú)法用在客戶庫(kù)或 Sidecar 拓?fù)渲械摹?/p>

TCP/UDP 終端負(fù)載均衡器

image

圖 8：四層終端負(fù)載均衡器

還在應(yīng)用的第一種四層負(fù)載均衡器是圖 8中的終端負(fù)載均衡器骡和。這和我們介紹四層負(fù)載均衡的時(shí)候講到的內(nèi)容是一致的。這種類(lèi)型的負(fù)載均衡器中相寇，使用了兩個(gè)的獨(dú)立的 TCP 連接：一個(gè)用于客戶端和負(fù)載均衡器之間慰于；另一個(gè)用在負(fù)載均衡器和后端之間。

四層終端負(fù)載均衡器還有兩個(gè)原因：

1. 實(shí)現(xiàn)相對(duì)簡(jiǎn)單唤衫。

2. 靠近客戶端的連接終端對(duì)性能有顯著影響婆赠。尤其是如果客戶使用有損網(wǎng)絡(luò)（例如蜂窩網(wǎng)）的話，在進(jìn)入穩(wěn)定的有線傳輸?shù)阶罱K目的之前佳励，是容易發(fā)生重傳的休里。換句話說(shuō)，這種負(fù)載均衡器適用于在存在點(diǎn)（Point of Presence )場(chǎng)景下的原始 TCP 連接赃承。

TCP/UDP 透?jìng)髫?fù)載均衡器

image

圖 9：透?jìng)髫?fù)載均衡器

四層負(fù)載均衡器的另一種類(lèi)型就是圖 9所說(shuō)的透?jìng)髫?fù)載均衡器妙黍。這種類(lèi)型的負(fù)載均衡過(guò)程中，TCP連接沒(méi)有被負(fù)載均衡器終結(jié)瞧剖，每個(gè)鏈接的數(shù)據(jù)包拭嫁，在經(jīng)過(guò)連接分析和網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）過(guò)程之后，都被轉(zhuǎn)發(fā)給一個(gè)選中的后端抓于。首先讓我們定義一下連接跟蹤和 NAT：

• 連接跟蹤：跟蹤全部活動(dòng) TCP 連接的過(guò)程噩凹。這里包括很多內(nèi)容，例如握手是否完成毡咏，是否收到 FIN驮宴，連接發(fā)呆了多久，這個(gè)連接轉(zhuǎn)發(fā)給哪一個(gè)后端等呕缭。

• NAT：是使用連接跟蹤數(shù)據(jù)堵泽，來(lái)更改數(shù)據(jù)包的 IP/端口信息使之穿過(guò)負(fù)載均衡器的過(guò)程。

有了連接跟蹤和 NAT恢总，負(fù)載均衡器就能把客戶端的 TCP 流量幾乎原封不動(dòng)的的轉(zhuǎn)發(fā)給后端迎罗。例如客戶端同1.2.3.4:80進(jìn)行通信，選中的后端是10.0.0.2:9000片仿∥瓢玻客戶端的 TCP 數(shù)據(jù)包會(huì)到達(dá)位于1.2.3.4:80的負(fù)載均衡器。負(fù)載均衡器會(huì)把目標(biāo) IP 和端口替換為10.0.0.2:9000；同時(shí)還會(huì)把源 IP 替換為負(fù)載均衡器的 IP厢岂。當(dāng)后端響應(yīng) TCP 連接時(shí)光督，數(shù)據(jù)包就會(huì)返回給負(fù)載均衡器，負(fù)載均衡器中的鏈接跟蹤和 NAT 再次發(fā)揮作用塔粒，反向送回?cái)?shù)據(jù)包结借。

為什么會(huì)使用這一種負(fù)載均衡器，而不是前面提到的終端型呢卒茬？

• 性能和資源消耗：透?jìng)餍偷呢?fù)載均衡器沒(méi)有終結(jié) TCP 連接船老，無(wú)需緩存任何的 TCP 連接窗口。每個(gè)連接的狀態(tài)存儲(chǔ)非常小圃酵，通常使用高效的哈希表查詢即可柳畔。正因如此，相對(duì)終端負(fù)載均衡器來(lái)說(shuō)郭赐，透?jìng)餍拓?fù)載均衡器能夠處理更大數(shù)量的活動(dòng)鏈接薪韩，單位時(shí)間內(nèi)處理更多的數(shù)據(jù)包。

• 允許后端進(jìn)行擁塞控制：TCP 擁塞控制 是一種機(jī)制堪置，讓 Internete 端點(diǎn)對(duì)外發(fā)數(shù)據(jù)進(jìn)行流量控制躬存，防止超量使用帶寬和緩沖。

• 為直接服務(wù)器返回（Direct Server Return = DSR）做基線舀锨，以及四層負(fù)載均衡集群：透?jìng)髫?fù)載均衡也是高級(jí)四層負(fù)載均衡（例如后面將要說(shuō)到的 DSR 和使用分布式一致性哈希的集群）的基礎(chǔ)岭洲。

Direct Server Return (DSR)

image.gif

圖 10：四層 DSR

圖 10展示的就是 DSR 負(fù)載均衡。DSR 構(gòu)建在前文提到的透?jìng)髫?fù)載均衡器的基礎(chǔ)之上坎匿。DSR 是一種優(yōu)化方案盾剩，只有入站/請(qǐng)求數(shù)據(jù)包通過(guò)負(fù)載均衡；出站/響應(yīng)數(shù)據(jù)包繞過(guò)負(fù)載均衡器直接返回給客戶端替蔬。使用 DSR 方案的有趣之處在于告私，很多負(fù)載的響應(yīng)比請(qǐng)求數(shù)據(jù)量大很多(比如典型的 HTTP 請(qǐng)求和響應(yīng))。假設(shè) 10% 的流量是請(qǐng)求承桥，另外 90% 是響應(yīng)驻粟，如果使用了 DSR 負(fù)載均衡，僅需要 1/10 的容量就能夠滿足系統(tǒng)需要凶异。從前的負(fù)載均衡非常昂貴蜀撑，這一方案能夠顯著降低系統(tǒng)成本并提高可靠性（更少就是更好）。DSR 負(fù)載均衡器用下面的方式擴(kuò)展了透?jìng)髫?fù)載均衡的概念：

• 由于響應(yīng)包不再經(jīng)過(guò)負(fù)載均衡器剩彬，所以連接跟蹤僅有部分?jǐn)?shù)據(jù)酷麦，負(fù)載均衡器無(wú)法知道完整的 TCP 連接狀態(tài)。然而還是可以通過(guò)對(duì)客戶數(shù)據(jù)包的觀察喉恋，對(duì)發(fā)呆超時(shí)的情況來(lái)推斷具體狀態(tài)沃饶。

• 負(fù)載均衡器通常使用 GRE 來(lái)封裝 IP 包母廷，并從負(fù)載均衡器發(fā)送到后端。這樣當(dāng)后端接收到封裝后的數(shù)據(jù)包糊肤，可以解包并獲得客戶端的端口和地址琴昆。這樣后端就能直接跨過(guò)負(fù)載均衡器直接發(fā)送響應(yīng)包給客戶端了。

• DSR 負(fù)載均衡器的一個(gè)重要部分就是：后端部分的參與了負(fù)載均衡過(guò)程轩褐。后端需要合理的配置 GRE 隧道椎咧，并且需要根據(jù)網(wǎng)絡(luò)的低級(jí)細(xì)節(jié)來(lái)配置自己的連接跟蹤以及 NAT 等玖详。

注意不管是 DSR 還是透?jìng)髫?fù)載均衡器把介，其中的連接跟蹤、NAT蟋座、GRE 等組成部分都有很多不同設(shè)計(jì)方式拗踢。這些設(shè)置從負(fù)載均衡器到后端都會(huì)涉及。這部分內(nèi)容超出了本文的范圍向臀，就不再深入進(jìn)行了巢墅。

使用高可用配對(duì)方式實(shí)現(xiàn)容錯(cuò)

image.gif

圖 11：使用 HA 對(duì)和連接跟蹤實(shí)現(xiàn)容錯(cuò)

到現(xiàn)在，我們要考慮四層負(fù)載均衡的容錯(cuò)設(shè)計(jì)了券膀。不管是 DSR 還是透?jìng)髫?fù)載均衡都需要一定數(shù)量的鏈接跟蹤和狀態(tài)數(shù)據(jù)存儲(chǔ)在負(fù)載均衡器中君纫。負(fù)載均衡器宕機(jī)了會(huì)怎樣？——所有經(jīng)過(guò)這一負(fù)載均衡器的連接都會(huì)斷掉芹彬⌒钏瑁可能對(duì)應(yīng)用產(chǎn)生顯著影響。

歷史上舒帮，四層負(fù)載均衡器是一種從典型供應(yīng)商（Cisco会喝、Juniper、F5 等）采購(gòu)的硬件玩郊。這些設(shè)備非常昂貴肢执，能夠處理大量通信。為了防止單點(diǎn)失敗導(dǎo)致的所有連接中斷译红，引發(fā)應(yīng)用故障预茄，負(fù)載均衡器通常會(huì)使用高可用配對(duì)的方式進(jìn)行部署，如圖 11 所示侦厚。典型的高可用負(fù)載均衡器配置會(huì)滿足如下設(shè)計(jì)：

• 一對(duì)高可用邊緣路由器提供一系列的虛擬 IP(VIP)耻陕。這些邊緣路由器使用邊界網(wǎng)關(guān)協(xié)議（BGP）來(lái)發(fā)布虛擬 IP。主要邊緣路由器的 BGP 優(yōu)先級(jí)高于備用邊緣路由器假夺，所以正常情況下他會(huì)處理所有流量（BGP 是一個(gè)超級(jí)復(fù)雜的協(xié)議淮蜈；為了行文方便，可以理解 BGP 是一種機(jī)制已卷，這種機(jī)制讓網(wǎng)絡(luò)設(shè)備可以宣稱(chēng)自身能夠處理來(lái)自其他網(wǎng)絡(luò)設(shè)備的流量梧田，并且每個(gè)連接都會(huì)有一個(gè)權(quán)重，從而影響連接的通信）。

• 類(lèi)似的裁眯，主要四層負(fù)載均衡向 BGP 權(quán)重較高的邊緣路由器宣告可用鹉梨，所以在通常情況下，他會(huì)處理所有流量穿稳。

• 兩個(gè)邊緣路由器和兩個(gè)負(fù)載均衡器是交叉連接的存皂，這意味著如果一個(gè)邊緣路由器或者一個(gè)負(fù)載均衡器宕機(jī)，或者因?yàn)槟承┰?BGP 宣布失效逢艘，備用設(shè)備就會(huì)接入旦袋，承載所有流量。

上面的設(shè)置是目前很多互聯(lián)網(wǎng)上的高流量應(yīng)用還在持續(xù)使用的方式它改，但是這種方案有一些副作用：

• VIP 必須通過(guò)高可用負(fù)載均衡器對(duì)流量進(jìn)行正確的分配疤孕。如果單一 VIP 的容量超過(guò)了 HA 對(duì)，則 VIP 需要分割為多個(gè) VIP央拖。

• 系統(tǒng)資源使用率很低祭阀。通常會(huì)有一半的容量在閑置。過(guò)去的負(fù)載均衡器非常昂貴鲜戒，所以這一閑置成本也是很高的专控。

• 現(xiàn)代分布式系統(tǒng)設(shè)計(jì)要求比主備模式更好的容錯(cuò)設(shè)計(jì)。例如一個(gè)系統(tǒng)需要在多個(gè)同時(shí)出現(xiàn)故障的情況下保持運(yùn)行遏餐。高可用負(fù)載均衡對(duì)如果遭遇同時(shí)故障伦腐，就會(huì)導(dǎo)致完全癱瘓。

• 供應(yīng)商提供的硬件設(shè)備價(jià)格昂貴境输，會(huì)導(dǎo)致對(duì)特定廠商的依賴(lài)蔗牡。使用支持水平擴(kuò)展的軟件方案對(duì)商業(yè)硬件設(shè)施進(jìn)行替換，是目前普遍存在的迫切需要嗅剖。

使用分布式一致性哈希進(jìn)行容錯(cuò)和伸縮

image.gif

圖 12：四層負(fù)載均衡器和一致哈希實(shí)現(xiàn)容錯(cuò)和伸縮

前文介紹了通過(guò)高可用配對(duì)的方式來(lái)進(jìn)行負(fù)載均衡器的容錯(cuò)設(shè)置辩越，以及隨之而來(lái)的問(wèn)題。千禧年初信粮，一些大的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施提供商開(kāi)始設(shè)計(jì)和部署新的圖 12 模式的并行四層負(fù)載均衡系統(tǒng)黔攒。這類(lèi)系統(tǒng)的目標(biāo)是：

• 解決使用成對(duì) HA 模式設(shè)計(jì)的負(fù)載均衡方案帶來(lái)的所有問(wèn)題。

• 從廠商專(zhuān)屬的專(zhuān)利硬件模式的負(fù)載均衡器中遷移出來(lái)强缘，使用標(biāo)準(zhǔn)服務(wù)器和網(wǎng)卡配合商業(yè)軟件方案進(jìn)行替代督惰。

四層負(fù)載均衡器的設(shè)計(jì)是 fault tolerance and scaling via clustering and distributed consistent hashing 的最佳引用，具體工作模式是：

• N 個(gè)邊緣路由器在同一 BGP 權(quán)重上旅掂，聲明所有的 任播 VIP赏胚。使用 ECMP（等價(jià)多路徑路由） 來(lái)保證所有單一 Flow 能夠到達(dá)同一個(gè)邊緣路由器。一個(gè) Flow 通常是一個(gè)由源 IP/端口和目的 IP/端口 構(gòu)成的元組商虐。(簡(jiǎn)單說(shuō)觉阅，ECMP 是一個(gè)在使用一致性哈希連接的獨(dú)立加權(quán)網(wǎng)絡(luò)上分發(fā)數(shù)據(jù)包的方式)崖疤。邊緣路由器并不在意哪些數(shù)據(jù)包去了哪里。一般會(huì)傾向于把來(lái)自于一個(gè) Flow 所有數(shù)據(jù)包發(fā)送給同一套連接典勇，以此避免亂序包導(dǎo)致的性能損失劫哼。

• N 個(gè)四層負(fù)載均衡器向邊緣路由器在同一個(gè) BGP 權(quán)重上聲明所有的 VIP。再次借助 ECMP割笙，邊緣路由器會(huì)選擇為同一個(gè) Flow 選擇同一個(gè)負(fù)載均衡器权烧。

• 每個(gè)四層負(fù)載均衡器會(huì)進(jìn)行部分的連接跟蹤，為這一 Flow 使用一致性哈希選擇一個(gè)后端伤溉。從負(fù)載均衡器到后端的數(shù)據(jù)包會(huì)使用 GRE 進(jìn)行封裝般码。

• 接下來(lái)使用 DSR 將相應(yīng)包直接從后端通過(guò)邊緣路由器發(fā)送會(huì)客戶端。

• 四層負(fù)載均衡器使用的一致性哈希算法是一個(gè)活躍的研究領(lǐng)域谈火，其中涉及合理分配侈询、減小延遲舌涨、后端變更成本以及最小化內(nèi)存開(kāi)支等各方面要素糯耍。這方面的完整討論也超出了本文范圍。

接下來(lái)看看這種設(shè)計(jì)如何克服 HA 配對(duì)方式的缺點(diǎn)：

• 新的邊緣路由器和負(fù)載均衡器可以按需加入囊嘉。一致性哈希會(huì)在各個(gè)層次上使用温技，在加入新機(jī)器的時(shí)候，盡可能降低受影響的 Flow 數(shù)量扭粱。

• 在保持對(duì)突發(fā)消耗的支持能力以及容錯(cuò)能力的同時(shí)舵鳞，可以提高資源的使用率。

• 邊緣路由器和負(fù)載均衡都可以使用使用普通硬件琢蛤，僅是傳統(tǒng)硬件負(fù)載均衡成本的幾分之一（下文會(huì)進(jìn)一步說(shuō)明）蜓堕。

行文至此，有讀者可能會(huì)問(wèn)：“為什么不讓邊緣路由器直接通過(guò) ECMP 和后端進(jìn)行通信博其？為什么我們還需要負(fù)載均衡器套才？”。答案是 DoS 防范以及后端運(yùn)維難度慕淡。如果沒(méi)有負(fù)載均衡器支持背伴，每個(gè)后端都需要加入 BGP，而且難于進(jìn)行滾動(dòng)更新峰髓。

所有的現(xiàn)代四層負(fù)載均衡系統(tǒng)都在向著這一方案（或其變體）遷移傻寂。兩個(gè)最為公眾所知的例子就是 Google 的 Maglev 以及 Amazon 的 Network Load Balancer (NLB)。目前還沒(méi)有任何開(kāi)源負(fù)載均衡器實(shí)現(xiàn)了這一設(shè)計(jì)携兵，然而據(jù)我所知疾掰，有公司要在 2018 年發(fā)布一個(gè)這樣的產(chǎn)品。我很期待他的出現(xiàn)徐紧，這一產(chǎn)品將會(huì)填補(bǔ)開(kāi)源網(wǎng)絡(luò)組件的重要空白静檬。

當(dāng)前七層負(fù)載均衡的技術(shù)狀態(tài)

Current state of the art in L7 load balancing The proxy wars in tech currently is quite literally the proxy wars. Or the "war of the proxies". Nginx plus, HAProxy, linkerd, Envoy all quite literally killing it. And proxy-as-a-service/routing-as-a-service SaaS vendors raising the bar as well. Very interesting times!

是的勒葱，的確是這樣。近幾年我們看到七層負(fù)載均衡/代理技術(shù)的開(kāi)發(fā)工作開(kāi)始復(fù)興巴柿。隨著分布式微服務(wù)系統(tǒng)的不斷推進(jìn)凛虽，這方面也會(huì)不斷進(jìn)步。從基礎(chǔ)上看广恢，目前對(duì)于靠不住的網(wǎng)絡(luò)的依賴(lài)越發(fā)嚴(yán)重凯旋，帶來(lái)更高的運(yùn)維難度。從長(zhǎng)遠(yuǎn)看钉迷，自動(dòng)伸縮至非、容器編排等技術(shù)的大量使用，意味著靜態(tài) IP糠聪、靜態(tài)文件的時(shí)代已經(jīng)過(guò)去了荒椭。系統(tǒng)不僅更多的使用網(wǎng)絡(luò)，而且更加動(dòng)態(tài)舰蟆，需要新的負(fù)載均衡功能趣惠。在本節(jié)中我們簡(jiǎn)單歸納一下現(xiàn)在七層負(fù)載均衡器的功能。

協(xié)議支持

現(xiàn)代七層負(fù)載均衡器加入了很多不同協(xié)議的顯式支持身害。負(fù)載均衡器對(duì)應(yīng)用通訊認(rèn)識(shí)越多味悄，就越能做好監(jiān)控輸出、高級(jí)負(fù)載均衡和路由等功能塌鸯。例如目前 Envoy 顯式的支持七層協(xié)議解析和路由的范圍包括 HTTP/1侍瑟、HTTP/2、gRPC丙猬、Redis涨颜、MongoDB 以及 DynamoDB。包括 MySQL 和 Kafka 在內(nèi)的更多協(xié)議會(huì)逐漸添加進(jìn)來(lái)茧球。

動(dòng)態(tài)配置

如上文所述庭瑰，分布式系統(tǒng)的大行其道，需要有動(dòng)態(tài)配置能力來(lái)提高系統(tǒng)的動(dòng)態(tài)和控制能力袜腥。Istio就是一個(gè)這種系統(tǒng)的例子见擦。請(qǐng)參考 Service Mesh Data Plan vs Control Plan 來(lái)獲取更多這方面的內(nèi)容。

高級(jí)負(fù)載均衡

七層負(fù)載均衡器一般都有內(nèi)置的高級(jí)負(fù)載均衡支持羹令，例如超時(shí)鲤屡、重試、頻率控制福侈、斷路器酒来、Shadow、緩沖肪凛、基于內(nèi)容的路由等堰汉。

可觀測(cè)性

上文中也提到過(guò)辽社，負(fù)載均衡的一個(gè)常見(jiàn)功能，越來(lái)越多的動(dòng)態(tài)系統(tǒng)被部署翘鸭，調(diào)試難度也水漲船高滴铅。健壯的協(xié)議規(guī)范觀測(cè)輸出可能是未來(lái)七層負(fù)載均衡器要提供的最重要功能之一。統(tǒng)計(jì)數(shù)字就乓、分布式跟蹤以及可以定義日志的輸出汉匙，目前已經(jīng)成為對(duì)器層負(fù)載均衡解決方案的必須要求。

擴(kuò)展性

現(xiàn)代七層負(fù)載均衡器需要能夠簡(jiǎn)單的加入定制功能生蚁。這一功能可以通過(guò)編寫(xiě)可插接過(guò)濾器噩翠，并載入到負(fù)載均衡器的方式來(lái)實(shí)現(xiàn)。很多負(fù)載均衡器還支持腳本擴(kuò)展邦投，例如 Lua伤锚。

容錯(cuò)

在講四層負(fù)載均衡的容錯(cuò)時(shí)頗費(fèi)了一番口舌。七層負(fù)載均衡的容錯(cuò)又怎樣呢志衣？一般來(lái)說(shuō)我們認(rèn)為七層負(fù)載均衡器（的工作負(fù)載）是無(wú)狀態(tài)的可拋棄的屯援。使用普通軟件就能夠簡(jiǎn)單的對(duì)七層負(fù)載均衡器進(jìn)行水平擴(kuò)展。另外七層負(fù)載均衡的流量處理和狀態(tài)跟蹤的復(fù)雜度要遠(yuǎn)超四層蠢涝。設(shè)置七層負(fù)載均衡器的 HA 配對(duì)在技術(shù)上是可行的玄呛，但會(huì)非常繁雜。

總的說(shuō)來(lái)和二，不管是四層還是七層的負(fù)載均衡，業(yè)界都在嘗試走出 HA 配對(duì)模式耳胎，轉(zhuǎn)向一致性哈希為基礎(chǔ)的水平擴(kuò)展方式惯吕。

更多

七層負(fù)載均衡器正在高速發(fā)展∨挛纾可以參考 Envoy 架構(gòu)概覽废登。

5

****全局負(fù)載均衡和中心控制平面****

image

圖 13：全局負(fù)載均衡

未來(lái)會(huì)有越來(lái)越多的獨(dú)立負(fù)載均衡器以商品設(shè)備的面目呈現(xiàn)。我認(rèn)為真正的創(chuàng)新和商業(yè)機(jī)會(huì)來(lái)自于控制平面郁惜。圖 13展示了一個(gè)全局負(fù)載均衡系統(tǒng)堡距。在本例中有一些不同的東西：

• 每個(gè) Sidecar 代理和三個(gè)不同區(qū)域的后端進(jìn)行通信。

• 如圖兆蕉，90% 的流量會(huì)被發(fā)送到 C 區(qū)羽戒，A B 兩區(qū)分別得到 5%。

• Sidecar 代理和后端都會(huì)周期性的向全局負(fù)載均衡器進(jìn)行匯報(bào)虎韵。這樣全局負(fù)載均衡器就可以根據(jù)延遲易稠、成本、負(fù)載包蓝、失敗率等數(shù)據(jù)進(jìn)行精密決策驶社。

• 全局負(fù)載均衡周期性的使用當(dāng)前的路由信息配置每個(gè) Sidecar 代理企量。

全局負(fù)載均衡能做一些單一負(fù)載均衡器做不到的事情，例如：

• 對(duì)分區(qū)故障的自動(dòng)檢測(cè)和路由繞行亡电。

• 應(yīng)用全局的安全和路由策略届巩。

• 使用機(jī)器學(xué)習(xí)和神經(jīng)網(wǎng)絡(luò)，對(duì)異常流量進(jìn)行檢測(cè)和防范份乒，包括分布式拒絕服務(wù)攻擊姆泻。

• 提供中央界面和可視化支持，讓工程師能夠以聚合的角度冒嫡，對(duì)整個(gè)分布式系統(tǒng)進(jìn)行監(jiān)控和運(yùn)維拇勃。

全局負(fù)載均衡器要成為現(xiàn)實(shí)，他的數(shù)據(jù)平面必須具有強(qiáng)大的動(dòng)態(tài)配置能力孝凌。請(qǐng)參考我的博客：Envoy's universal data plane API方咆，以及 Service Mesh Data Plan vs Control Plan 。

6

******從硬件到軟件的變革******

這里只是簡(jiǎn)要的提到了硬件和軟件的問(wèn)題蟀架，主要聚焦在四層負(fù)載均衡高可用方面的歷史問(wèn)題瓣赂。這一領(lǐng)域的業(yè)界趨勢(shì)又如何呢？

這一推雖說(shuō)略顯浮夸片拍，但卻很好的描述了技術(shù)趨勢(shì)：

• 歷史上的負(fù)載均衡器和路由器都曾經(jīng)是昂貴的專(zhuān)屬硬件

• 逐漸的煌集，多數(shù)三層四層網(wǎng)絡(luò)設(shè)備都被替換為通用服務(wù)器硬件和網(wǎng)卡，以及基于 IPVS捌省、DPDK 和 fd.io之類(lèi)的框架的特定軟件方案苫纤。一個(gè)現(xiàn)代的成本低于 $5k 的數(shù)據(jù)中心，運(yùn)行 Linux 和自定義的基于 DPDK 的 user-space 應(yīng)用纲缓，能夠輕松用超小數(shù)據(jù)包跑滿 80Gbps 的網(wǎng)絡(luò)卷拘。另外廉價(jià)的基于 ASICs 的基礎(chǔ)路由器/交換機(jī)也能夠完成 ECMP 路由工作，并能支撐和通用路由器同級(jí)別的帶寬和包速率祝高。

• Nginx栗弟、HAProxy 以及 Envoy 這樣的七層軟負(fù)載均衡，也正快速發(fā)展工闺，逐步進(jìn)入過(guò)去由 F5 這樣的廠商的專(zhuān)屬領(lǐng)域乍赫。此外，七層負(fù)載均衡器正激進(jìn)的向通用軟件方案的方向邁進(jìn)陆蟆。

• 同時(shí)雷厂，主要云提供商推動(dòng)的 IaaS、CaaS 以及 FaaS 潮流遍搞，使得只有一小部分人需要理解物理網(wǎng)絡(luò)(這屬于黑科技罗侯，以及“我們不再需要深入了解”的范圍了)。

7

******結(jié)論溪猿，以及負(fù)載均衡器的未來(lái)******

綜上所述钩杰，本文的主旨：

• 負(fù)載均衡器是現(xiàn)代分布式系統(tǒng)的關(guān)鍵組件纫塌。

• 有兩種負(fù)載均衡器：四層和七層。

• 四層和七層負(fù)載均衡器都與現(xiàn)代架構(gòu)相關(guān)讲弄。

• 四層負(fù)載均衡器正在朝著基于一致性哈希的水平擴(kuò)展方案的方向進(jìn)行遷移措左。

• 由于動(dòng)態(tài)微服務(wù)架構(gòu)的成長(zhǎng)，七層負(fù)載均衡器得以快速發(fā)展避除。

• 控制平面和數(shù)據(jù)平面的拆分怎披，和全局負(fù)載均衡，是負(fù)載均衡的未來(lái)發(fā)展方向和機(jī)會(huì)來(lái)源瓶摆。

• 業(yè)界正激進(jìn)的邁向標(biāo)準(zhǔn)硬件和軟件的開(kāi)源解決方案凉逛。我相信傳統(tǒng)的像 F5 這樣的負(fù)載均衡廠商會(huì)被開(kāi)源軟件和云供應(yīng)商取代。傳統(tǒng)的路由器群井、交換機(jī)廠商状飞，例如 Arista/Cumulus 等，短期內(nèi)會(huì)有更好的發(fā)展书斜，但最終也會(huì)被共有云提供商及其自研物理網(wǎng)絡(luò)所取代诬辈。

總的說(shuō)來(lái)，我認(rèn)為這是計(jì)算器網(wǎng)絡(luò)的奇跡年代荐吉。多數(shù)系統(tǒng)開(kāi)始向開(kāi)源和軟件方向轉(zhuǎn)變焙糟，極大的提高了迭代速度。未來(lái)样屠，分布式系統(tǒng)又向無(wú)服務(wù)器計(jì)算進(jìn)軍穿撮，底層網(wǎng)絡(luò)和負(fù)載均衡系統(tǒng)的復(fù)雜性也勢(shì)必齊頭并進(jìn)，水漲船高瞧哟。

原文：https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236