全局代理是什么意思呢，全局代理是什么意思呢英文？

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

現(xiàn)代對(duì)網(wǎng)絡(luò)銅元均衡和代理的定義涵蓋了計(jì)算的各個(gè)方面，不單是網(wǎng)絡(luò)。操作系統(tǒng)使用負(fù)載均衡在不同物理處理器上調(diào)度任務(wù)，K8S這樣的容器編排引擎通過(guò)負(fù)載均衡在計(jì)算機(jī)集群上調(diào)度任務(wù)，網(wǎng)絡(luò)負(fù)載均衡器在可用的后端之間調(diào)度網(wǎng)絡(luò)任務(wù)。本文接下來(lái)只討論網(wǎng)絡(luò)負(fù)載均衡。

圖1：網(wǎng)絡(luò)負(fù)載均衡架構(gòu)圖

圖1是網(wǎng)絡(luò)負(fù)載均衡的高層架構(gòu)圖。若干客戶端正在訪問(wèn)若干后端服務(wù)，它們中間是一個(gè)負(fù)載均衡器；從高層看，負(fù)載均衡器完成以下功能：

• 服務(wù)發(fā)現(xiàn)：系統(tǒng)中的哪些后端是可用的？它們的地址是多少（例如，負(fù)責(zé)均衡器如何和它們通信）？
• 健康檢查：當(dāng)前哪些后端是健康的，可以接收請(qǐng)求？
• 負(fù)載均衡：應(yīng)該用什么算法將請(qǐng)求平衡地轉(zhuǎn)發(fā)到健康的后端服務(wù)？

負(fù)載均衡使用得當(dāng)可以給分布式系統(tǒng)帶來(lái)很多好處：

• 命名抽象（Namingabstraction）：客戶端可以通過(guò)預(yù)設(shè)的機(jī)制訪問(wèn)LB，域名解析工作交給LB，這樣每個(gè)客戶端就無(wú)需知道每個(gè)后端（服務(wù)發(fā)現(xiàn)）。預(yù)設(shè)的機(jī)制包括內(nèi)置庫(kù)、眾所周知的DNS/IP/port，接下來(lái)會(huì)詳細(xì)討論
• 容錯(cuò)：通過(guò)健康檢查和多種算法，LB可以將請(qǐng)求有效地路由到負(fù)載過(guò)高的后端。這意味著運(yùn)維人員可以從容地修復(fù)異常的后端，而不用慌張
• 成本和性能收益：分布式系統(tǒng)的網(wǎng)絡(luò)很少是同構(gòu)的（homogeneous）。系統(tǒng)很可能跨多個(gè)網(wǎng)絡(luò)zone（可用區(qū)）和region（相隔較遠(yuǎn)的地理區(qū)域，這兩者都是云計(jì)算術(shù)語(yǔ)，有嚴(yán)格定義，想進(jìn)一步了解請(qǐng)自行搜索）。在每個(gè)zone內(nèi)部，網(wǎng)絡(luò)的利用率相對(duì)較低；zone之間，利用率經(jīng)常達(dá)到上限。（這里利用率的衡量公式：網(wǎng)卡帶寬/路由器之間帶寬）。智能負(fù)載均衡可以最大限度地將請(qǐng)求流量保持在zone內(nèi)部，既提高了性能（延遲降低），又減少了整體的系統(tǒng)成本（減少跨zone帶寬及光纖成本）

1.1、負(fù)載均衡器vs代理

在業(yè)內(nèi)討論網(wǎng)絡(luò)負(fù)載均衡器的時(shí)候，負(fù)載均衡器（loadbalancer）和代理（proxy）兩個(gè)術(shù)語(yǔ)經(jīng)常（大體上）無(wú)差別混用。本文中也將沿用這種慣例，認(rèn)為二者整體上是對(duì)等的。（嚴(yán)格地從學(xué)術(shù)角度來(lái)說(shuō)，不是所有代理都是負(fù)載均衡器，但絕大部分代理的核心功能都包括負(fù)載均衡。）

有人可能會(huì)說(shuō)，當(dāng)負(fù)載均衡內(nèi)嵌到客戶端庫(kù)作為庫(kù)的一部分的時(shí)候，負(fù)載均衡器并不是一個(gè)代理。對(duì)此我的意見是，這種區(qū)分只是給本已令人困惑的主題又增加了不必要的復(fù)雜性。本文后面會(huì)討論負(fù)載均衡器拓?fù)涞念愋?，其中將把嵌入式?fù)載均衡器拓?fù)渥鳛橐环N特殊的代理；應(yīng)用通過(guò)內(nèi)嵌的庫(kù)進(jìn)行代理轉(zhuǎn)發(fā)，這個(gè)庫(kù)提供的抽象和一個(gè)位于應(yīng)用進(jìn)程之外的負(fù)載均衡器是一樣的。

1.2、L4（會(huì)話/連接層）負(fù)載均衡

現(xiàn)在，當(dāng)業(yè)內(nèi)討論負(fù)載均衡的時(shí)候，所有解決方案通常分為兩類：L4和L7。這兩者分別對(duì)應(yīng)OSI模型的4層和7層。不過(guò)我認(rèn)為使用這個(gè)術(shù)語(yǔ)相當(dāng)不幸，在后面討論L7負(fù)載均衡的時(shí)候會(huì)明顯看到這一點(diǎn)。OSI模型是一個(gè)很差的對(duì)負(fù)載均衡解決方案復(fù)雜度的近似，這些解決方案包含4層協(xié)議，例如TCP和UDP，但經(jīng)常又包括一些OSI其他協(xié)議層的內(nèi)容。比如，如果一個(gè)L4TCPLB同時(shí)支持TLStermination，那它現(xiàn)在是不是一個(gè)L7LB？

圖2：TCPL4termination負(fù)載均衡

圖2是傳統(tǒng)的L4TCP負(fù)載均衡器。這種情況下，客戶端建立一個(gè)TCP連接到LB。LB終止（terminate）這個(gè)連接（例如，立即應(yīng)答SYN包），選擇一個(gè)后端，然后建立一個(gè)新的TCP連接到后端（例如，發(fā)送一個(gè)新的SYN包）。不要太在意圖中的細(xì)節(jié)，我們?cè)诤竺嬲鹿?jié)會(huì)專門討論L4負(fù)載均衡。

本節(jié)想說(shuō)明的是，典型情況下，L4負(fù)載均衡器只工作在L4TCP/UDPconnection/session。因此，LB在雙向來(lái)回轉(zhuǎn)發(fā)字節(jié)，保證屬于同一session的字節(jié)永遠(yuǎn)落到同一后端。L4LB不感知其轉(zhuǎn)發(fā)字節(jié)所屬應(yīng)用的任何細(xì)節(jié)。這些字節(jié)可能是HTTP、Redis、MongoDB，或者任何其他應(yīng)用層協(xié)議。

1.3、L7（應(yīng)用層）負(fù)載均衡

L4負(fù)載均衡很簡(jiǎn)單，應(yīng)用范圍也很廣。那么，相比于L7（應(yīng)用層）負(fù)載均衡，L4有哪些缺點(diǎn)？設(shè)想如下L4特殊場(chǎng)景：

• 兩個(gè)gRPC/HTTP2客戶端想連接到后端，因此它們通過(guò)L4LB建立連接
• L4LB為每個(gè)（從客戶端）進(jìn)來(lái)的連接建立一個(gè)出去的（到后端）的連接，因此最終由兩個(gè)進(jìn)來(lái)的連接和兩個(gè)出去的連接
• 客戶端A的連接每分鐘發(fā)送1個(gè)請(qǐng)求，而客戶端B的連接每秒發(fā)送50個(gè)請(qǐng)求

在以上場(chǎng)景中，選中的處理客戶端A請(qǐng)求的后端比選中的處理客戶端B請(qǐng)求的后端，負(fù)載要相差3000x倍。這個(gè)問(wèn)題非常嚴(yán)重，與負(fù)載均衡的目的背道而馳。而且要注意，對(duì)任何multiplexing，kept-alive（多路復(fù)用，?；睿﹨f(xié)議，都存在這個(gè)問(wèn)題。（Multiplexing表示通過(guò)單個(gè)L4連接發(fā)送并發(fā)應(yīng)用的請(qǐng)求，kept-alive表示當(dāng)沒有主動(dòng)的請(qǐng)求時(shí)也不要關(guān)閉連接）。出于性能考慮（創(chuàng)建連接的開銷是非常大的，尤其是連接是使用TLS加密的時(shí)候），所有現(xiàn)代協(xié)議都在演進(jìn)以支持multiplexing和kept-alive，因此L4LB的阻抗不匹配問(wèn)題（impedancemismatch）隨時(shí)間越來(lái)越彰顯。這個(gè)問(wèn)題被L7LB解決了。

圖3：HTTP/2L7負(fù)載均衡

圖3是一個(gè)L7HTTP/2負(fù)載均衡器。這種情況下，客戶端與LB只建立一個(gè)HTTP/2TCP連接。LB接下來(lái)和兩個(gè)后端建立連接。當(dāng)客戶端向LB發(fā)送兩個(gè)HTTP/2流（streams）時(shí)，stream1會(huì)被發(fā)送到后端1，而stream2會(huì)被發(fā)送到后端2。因此，即使不同客戶端的請(qǐng)求數(shù)量差異巨大，這些請(qǐng)求也可以被高效地、平衡地分發(fā)到后端。這就是L7LB對(duì)現(xiàn)代協(xié)議如此重要的原因。L7負(fù)載均衡具備檢測(cè)應(yīng)用層流量的能力，這帶來(lái)了大量額外的好處，我們后面會(huì)更詳細(xì)看到。

1.4、L7負(fù)載均衡和OSI7層模型

前面討論L4負(fù)載均衡時(shí)我說(shuō)過(guò)，使用OSI模型描述負(fù)載均衡特性是有問(wèn)題的。原因是，對(duì)于L7，至少按照OSI模型的描述，它本身就包括了負(fù)載均衡抽象的多個(gè)獨(dú)立層級(jí)（discretelayers），例如，對(duì)于HTTP流量考慮如下子層級(jí)：

• 可選的TLS（TransportLayerSecurity）層。網(wǎng)絡(luò)領(lǐng)域的人們還在爭(zhēng)論TLS到底屬于OSI的哪一層。本文出于討論目的將假設(shè)它屬于L7
• 物理HTTP協(xié)議（HTTP/1或者HTTP/2）
• 邏輯HTTP協(xié)議（headers,bodydata,trailers）
• 消息協(xié)議（gRPC,REST等等）

一個(gè)復(fù)雜的L7LB可能會(huì)提供與以上全部子層級(jí)相關(guān)的特性，而另一個(gè)L7LB可能會(huì)認(rèn)為其中只有一部分才屬于7層的功能，因此只提供這個(gè)子集的功能。也就是說(shuō)，如果要比較負(fù)載均衡器的特性（features），L7的范圍比L4的復(fù)雜的多。（當(dāng)然，這里我們只涉及了HTTP；Redis、Kafka、MongoDB等等都是L7LB應(yīng)用層協(xié)議的例子，它們都受益于7層負(fù)載均衡。）

2、負(fù)載均衡器特性

本節(jié)將簡(jiǎn)要總結(jié)負(fù)載均衡器提供的高層特性（highlevelfeatures）。但并不是所有負(fù)載均衡器都提供這里的所有特性。

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

服務(wù)發(fā)現(xiàn)是負(fù)載均衡器判斷它有哪些可用后端的過(guò)程。用到的方式差異很大，這里給出幾個(gè)例子：

• 靜態(tài)配置文件
• DNS
• Zookeeper,Etcd,Consul等待
• Envoy的通用數(shù)據(jù)平面API（universaldataplaneAPI）

2.2、健康檢查

健康檢查是負(fù)載均衡器判斷它的后端是否可以接收請(qǐng)求的過(guò)程。大致分為兩類：

• 主動(dòng)：LB定時(shí)向后端發(fā)送ping消息（例如，向/healthcheck發(fā)送HTTP請(qǐng)求），以此測(cè)量后端健康狀態(tài)
• 被動(dòng)：LB從數(shù)據(jù)流中檢測(cè)健康狀態(tài)。例如，L4LB可能會(huì)認(rèn)為如果一個(gè)后端有三次連接錯(cuò)誤，它就是不健康的；L7LB可能會(huì)認(rèn)為如果后端有503錯(cuò)誤碼就是不健康的

2.3、負(fù)載均衡

LB必須保證負(fù)載是均衡的。給定一組健康的后端，如何選擇哪個(gè)后端來(lái)處理一個(gè)連接或一個(gè)請(qǐng)求呢？負(fù)載均衡算法是一個(gè)相對(duì)活躍的研究領(lǐng)域，從簡(jiǎn)單的隨機(jī)選擇、RoundRobin，到更復(fù)雜的考慮各種延遲和后端負(fù)載狀態(tài)的算法。最流行的負(fù)載均衡算法之一是冪次最少請(qǐng)求（powerof2leastrequest）負(fù)載均衡。

2.4、StickySession（黏性會(huì)話）

對(duì)于一些特定應(yīng)用，保證屬于同一session的請(qǐng)求落到同一后端非常重要。這可能需要考慮緩存、結(jié)構(gòu)復(fù)雜的臨時(shí)狀態(tài)等問(wèn)題。session的定義也并不相同，可能會(huì)包括HTTPcookies、客戶端連接特性（properties），或者其他一些屬性。一些L7LB支持stickysession。但這里我要說(shuō)明的是，sessionstickiness本質(zhì)上是脆弱的（處理/保持session的后端會(huì)掛掉），因此如果設(shè)計(jì)的系統(tǒng)依賴這個(gè)特性，那要額外小心。

2.5、TLSTermination

關(guān)于TLS以及它在邊緣服務(wù)（edgeserving）和安全的service-to-service通信中扮演的角色，值得單獨(dú)寫一篇文章，因此這里不詳細(xì)展開。許多L7LB會(huì)做大量的TLS處理工作，包括termination、證書驗(yàn)證和綁定（verificationandpinning）、使用SNI提供證書服務(wù)等等。

2.6、可觀測(cè)性（observability）

我在技術(shù)分享中喜歡說(shuō)：“可觀測(cè)性、可觀測(cè)性、可觀測(cè)性?！本W(wǎng)絡(luò)在本質(zhì)上是不可靠的，LB通常需要導(dǎo)出統(tǒng)計(jì)、跟蹤和日志信息，以幫助運(yùn)維判斷出了什么問(wèn)題并修復(fù)它。負(fù)載均衡器輸出的可觀測(cè)性數(shù)據(jù)差異很大。最高級(jí)的負(fù)載均衡器提供豐富的輸出，包括數(shù)值統(tǒng)計(jì)、分布式跟蹤以及自定義日志。需要指出的是，豐富的可觀測(cè)數(shù)據(jù)并不是沒有代價(jià)的，負(fù)載均衡器需要做一些額外的工作才能產(chǎn)生這些數(shù)據(jù)。但是，這些數(shù)據(jù)帶來(lái)的收益要遠(yuǎn)遠(yuǎn)大于為產(chǎn)生它們而增加的那點(diǎn)性能損失。

2.7、安全和DoS防御

至少（尤其）在邊緣部署拓?fù)洌ㄏ旅鏁?huì)看到）情況下，負(fù)載均衡器通常需要實(shí)現(xiàn)很多安全特性，包括限速、鑒權(quán)和DoS防御（例如，給IP地址打標(biāo)簽及分配標(biāo)識(shí)符、tarpitting等等）。

2.8、配置和控制平面

負(fù)載均衡器要可以配置。在大型部署場(chǎng)景中，這可能是一項(xiàng)很大的工作。一般地，將配置負(fù)載均衡器的系統(tǒng)稱為“控制平面”，其實(shí)現(xiàn)方式各異。

2.9、其他更多特性

本節(jié)對(duì)負(fù)載均衡器提供的功能做了一個(gè)非常淺的介紹。更多內(nèi)容我們會(huì)在下面討論L7LB的時(shí)候看到。

3、負(fù)載均衡器的拓?fù)漕愋?/span>

前面我們已經(jīng)覆蓋了負(fù)載均衡器的高層概覽，L4和L7負(fù)載均衡器的區(qū)別，以及負(fù)載均衡器的功能特性等內(nèi)容，接下來(lái)介紹它的分布式部署拓?fù)洌ㄏ旅娼榻B的每種拓?fù)涠歼m用于L4和L7負(fù)載均衡器）。

3.1、中間代理（middleproxy）

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

圖4所示的中間代理拓?fù)鋺?yīng)該是大家最熟悉的負(fù)載均衡方式。這一類型的方案包括：

• 硬件設(shè)備：Cisco、Juniper、F5等公司的產(chǎn)品
• 云軟件解決方案：Amazon的ALB和NLB，Google的CloudLoadBalancer
• 純軟件方案：HAProxy、NGINX、Envoy等等

中間代理模式的優(yōu)點(diǎn)是簡(jiǎn)單，用戶一般只需要通過(guò)DNS連接到LB，其他的事情就不用關(guān)心了。缺點(diǎn)是，這種模式下負(fù)載均衡器（即使已經(jīng)做了集群）是單點(diǎn)的（singlepointoffailure），而且橫向擴(kuò)展有瓶頸。

中間代理很多情況下都是一個(gè)黑盒子，給運(yùn)維帶來(lái)很多困難。例如發(fā)生故障的時(shí)候，很難判斷問(wèn)題是出在客戶端，中間代理，還是后端。

3.2、邊緣代理（edgeproxy）

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

圖5所示的邊緣代理拓?fù)淦鋵?shí)只是中間代理拓?fù)涞囊粋€(gè)變種，這種情況下負(fù)載均衡器是可以從因特網(wǎng)直接訪問(wèn)的。這種場(chǎng)景下，負(fù)載均衡器通常還要提供額外的“API網(wǎng)關(guān)”功能，例如TLStermination、限速、鑒權(quán)，以及復(fù)雜的流量路由等等。

中間代理拓?fù)涞膬?yōu)缺點(diǎn)對(duì)邊緣代理也是適用的。需要說(shuō)明的是，對(duì)于面向因特網(wǎng)的分布式系統(tǒng)，部署邊緣代理通常是無(wú)法避免的?？蛻舳艘话阃ㄟ^(guò)DNS訪問(wèn)系統(tǒng)，而它使用什么網(wǎng)絡(luò)庫(kù)，服務(wù)方是控制不了的（下文會(huì)看到的客戶端內(nèi)嵌庫(kù)或sidecar代理拓?fù)湓诖瞬贿m用）。另外，從安全的角度考慮，所有來(lái)自因特網(wǎng)的流量都通過(guò)唯一的網(wǎng)關(guān)進(jìn)入系統(tǒng)是比較好的。

3.3、客戶端內(nèi)嵌庫(kù)（embeddedclientlibrary）

圖6：客戶端內(nèi)嵌庫(kù)實(shí)現(xiàn)負(fù)載均衡

為了解決中間代理拓?fù)涔逃械膯吸c(diǎn)和擴(kuò)展問(wèn)題，出現(xiàn)了一些更復(fù)雜的方案，例如將負(fù)載均衡器已函數(shù)庫(kù)的形式內(nèi)嵌到客戶端，如圖6所示。這些庫(kù)支持的特性差異非常大，最知名的庫(kù)包括Finagle、Eureka/Ribbon/Hystrix、gRPC（大致基于一個(gè)Google內(nèi)部系統(tǒng)Stubby）。

這種拓?fù)涞淖畲髢?yōu)點(diǎn)是：將LB的全部功能下放到每個(gè)客戶端，從而完全避免了單點(diǎn)和擴(kuò)展問(wèn)題。缺點(diǎn)是：必須為公司使用的每種語(yǔ)言實(shí)現(xiàn)相應(yīng)的庫(kù)。分布式架構(gòu)正在變得越來(lái)越“polyglot”（multilingual，多語(yǔ)言化）。在這種情況下，為多種語(yǔ)言實(shí)現(xiàn)一個(gè)復(fù)雜的網(wǎng)絡(luò)庫(kù)是非常難的（prohibitive）。最后，對(duì)大型服務(wù)架構(gòu)，進(jìn)行客戶端升級(jí)也是一件極其痛苦的事情，最終很可能導(dǎo)致生產(chǎn)集群中同時(shí)運(yùn)行多個(gè)版本的客戶端，增加運(yùn)維和認(rèn)知（cognitive）負(fù)擔(dān)。

雖然如此，但是那些在能夠限制語(yǔ)言數(shù)量增加（proliferation）而且能夠解決客戶端升級(jí)痛苦的公司，這種拓?fù)溥€是取得了成功的。

3.4、sidecar代理

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

客戶端內(nèi)嵌庫(kù)拓?fù)涞囊粋€(gè)變種是sidecar拓?fù)?，如圖7所示。近年來(lái)這種拓?fù)浞浅Ａ餍校环Q為服務(wù)網(wǎng)格（servicemesh）。sidecar代理模式背后的思想是：通過(guò)將流量導(dǎo)到其他進(jìn)程的方式，犧牲一點(diǎn)（延遲）性能，實(shí)現(xiàn)客戶端內(nèi)嵌庫(kù)模式的所有好處，而無(wú)任何語(yǔ)言綁定（languagelock-in）。寫作本文時(shí)，最流行的sidecar代理有Envoy、NGINX、HAProxy、Linkerd。想了解sidercar模式負(fù)載均衡的更多信息，請(qǐng)查看我之前介紹Envoy的博客，以及servicemesh數(shù)據(jù)平面vs控制平面的博客。

3.5、不同拓?fù)漕愋偷膬?yōu)缺點(diǎn)比較

• 中間代理拓?fù)涫亲詈?jiǎn)單的負(fù)載均衡方式，缺點(diǎn)是單點(diǎn)故障、擴(kuò)展性問(wèn)題、以及黑盒運(yùn)維
• 邊緣代理拓?fù)浜椭虚g代理拓?fù)漕愃疲恍﹫?chǎng)景必須得用這種模式
• 客戶端內(nèi)嵌庫(kù)拓?fù)涮峁┝俗顑?yōu)的性能和擴(kuò)展性，但必須為每種語(yǔ)言實(shí)現(xiàn)相應(yīng)的庫(kù)，并且升級(jí)非常痛苦
• sidecar代理拓?fù)湫阅懿蝗缈蛻舳藘?nèi)嵌庫(kù)好，但沒有后者的那些缺點(diǎn)

總體上我認(rèn)為在service-to-service通信中，sidecar（servicemesh）正在逐漸取代其他所有拓?fù)漕愋?。另外，在流量進(jìn)入servicemesh的地方，總是需要一個(gè)邊緣代理拓?fù)湄?fù)載均衡器。

4、當(dāng)前L4負(fù)載均衡最新技術(shù)

4.1、L4負(fù)載均衡還有用嗎？

我們前面已經(jīng)解釋了為什么L7負(fù)載均衡器對(duì)現(xiàn)代協(xié)議如此重要，接下來(lái)詳細(xì)討論L7LB的功能特性。這是否意味著L4LB沒用了？不！雖然我認(rèn)為在service-to-service通信中L7負(fù)載均衡最終會(huì)完全取代L4負(fù)載均衡，但L4負(fù)載均衡在邊緣仍然是非常有用的，因?yàn)閹缀跛械默F(xiàn)代大型分布式架構(gòu)都是在因特網(wǎng)流量接入處使用L4/L7兩級(jí)負(fù)載均衡架構(gòu)。在邊緣L7負(fù)載均衡器之前部署L4負(fù)載均衡器的原因：

• L7LB承擔(dān)的更多工作是復(fù)雜的分析、變換、以及應(yīng)用流量路由，他們處理原始流量的能力（按每秒處理的包數(shù)和字節(jié)數(shù)衡量）比經(jīng)過(guò)優(yōu)化的L4負(fù)載均衡器要差。這使得L4LB更適合處理特定類型的攻擊，例如SYN泛洪、通用包（genericpacket）泛洪攻擊等
• L7LB部署的更多更頻繁，bug也比L4LB多。在L7之前加一層L4LB，可以在調(diào)整L7部署的時(shí)候，對(duì)其做健康檢查和流量排除（drain），這比（單純使用）現(xiàn)代L4LB要簡(jiǎn)單的多，后者通常使用BGP和ECMP（后面會(huì)介紹）。最后，因?yàn)長(zhǎng)7功能更復(fù)雜，它們的bug也會(huì)比L4多，在前面有一層L4LB能及時(shí)將有問(wèn)題的L7LB拉出

接下來(lái)的幾節(jié)我將介紹中間/邊緣代理L4LB的幾種不同設(shè)計(jì)。這些設(shè)計(jì)通常不適用于客戶端內(nèi)嵌庫(kù)和sidecar代理拓?fù)淠Ｊ健?/span>

4.2、TCP/UDPtermination負(fù)載均衡

圖8：TCPL4termination負(fù)載均衡

第一種現(xiàn)在仍在用的L4LB是terminationLB，如圖8所示。這和我們最開始介紹L4負(fù)載均衡器時(shí)看到的圖是一樣的（圖2）。這種模式中，會(huì)使用兩個(gè)獨(dú)立的TCP連接：一個(gè)用于客戶端和負(fù)載均衡器之間，一個(gè)用于負(fù)載均衡器和后端之間。

L4負(fù)載均衡器仍然在用有兩個(gè)原因：

1. 他們實(shí)現(xiàn)相對(duì)簡(jiǎn)單
2. 連接terminate的地方離客戶端越近，客戶端的性能（延遲）越好。特別地，如果在一個(gè)有丟包的網(wǎng)絡(luò)（lossynetwork，例如蜂窩網(wǎng)）中將terminationLB部署的離客戶端很近，重傳可能就會(huì)更快的發(fā)生（retransmitsarelikelytohappenfasterpriortothedatabeingmovedtoreliablefibertransiten-routetoitsultimatelocation）。換句話說(shuō)，這種負(fù)載均衡方式可能會(huì)用于入網(wǎng)點(diǎn)（POP，PointofPresence）的rawTCPconnectiontermination

4.3、TCP/UDPpassthrough負(fù)載均衡

圖9：TCPpassthrough負(fù)載均衡

第二種L4負(fù)載均衡是passthrough，如圖9所示。在這種類型中，TCP連接不會(huì)被負(fù)載均衡器terminate，而是在建立連接跟蹤和網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）之后直接轉(zhuǎn)發(fā)給選中的后端。我們首先來(lái)定義連接跟蹤和NAT：

• 連接跟蹤（connectiontracking）：跟蹤所有活動(dòng)的TCP連接的狀態(tài)的過(guò)程。這包括握手是否成功、是否收到FIN包、連接已經(jīng)空閑多久、為當(dāng)前連接選擇哪個(gè)后端等
• NAT：利用連接跟蹤的數(shù)據(jù)，在包經(jīng)過(guò)負(fù)載均衡器時(shí)修改包的IP/port信息

使用連接跟蹤和NAT技術(shù)，負(fù)載均衡器可以將大部分rawTCP流量從客戶端轉(zhuǎn)發(fā)到后端。例如，我們假設(shè)客戶端正在和負(fù)載均衡器1.2.3.4:80通信，選中的后端是10.0.0.2:9000。當(dāng)客戶端的TCP包到達(dá)負(fù)載均衡器時(shí)，負(fù)載均衡器會(huì)將包的目的IP/port（從1.2.3.4:80）換成10.0.0.2:9000，以及將源IP/port換成負(fù)載均衡器自己的IP/port。當(dāng)應(yīng)答包回來(lái)的時(shí)候，負(fù)載均衡器再做相反的轉(zhuǎn)換。

為什么這種比terminatingLB更復(fù)雜的LB類型，會(huì)在某些場(chǎng)景中替換前者使用呢？幾點(diǎn)原因：

• 性能和資源消耗：passthroughLB不會(huì)terminateTCP連接，因此無(wú)需緩存任何TCP連接窗口。每個(gè)連接的狀態(tài)數(shù)據(jù)非常小，通?？梢酝ㄟ^(guò)哈希表直接查詢。因此，passthroughLB的性能（packetspersecond，PPS，每秒處理的包數(shù)）要比terminatingLB高很多
• 允許后端進(jìn)行自主擁塞控制：TCP擁塞控制是一種避免發(fā)送太快導(dǎo)致超過(guò)網(wǎng)絡(luò)帶寬或緩沖區(qū)的機(jī)制。passthroughLB不terminateTCP連接，因此它不參與擁塞控制。這使得后端可以根據(jù)應(yīng)用的類型自主決定采用哪種擁塞控制算法。而且，這種方式還使得驗(yàn)證擁塞控制的改動(dòng)更容易（例如，最近的BBRrollout）
• 是Directserverreturn(DSR)和L4LB集群化的基礎(chǔ)：很多高級(jí)的L4負(fù)載均衡技術(shù)基于passthroughLB，例如DSR和一致性哈希集群（下面討論）

4.4、DSR（直接服務(wù)器返回）

圖10：L4Directserverreturn(DSR，直接服務(wù)器返回）

DSRLB如圖10所示，它基于passthroughLB，對(duì)后者的改進(jìn)之處是：只允許進(jìn)來(lái)的流量/請(qǐng)求（ingress/request）經(jīng)過(guò)LB，而出去的流量/響應(yīng)（egress/response）直接從服務(wù)器返回到客戶端。

設(shè)計(jì)DSR的主要原因是：在一些場(chǎng)景中，響應(yīng)的流量要遠(yuǎn)遠(yuǎn)大于請(qǐng)求的流量（例如典型的HTTPrequest/response模式）。假設(shè)請(qǐng)求占10%的流量，響應(yīng)占90%，使用DSR技術(shù)，只需1/10的帶寬就可以滿足系統(tǒng)需求。因?yàn)樵缙诘呢?fù)載均衡器非常昂貴，這種類型的優(yōu)化可以極大地節(jié)省成本，還提高了負(fù)載均衡器的可靠性（流量越低肯定越好）。DSR在如下方面擴(kuò)展了passthroughLB：

• LB仍然做一部分連接跟蹤工作。因?yàn)轫憫?yīng)不再經(jīng)過(guò)LB，LB無(wú)法知道TCP連接的完整狀態(tài)。但是，它仍然可以根據(jù)客戶端的包以及多種類型的idletimeout，（strongly）推測(cè)連接的狀態(tài)
• 與NAT不同，負(fù)載均衡器通常使用GRE（GenericRoutingEncapsulation）將IP包封裝發(fā)送到后端。后端收到后進(jìn)行解封裝，就可以拿到原始的IP包，里面有客戶端的IP和port信息。因此后端可以直接將應(yīng)答包發(fā)給客戶端，而需要經(jīng)過(guò)LB
• DSR非常的重要一點(diǎn)是：后端參與負(fù)載均衡過(guò)程。后端需要配置正確的GRE隧道，視網(wǎng)絡(luò)設(shè)置的底層細(xì)節(jié)，GRE可能還需要自己的連接跟蹤和NAT

注意，不管是在passthrough還是DSR設(shè)計(jì)中，負(fù)載均衡器和后端之間的連接跟蹤、NAT、GRE等等都有多種設(shè)置方式。但不幸的是這個(gè)話題超出本文的討論范圍。

4.5、通過(guò)HApair實(shí)現(xiàn)容錯(cuò)

圖11：通過(guò)HApair和連接跟蹤實(shí)現(xiàn)L4容錯(cuò)

到目前為止，我們討論的都是單個(gè)L4LB。passthrough和DSR都需要LB保存一些連接跟蹤的狀態(tài)。假如LB掛了呢？如果一個(gè)LB實(shí)例掛了，那所有經(jīng)過(guò)這個(gè)LB的連接都會(huì)受到影響。視應(yīng)用的不同，這可能會(huì)對(duì)應(yīng)用性能產(chǎn)生很大影響。

歷史上，L4負(fù)載均衡器是從一些廠商（Cisco、Juniper、F5等等）購(gòu)買的硬件設(shè)備，這些設(shè)備非常昂貴，可以處理大量的網(wǎng)絡(luò)流量。為了避免單個(gè)負(fù)載均衡器掛掉導(dǎo)致應(yīng)用不可用，負(fù)載均衡器通常都是以高可用對(duì)（highavailabilitypair）方式部署的，如圖11所示。典型的HA負(fù)載均衡器設(shè)置包括：

• 一對(duì)HA邊緣路由器提供若干虛擬IP（virtualIP，VIP），并通過(guò)BGP(BorderGatewayProtocol)協(xié)議通告VIP。主（primary）邊緣路由器的BGP權(quán)重比備（backup）邊緣路由器的高，在正常情況下處理所有流量。（BGP是一個(gè)非常復(fù)雜的協(xié)議，出于本文討論目的，可以認(rèn)為BGP就是一種對(duì)外宣告哪個(gè)網(wǎng)絡(luò)設(shè)備配置了哪個(gè)IP的機(jī)制，每個(gè)設(shè)備有一個(gè)表示處理網(wǎng)絡(luò)流量的權(quán)重）
• 類似地，primaryL4LB向邊緣路由器宣告它的權(quán)重比backupLB大，因此正常情況下它處理所有流量
• primaryLB交叉連接（cross-connected）到backupLB，共享所有的連接跟蹤狀態(tài)。因此，假如primaryLB掛了，backupLB可以馬上接管所有活動(dòng)連接
• 兩個(gè)邊緣路由器和兩個(gè)負(fù)載均衡器都是交叉連接的。這意味著，如果一個(gè)邊緣路由器或一個(gè)負(fù)載均衡器掛了，或者由于某種原因之前聲明的BGP權(quán)重收回了（withdraw），backup馬上可以接受所有流量

以上就是許多大流量因特網(wǎng)應(yīng)用今天仍然在使用的架構(gòu)。然而，以上架構(gòu)也有很大的不足：

• VIP需要做容量規(guī)劃，并正確sharding給兩個(gè)負(fù)載均衡器實(shí)例。如果一個(gè)VIP（的連接數(shù)？）增長(zhǎng)超過(guò)了單個(gè)HApair的容量，那這個(gè)VIP需要分裂成多個(gè)VIP
• 資源利用率很低，平穩(wěn)狀態(tài)下50%的容量是空閑的?？紤]到有史以來(lái)硬件負(fù)載均衡器都是非常昂貴的，這意味著大量的資金沒有得到有效利用
• 現(xiàn)代分布式系統(tǒng)設(shè)計(jì)追求比active/backup更高的容錯(cuò)（faulttolerance）性。例如，理想情況下，一個(gè)系統(tǒng)有多個(gè)實(shí)例同時(shí)掛掉仍能繼續(xù)運(yùn)行。而HALBpair的主備實(shí)例同時(shí)掛掉時(shí)，服務(wù)就徹底掛了
• 供應(yīng)商提供的專有大型硬件設(shè)備非常昂貴，導(dǎo)致用戶被鎖死到廠商（vendorlock-in，即買了某個(gè)廠商的設(shè)備后，后期只能繼續(xù)買這個(gè)廠商的設(shè)備或服務(wù)）。通常期望的是，可以用基于通用服務(wù)器的、水平擴(kuò)展性良好的純軟件方案代替這些硬件設(shè)備

4.6、基于集群和一致性哈希的容錯(cuò)和可擴(kuò)展

圖12：基于負(fù)載均衡器集群和一致性哈希實(shí)現(xiàn)L4容錯(cuò)和可擴(kuò)展

前一節(jié)介紹了通過(guò)HApair實(shí)現(xiàn)L4LB的容錯(cuò)，以及這種設(shè)計(jì)固有的問(wèn)題。從2000s初期到中期，大型因特性基礎(chǔ)設(shè)施（公司）開始設(shè)計(jì)和部署全新的大規(guī)模并行L4負(fù)載均衡系統(tǒng)，如圖12所示。這些系統(tǒng)的設(shè)計(jì)目標(biāo)是：

• 避免HApair設(shè)計(jì)的所有缺點(diǎn)
• 從廠商的商業(yè)硬件方案，遷移到基于標(biāo)準(zhǔn)服務(wù)器和網(wǎng)卡的通用軟件方案

這種L4LB設(shè)計(jì)最合適的名稱是基于集群化和一致性哈希的容錯(cuò)和可擴(kuò)展（faulttoleranceandscalingviaclusteringanddistributedconsistenthashing）。它的工作原理如下：

• N個(gè)邊緣路由器以相同的BGP權(quán)重通告所有AnycastVIP。通過(guò)ECMP（Equal-cost,Multi-pathrouting）保證每個(gè)flow的所有包都會(huì)到達(dá)同一個(gè)邊緣路由器。一個(gè)flow通常是4元組：源IP/port和目的IP/port。簡(jiǎn)單來(lái)說(shuō)，ECMP是一種通過(guò)一致性哈希將包分發(fā)到一組權(quán)重相同的網(wǎng)絡(luò)設(shè)備的方式。雖然邊緣路由器通常并不關(guān)心每個(gè)包要發(fā)往哪里，但一般都是希望同一flow的所有包都以相同路徑經(jīng)過(guò)各個(gè)設(shè)備，因?yàn)檫@可以避免亂序代理的性能下降
• N個(gè)L4LB以相同的BGP權(quán)重向所有的邊緣路由器通告所有的VIP。仍然使用ECMP，邊緣路由器會(huì)為相同flow的包選擇相同的LB
• 每個(gè)L4LB實(shí)例會(huì)做部分連接跟蹤（partialconnectiontracking）工作，然后使用一致性哈希為每個(gè)flow選擇一個(gè)后端。通過(guò)GRE封裝將包從LB發(fā)送到后端
• 然后使用DSR將應(yīng)答包從后端直接發(fā)送到邊緣路由器，最后到客戶端
• L4LB用到的一致性哈希算法是一個(gè)熱門的研究領(lǐng)域。需要在平衡負(fù)載、最小化延遲、最小化后端變化帶來(lái)的擾動(dòng)、最小化內(nèi)存開銷等等之間做取舍。關(guān)于這一話題的完整討論超出了本篇的范圍

我們來(lái)看看以上的設(shè)計(jì)是如何避免了HApair的不足的：

• 邊緣路由器和負(fù)載均衡器實(shí)例可以按需添加。每一層都用到了ECMP，當(dāng)新實(shí)例加入的時(shí)候，ECMP能最大程度地減少受影響的flow數(shù)量
• 在預(yù)留足夠的突發(fā)量（burstmargin）和容錯(cuò)的前提下，系統(tǒng)的資源利用率想達(dá)到多高就可以到多高
• 邊緣路由器和負(fù)載均衡器都可以基于通用硬件搭建，成本只是傳統(tǒng)硬件LB的很小一部分（后面有更多信息）

很多讀者可能會(huì)問(wèn)：“為什么不讓邊緣路由器通過(guò)ECMP直接和后端通信？為什么我們還需要這一層負(fù)載均衡器？”這樣做主要的原因是防止DoS攻擊，以及方便后端的運(yùn)維。沒有這一層負(fù)載均衡，后端就得直接參與BGP，當(dāng)對(duì)后端集群進(jìn)行滾動(dòng)（rolling）部署時(shí)受影響程度會(huì)大很多。

所有現(xiàn)代L4負(fù)載均衡系統(tǒng)都在朝著這種設(shè)計(jì)（或其變種）演進(jìn)。其中最有名的兩個(gè)分別是來(lái)自Google的Maglev和來(lái)自Amazon的NetworkLoadBalancer。基于這種設(shè)計(jì)的開源方案目前還沒有，但據(jù)我所知，有一家公司準(zhǔn)備在2018年開源他們的產(chǎn)品。對(duì)此我非常興奮，因?yàn)楝F(xiàn)代L4LB是網(wǎng)絡(luò)領(lǐng)域的開源產(chǎn)品中仍然缺失的重要部分。

5、當(dāng)前L7負(fù)載均衡最新技術(shù)

過(guò)去幾年見證了L7負(fù)載均衡器/代理的一陣復(fù)興（resurgence）浪潮，這緊跟了分布式系統(tǒng)微服務(wù)化的發(fā)展趨勢(shì)。本質(zhì)上，當(dāng)使用更加頻繁時(shí)，天生有損的網(wǎng)絡(luò)（inherentlyfaultynetwork）越來(lái)越難以有效運(yùn)維。而且，自動(dòng)擴(kuò)縮容（autoscaling）、容器調(diào)度器等技術(shù)的崛起，意味著通過(guò)靜態(tài)文件配置靜態(tài)IP的方式早就過(guò)時(shí)了。系統(tǒng)不僅使用網(wǎng)絡(luò)更加頻繁，而且使用的方式越來(lái)越動(dòng)態(tài)，需要負(fù)載均衡器提供更多的功能。本節(jié)我將簡(jiǎn)要現(xiàn)代L7負(fù)載均衡器發(fā)展最快的幾個(gè)領(lǐng)域。

5.1、協(xié)議支持

現(xiàn)代L7負(fù)載均衡器正在顯示地添加對(duì)更多協(xié)議的支持。負(fù)載均衡器對(duì)應(yīng)用層協(xié)議了解的越多，就可以處理越多更復(fù)雜的事情，包括觀測(cè)輸出、高級(jí)負(fù)載均衡和路由等等。例如，在寫作本文時(shí)，Envoy顯式支持如下L7協(xié)議的解析和路由：HTTP/1、HTTP/2、gRPC、Redis、MongoDB、DynamoDB。未來(lái)可能會(huì)添加包括MySQL和Kafka在內(nèi)的更多協(xié)議。

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

如前面描述的，分布式系統(tǒng)越來(lái)越動(dòng)態(tài)的本質(zhì)需要同時(shí)在兩方面做投資：動(dòng)態(tài)和響應(yīng)式控制。Istio即使這種系統(tǒng)的一個(gè)例子。

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

L7LB現(xiàn)在一般都內(nèi)置高級(jí)負(fù)載均衡的特性，例如超時(shí)、重試、限速、熔斷（circuitbreaking）、流量鏡像（shadowing）、緩存、基于內(nèi)容的路由等等。

5.4、可觀測(cè)性

前面在介紹通用負(fù)載均衡器特性時(shí)講到，隨著部署的系統(tǒng)越來(lái)越動(dòng)態(tài)，debug也越來(lái)越困難。健壯的協(xié)議特定的（protocolspecific）可觀測(cè)性輸出可能是現(xiàn)代L7LB提供的最重要的特性。輸出數(shù)值統(tǒng)計(jì)、分布式跟蹤以及自定義日志等功能現(xiàn)在幾乎是L7負(fù)載均衡解決方案的標(biāo)配。

5.5、可擴(kuò)展性

現(xiàn)代L7LB的用戶常常希望能夠輕松地對(duì)它擴(kuò)展以添加自定義的功能。這可以通過(guò)編寫可插拔的過(guò)濾器，然后加載到負(fù)載均衡器實(shí)現(xiàn)。一些負(fù)載均衡器還支持腳本編程，典型的是通過(guò)Lua。

5.6、容錯(cuò)

前面介紹了很多L4LB容錯(cuò)的內(nèi)容。那么L7LB的容錯(cuò)又如何呢？通常來(lái)說(shuō)，我們認(rèn)為L(zhǎng)7LB是易消耗的和無(wú)狀態(tài)的（expendableandstateless）?；谕ㄓ密浖沟肔7負(fù)載均衡器可以輕松地實(shí)現(xiàn)水平擴(kuò)展。進(jìn)一步，L7LB的處理過(guò)程和狀態(tài)跟蹤比L4LB要復(fù)雜的多。搭建一個(gè)L7LBHApair技術(shù)上是可行的，但代價(jià)相當(dāng)大。

總體來(lái)說(shuō)，不管是在L4還是在L7負(fù)載均衡領(lǐng)域，業(yè)界都在從HApair架構(gòu)轉(zhuǎn)向基于一致性哈希的水平可擴(kuò)展架構(gòu)。

5.7、其他

L7負(fù)載均衡器正在以蹣跚的步伐演進(jìn)。以Envoy作為例子，讀者可以查看它的架構(gòu)綜述。

6、全局負(fù)載均衡和集中式控制平面

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

未來(lái)的負(fù)載均衡會(huì)越來(lái)越將單個(gè)負(fù)載均衡器看做通用設(shè)備（commoditydevice）。我個(gè)人覺得，真正的創(chuàng)新和商業(yè)機(jī)會(huì)全部都會(huì)在控制平面。圖13展示了全局負(fù)載均衡系統(tǒng)的一個(gè)例子。這個(gè)例子包含如下內(nèi)容：

• 每個(gè)sidecar同時(shí)和位于三個(gè)zone的后端通信
• 圖上可以看到，90%的流量到了zoneC，而zoneA和B各只有5%
• sidecar和后端都定期向全局負(fù)載均衡器匯報(bào)狀態(tài)。這使得全局負(fù)載均衡器可以基于延遲、代價(jià)、負(fù)載、當(dāng)前失敗率等參數(shù)做出決策
• 全局負(fù)載均衡器定期配置每個(gè)sidecar的路由信息

全局負(fù)載均衡器可以做越來(lái)越復(fù)雜、單個(gè)負(fù)載均衡器無(wú)法完成的事情。例如：

• 自動(dòng)檢測(cè)和路由zonalfailure（可用區(qū)級(jí)別失?。?/span>
• 應(yīng)用全局安全和路由策略
• 使用機(jī)器學(xué)習(xí)和神經(jīng)網(wǎng)絡(luò)技術(shù)檢測(cè)和緩解流量異常，包括DDoS攻擊
• 提供集中式UI和可視化平臺(tái)，方便工程師理解和運(yùn)維整個(gè)分布式系統(tǒng)

為了實(shí)現(xiàn)分布式負(fù)載均衡，作為數(shù)據(jù)平面使用的負(fù)載均衡器必須具有支持復(fù)雜的動(dòng)態(tài)配置的能力。這一話題的更多信息請(qǐng)參考我之前關(guān)于Envoy’suniversaldataplaneAPI以及servicemeshdataplanevs.controlplane的博客。

7、從硬件進(jìn)化到軟件

到目前為止本文只是對(duì)硬件和軟件做了簡(jiǎn)要對(duì)比，大部分內(nèi)容是在介紹傳統(tǒng)L4LBHApair的時(shí)候。那么，這一領(lǐng)域當(dāng)前的趨勢(shì)是什么呢？

上面這條tweet是一個(gè)很幽默的夸張，但確實(shí)很好地總結(jié)了當(dāng)前的趨勢(shì)：

• 從歷史來(lái)說(shuō)，路由器和負(fù)載均衡器都是廠商提供的專有硬件，非常昂貴。
• 越來(lái)越多的專有L3/L4網(wǎng)絡(luò)設(shè)備被通用服務(wù)器、通用網(wǎng)卡，以及基于IPVS、DPDK、fd.io等框架的特殊軟件方案代替。一臺(tái)現(xiàn)代數(shù)據(jù)中心的價(jià)格$5K以下機(jī)器，基于DPDK開發(fā)用戶態(tài)應(yīng)用程序在Linux發(fā)小包，很容易就可以用滿80Gbps的網(wǎng)卡帶寬。同時(shí)，人們正在將價(jià)格便宜的、ECMP路由聚合帶寬能力驚人的基礎(chǔ)路由器/交換機(jī)ASICs組裝成通用路由器。
• NGINX、HAProxy以及Envoy這樣的功能復(fù)雜的L7負(fù)載均衡器正在快速迭代，并不斷侵蝕原來(lái)硬件廠商例如F5的地盤。因此，L7LB也在非常有氣勢(shì)地朝著通用軟件方案邁進(jìn)。
• 同時(shí)，工業(yè)界幾個(gè)主要云廠商主導(dǎo)的以IaaS、CaaS、FaaA為整體演進(jìn)的趨勢(shì)，意味著將來(lái)只有很少一部分工程師需要了解物理的網(wǎng)絡(luò)是如何工作的（這些就是“黑科技”）。

8、總結(jié)及展望

最后總結(jié)，本文的核心內(nèi)容：

• 負(fù)載均衡器是現(xiàn)代分布式系統(tǒng)的一個(gè)核心組件
• 有兩類通用負(fù)載均衡器：L4和L7
• L4和L7負(fù)載均衡器在現(xiàn)代架構(gòu)中都有很重要的應(yīng)用場(chǎng)景
• L4負(fù)載均衡器正在朝著基于分布式一致性哈希的水平可擴(kuò)展架構(gòu)演進(jìn)
• L7負(fù)載均衡器近年來(lái)投入的資源非常大，源于最近火熱的動(dòng)態(tài)微服務(wù)架構(gòu)的需求
• 全局負(fù)載均衡，以及控制平面和數(shù)據(jù)平面的分離是負(fù)載均衡的未來(lái)，將來(lái)大部分創(chuàng)新和商業(yè)機(jī)會(huì)也都會(huì)在這兩個(gè)方向
• 對(duì)于網(wǎng)絡(luò)解決方案，工業(yè)界正在大步邁向通用開源硬件和軟件解決方案。我相信傳統(tǒng)負(fù)載均衡廠商，比如F5，會(huì)是最先被開源軟件和云廠商干掉的。傳統(tǒng)路由器/交換機(jī)廠商，例如Arista/Cumulus等，由于on-premisesdeployments（本地部署）的需求，我認(rèn)為存在時(shí)間會(huì)更長(zhǎng)一些，但最終會(huì)被云廠商和他們的自研物理網(wǎng)絡(luò)干掉

總體來(lái)說(shuō)，我認(rèn)為這是計(jì)算機(jī)網(wǎng)絡(luò)的一個(gè)令人振奮的時(shí)代。朝著開源和軟件方向的轉(zhuǎn)變使得大部分系統(tǒng)的迭代速度有了數(shù)量級(jí)（ordersofmagnitude）的提高。而且，隨著分布系統(tǒng)基于serverless設(shè)計(jì)，繼續(xù)朝著動(dòng)態(tài)化的目標(biāo)長(zhǎng)征，底層網(wǎng)絡(luò)和負(fù)載均衡系統(tǒng)的復(fù)雜性也會(huì)成比例的（commensurately）增加。

原文：Introduction to modern network load balancing and proxying

好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡(luò)推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525  備注：發(fā)貨聯(lián)盟引流學(xué)習(xí)； 我拉你進(jìn)直播課程學(xué)習(xí)群，每周135晚上都是有實(shí)戰(zhàn)干貨的推廣引流技術(shù)課程免費(fèi)分享！