[譯] 條分縷析拆解現代網絡負載均衡和代理技術

關于現代網絡負載均衡和代理（proxy）的介紹性資料很少，這件事引起了我的注意。為什么會這樣呢？構建一個可靠的分布式系統時，負載均衡是一個非常核心的概念。但可惜的是，搜索發現關于負載均衡和服務代理的內容很少。維基百科文章只包含了一些概念,沒有對該主題的詳細介紹，尤其是與現代微服務架構相關的。

本文試圖通過對現代網絡負載均衡和代理的簡單介紹，來彌補這部分信息的缺乏。為了保持文章的長度，盡量將復雜的話題濃縮成簡單的概述。

1

什么是網絡負載均衡和代理？

維基百科這樣定義負載均衡：

在計算中，負載均衡可以改善在多個計算機資源（如計算機，計算機集群，網絡鏈接，中央處理單元或磁盤驅動器）上的工作負載分布。負載均衡旨在優化資源的使用，最大吞吐量，及最小響應時間，避免任何單一資源的過載。通過使用多個組件而不是單個組件，負載均衡通過冗余來提高可靠性和可用性。負載均衡通常涉及專用軟件和硬件，例如多層交換機或域名系統服務器進程。

以上定義適用于計算的各個方面，而不僅僅是網絡。操作系統使用負載均衡在物理處理器之間安排任務，諸如Kubernetes之類的容器編排者使用負載均衡來計劃跨計算集群的任務，網絡負載均衡通過調用可用后端來平衡網絡任務。以下內容僅涵蓋網絡負載均衡。

圖 1: 網絡負載均衡描述

圖1展示了網絡負載均衡高層次的概覽。一些客戶端從后端請求資源。負載均衡器位于客戶端和后端之間，在更高層次執行關鍵任務：

• 服務發現： 在系統中哪些后端可用？地址是多少？（換句話說，負載均衡器如何與它們通信？）

• 健康檢查： 在系統中目前哪些后端是健康的，可以接受請求？

• 負載均衡： 用什么樣的算法把獨立的個人請求發給健康的后端？

在分布式系統中正確使用負載均衡會帶來如下好處：

• 命名抽象： 客戶端可以通過預定義的機制來尋址負載均衡器，而不是每個客戶端都需要了解每個后端（服務發現），然后將名稱解析的任務委托給負載均衡器。預定義的機制包括內置庫和眾所周知的DNS/IP/端口地址，后面會有詳細的討論。

• 容錯： 通過健康檢查和各種算法技術，負載均衡器的路由方法可以繞過壞的或者超負載的后端。這也意味著運維人員可以隨時優先修復后端錯誤。

• 低成本和高性能： 分布式系統網絡一致性比較差。系統可能會橫跨不同的網絡區域。在一個區域內，網絡之間通常以相對小的帶寬建立的。而在不同的區域之間，網絡大帶寬成為常態（帶寬的大小是指通過NIC使用的帶寬量占路由器之間可用帶寬的百分比）。智能的負載均衡可以盡可能保持區域內的請求流量，從而提高性能（低延遲）并降低整體系統成本（減少區域間的帶寬和光纖）。

負載均衡器VS代理

在談論到網絡負載均衡器，Load Balancer 和 Proxy 兩個術語在行業內可以互換使用。在本文中也把兩者視為一致的表達。（不過，不是所有的代理都是負載均衡器，但絕大多數代理都將負載均衡作為主要功能）。

一些人會爭辯說，當負載均衡器作為嵌入式客戶端庫的一部分實現時，這種負載均衡器并不是真正的代理。這種區分其實添加了不必要的復雜性。本文會詳細討論負載均衡器的拓撲類型，嵌入式負載均衡器是代理的一個特例，應用通過嵌入式庫進行代理，嵌入式庫與應用進程外的負載均衡器整體抽象是一致的。

L4（連接/會話）負載均衡

業界討論負載均衡時，解決方式往往分為兩類：L4 和 L7。指的是OSI模型的第四層和第七層。OSI模型包括傳統的第四層協議（如TCP和UDP），還包含各種不同OSI層的協議。換句話說，如果 L4 TCP負載均衡器也支持 TLS 終止，這不就是 L7負載均衡器么？

圖2：TCP L4 終止負載平衡

圖2展示了傳統的L4 TCP負載均衡器。在這種情況下，客戶端與負載均衡器建立TCP連接，負載均衡器終止連接（即直接響應SYN），選擇一個后端，并與后端建立新的TCP連接（即發起新的SYN）。

本節的關鍵是L4負載均衡器通常只在 L4 TCP / UDP連接/會話上運行。因此，負載平衡器負責操作字節，并確保來自同一會話的字節轉發到同一后端。L4負載平衡器并不知道通信中的任何應用細節。這些字節可能是 HTTP，Redis，MongoDB或任何其他應用協議。

L7（應用）負載平衡

L4負載均衡簡單，能看到廣泛使用。人們為什么放棄L4負載均衡，來研究L7（應用）負載均衡？以下是L4具體的案例：

• 兩個gRPC / HTTP2 客戶端通過L4負載均衡器與后端建立連接。

• L4負載均衡器為每個接入的TCP連接建立一個傳出的TCP連接，這樣就產生了兩個傳入和兩個傳出連接。

• 但是，客戶端A每分鐘發送 1個請求（RPM），而客戶端B通每秒發送50個請求（RPS）。

在上述場景中，后端選擇處理客戶端B請求是選擇客戶端A請求負載的大約3000倍。這是一個很大的問題，打破了負載均衡的目的。需要注意的是這個問題發生在任何復用，保持存活狀態的協議。（復用意味著通過單個L4連接多次發送應用程序請求，保持存活就是沒有活動請求時不關閉連接）。出于效率的考慮，所有現代協議都在不斷發展，既要復用也要存活（創建連接通常是昂貴的，特別是用TLS進行加密連接時），所以L4負載均衡器隨著時間的推移，負載失衡的情況更加明顯。這個問題在L7負載均衡器中得到解決。

圖3：HTTP / 2 L7終端負載均衡

圖3展示了L7 HTTP/2負載平衡器。客戶端與負載均衡器只建立一個 HTTP/2 TCP連接，連接兩個后端。當客戶端向負載均衡器發送兩個HTTP/2 流時，流1被發送到后端1，流2被發送到后端2。因此，即使差別很大的請求負載的多路復用客戶端也將被有效地平衡到不同的后端。這就是L7負載平衡對于現代協議的重要性所在。（L7負載平衡由于能夠檢查應用流量，而產生大量好處，后面會更詳述）。

L7負載均衡和OSI模型

正如L4負載平衡部分所述，使用OSI模型描述負載均衡功能是有問題的。原因在于L7本身包含多個離散的負載均衡抽象層。例如，對于HTTP流量，請考慮以下子層：

• 可選的傳輸層安全性（TLS）。網絡界對于TLS 屬于OSI模型哪一層有爭論。為了方便，我們考慮將TLS放在 L7。

• 物理HTTP協議（HTTP / 1或HTTP / 2）。

• 邏輯HTTP協議 (Header、Body 和 Trailer) 。

• 消息傳遞協議（gRPC，REST等）。

一個復雜的L7負載均衡器要提供與上述每個子層有關的功能。另L7負載均衡器可能只有一小部分功能屬于OSI模型中L7層。簡而言之，L7負載平衡器的功能遠比L4類型復雜得多。（HTTP、 Redis、Kafka、MongoDB等都是應用L7 協議的例子，它們受益于L7負載均衡）。

2

負載均衡器功能

在本節中將總結負載均衡器提供的高級功能，并非所有負載均衡器都提供全部功能。

服務發現

服務發現是負載平衡器確定可用后端的過程，實現的方式有很多種，一些例子包括：

• 靜態配置文件。

• DNS。

• Zookeeper，Etcd，Consul等。

• Envoy的通用數據平面API。

健康檢查

運行狀況檢查是負載均衡器確定后端是否可用來為流量提供服務的過程。健康檢查一般分為兩類：

• 主動式：負載平衡器將定期發送ping（例如，對/healthcheck端點的HTTP請求）到后端，并用它來衡量健康狀況。

• 被動式：負載均衡器從主數據流中檢測健康狀況。例如，如果連續出現三個連接錯誤，則L4負載均衡器會認為后端是不健康的。如果一行中有三個HTTP 503響應代碼，則L7負載均衡器會認為后端是不健康的。

負載均衡

負載均衡器必須實際平衡負載！當給定一組健康的后端時，選擇哪個后端處理請求？負載平衡算法是一個活躍的研究領域，從簡單的算法（如隨機選擇和循環算法）到考慮可變延遲和后端負載的更復雜的算法。考慮到其性能和簡單性，最流行的負載均衡算法是二節點最小請求負載均衡（power of 2 least request load balancing）。 

粘滯會話 （ Sticky sessions ）

在某些應用中，同一會話的請求到達相同的后端是很重要的。這與緩存，臨時復雜狀態等有關。會話的定義各不相同，可能包括HTTP Cookie，客戶端連接的配置或其他屬性。許多L7負載平衡器支持會話粘連。會話粘性本質上是脆弱的（后端保存的會話可能會失效），所以在設計系統的時候減少對它們的依賴。

TLS終止

關于TLS，它在邊緣服務和服務間通信方面值得肯定。因此，許多L7負載均衡器會執行大量的TLS處理，包括終止，證書驗證和保存，使用SNI的證書服務等。

可觀察性

正如談話中所強調的：“可觀察性，可觀察性，可觀察性”。網絡本質上是不可靠的，負載均衡器通常負責導出統計信息，跟蹤信息和記錄日志，幫助運營人員找出問題所在，從而解決問題。最先進的負載平衡器可觀察性輸出包括數字統計，分布式跟蹤和可定制的日志記錄。增強的可觀察性不是免費的; 負載平衡器必須做很多附加的工作來完成它。至于，負面影響，相對帶來的好處，幾乎不值一提。

安全性和 DoS 防范

特別是在邊緣部署拓撲（見下文）中，負載均衡器通常實施各種安全功能，包括速率限制，身份驗證和DoS防范（例如，IP地址標記和識別，緩送 Tarpitting 等）。

配置和控制面板

負載平衡器需要配置。在大規模部署中，這是一項重要工作。一般來說，配置負載均衡器的系統被稱為“控制面板”，并且在其實現中變化很大。

3

負載均衡器拓撲的類型

前面介紹了負載平衡器的概要，L4和L7負載平衡器之間的區別以及負載均衡器特性，接下來將轉向部署負載均衡器的各種分布式系統拓撲。（以下每種拓撲均適用于L4和L7負載均衡器）。

中間代理

圖4：中間代理負載均衡拓撲

圖4所示的中間代理拓撲是大多數讀者最熟悉的負載均衡一種方式。這一類包括Cisco，Juniper，F5等硬件設備; 云軟件解決方案，如亞馬遜的ALB和NLB以及Google的  Cloud Load Balancer  ; 以及HAProxy，NGINX和Envoy等純軟件自主托管解決方案。中間代理解決方案使用簡單。通常，用戶通過DNS連接到負載均衡器，不需要擔心其他任何事情。中間代理解決方案的特點是代理（即使是集群）是單一的故障點，也是擴展的瓶頸。中間代理通常是一個讓運維變得困難的黑匣子。當問題出現時，是在客戶端還是物理網絡？在中間代理還是后端？這很難說。

邊緣代理

圖5：邊緣代理負載平衡拓撲

圖5所示實際上只是中間代理拓撲的一種變體，負載均衡器通過Internet訪問。在這種情況下，負載均衡器通常必須提供附加的“API網關”功能，如TLS終止，速率限制，身份驗證和復雜的流量路由。邊緣代理的優缺點與中間代理相同。需要注意的是，在面向Internet的大型分布式系統中部署專用邊緣代理通常是不可避免的。客戶端通常需要使用服務所有者無法控制的任意網絡庫（后面會討論嵌入式客戶端庫或附屬代理拓撲結構不能直接在客戶端上運行）通過DNS訪問系統。另外，由于安全原因，希望具有單個網關，通過該網關，所有面向互聯網的流量進入系統。

嵌入式客戶端庫

圖6：通過嵌入式客戶端庫進行負載平衡

為了避免中間代理拓撲中固有的單點故障和擴展問題，更復雜的基礎設施已經開始將負載均衡器直接嵌入到服務庫中，如圖6所示。支持的功能庫有很大的不同，但是這個類別中最知名和最豐富的功能包括Finagle，Eureka / Ribbon / Hystrix和gRPC（松散地基于稱為Stubby的內部Google系統）。基于庫的解決方案的主要功能是將負載均衡器的所有功能完全分配給每個客戶端，從而消除之前描述的單點故障和擴展問題。基于客戶端庫的解決方案的主要內容是客戶端庫必須每種語言調用。分布式架構正變得越來越“多語言”（多語言）。在這樣的環境下，用許多不同的語言來重新實現一個非常復雜的網絡庫的成本會變得過高。最后，在大型服務體系結構中部署庫升級可能會非常痛苦，這使得很多不同版本的庫將在生產中同時運行，

綜上所述，上面提到的這些庫對于那些能夠限制編程語言擴散并克服庫升級難題的公司來說是成功的。

Sidecar代理

圖7：通過sidecar代理進行負載平衡

嵌入式客戶端庫負載平衡器拓撲的一個變種是圖7中所示的輔助代理拓撲。近年來，這種拓撲已經被普遍推廣為“服務網格”（Service Mesh）。Sidecar代理背后的思路是，以跳過一個不同的過程的代價來承擔輕微的延遲，嵌入式庫的所有好處都可以在沒有任何編程語言鎖定的情況下獲得。在撰寫本文時，最受歡迎的sidecar代理負載平衡器是Envoy，NGINX，HAProxy和Linkerd。

負載均衡器拓撲的總結和優缺點

• 中間代理拓撲是最簡單的負載平衡拓撲。缺點是：單點故障，伸縮瓶頸和黑箱操作。

• 邊緣代理拓撲與中間代理類似，但通常無法避免。

• 嵌入式客戶端庫拓撲提供了最好的性能和可擴展性，但是需要在每種語言中實現該庫，并跨所有服務升級庫。

• Sidecar代理拓撲性能比嵌入式客戶端庫拓撲弱，但不受任何限制。

總體而言，sidecar代理拓撲（服務網格）正在逐漸取代所有其他的服務。流量進入服務網格之前，始終需要邊緣代理拓撲。

4

L4負載均衡的現狀

L4負載均衡器 還有用嗎 ？

本文討論了L7負載平衡器如何用于現代協議，后面還會討論L7負載平衡器的特性。這是否意味著L4負載平衡器沒用了？沒有！盡管在我看來，L7負載均衡器最終將完全取代L4負載均衡器進行服務間通信，但是L4負載均衡器對邊緣通信仍然很重要。因為幾乎所有現代大型分布式架構都使用兩層L4 / L7負載平衡架構處理互聯網流量。在L7負載均衡器之前在邊緣部署中部署專用L4負載均衡器的好處是：

• L7負載均衡器執行的應用程序流量的分析，轉換和路由選擇要復雜得多，所以它們可以處理相對于經過優化的L4負載均衡器能夠處理的相對較小的原始流量負載（以每秒數據包和每秒字節數衡量）。這一現實通常使得L4負載平衡器成為處理某些類型的DoS攻擊（例如，SYN flood，通用包flood攻擊等）的更好位置。

• L7負載均衡器往往比L4負載平衡器更積極地開發，部署更頻繁，并且具有更多的缺陷。有一個L4負載均衡器，可以在L7負載平衡器部署期間執行健康檢查和排空，這比現代L4負載平衡器（通常使用BGP和ECMP）（以下更多）中使用的部署機制要容易得多。最后，因為L7負載平衡器功能的復雜性更容易出現錯誤，所以使用繞開故障和異常的L4負載平衡器產生更穩定的整體系統。

下面將介紹幾種不同的中間/邊緣代理L4負載均衡器的設計。這些設計不適用于客戶端庫和Sidecar拓撲。

TCP / UDP 終端 負載均衡器

圖8：L4終端負載均衡器

仍在使用的第一類L4負載均衡器是圖8所示的終端負載均衡器。這類負載均衡器，使用兩個離散的TCP連接：一個在客戶端和負載均衡器之間，另一個在負載均衡器和后端之間。

L4終端負載均衡器仍然有兩個原因：

1. 實現相對簡單。

2. 靠近客戶端的連接終端（低延遲）對性能有很大的影響。具體來說，如果終端負載均衡器可以放置在使用有損網絡（例如蜂窩）的客戶端附近，那么在將數據轉移到可靠的光纖傳輸到其最終位置之前，容易發生重傳。換句話說，這種負載平衡器適用于存在點（POP）場景下的原始TCP連接。

TCP / UDP直通負載均衡器

圖9：L4直通負載均衡器

第二種類型的L4負載均衡器是圖9所示的直通負載均衡器。在這種類型的負載均衡器中，TCP連接不會被負載均衡器終止。而是在連接跟蹤和網絡地址轉換（NAT）發生后，將每個連接的數據包轉發到選定的后端。首先，我們來定義一下連接跟蹤和NAT：

• 連接跟蹤：跟蹤所有活動的TCP連接狀態的過程。這包括握手是否完成，是否收到FIN，連接空閑多久，連接選擇了哪個后端等等。

• NAT：NAT是使用連接跟蹤數據在通過負載均衡器時更改數據包的IP /端口信息的過程。

使用連接跟蹤和NAT，負載平衡器可以將大部分原始TCP流量從客戶端傳遞到后端。例如，假設客戶正在交談，1.2.3.4:80而選定的后端位于10.0.0.2:9000。客戶端TCP數據包將到達負載均衡器at 1.2.3.4:80。然后負載均衡器將交換數據包的目標IP和端口10.0.0.2:9000。它還會將數據包的源IP與負載均衡器的IP地址進行交換。因此，當后端在TCP連接上響應時，數據包將返回到負載平衡器，在那里進行連接跟蹤并且NAT可以在反向再次發生。

為什么會使用這種負載均衡器來代替上一節中描述的終端負載均衡器呢？幾個原因：

• 性能和資源使用： 由于直通負載均衡器不是終止TCP連接，所以不需要緩沖任何TCP連接窗口。每個連接存儲的狀態量非常小，通常通過高效的散列表查找來訪問。因此，直通負載均衡器通常可以處理比終端負載均衡器大得多的活動連接數和數據包數（PPS）。

• 允許后端執行擁塞控制：TCP擁塞控制是因特網上的端點節制發送數據的機制，從而不會壓倒可用帶寬和緩沖區。由于直通負載均衡器不會終止TCP連接，因此不參與擁塞控制。這個事實允許后端根據他們的應用使用情況使用不同的擁塞控制算法。它還可以更容易地進行擁塞控制變更的實驗（例如，最近的BBR部署）。

• 形成直接服務器返回（DSR）和群集L4負載平衡的基準： 更高級的L4負載平衡技術（如DSR和使用分布式一致性散列的群集（以下各節中討論））需要直通負載平衡。

直接服務器返回（ Direct Server Return ， DSR ）

圖10：L4直接服務器返回（DSR）

直接服務器返回（DSR）負載平衡器如圖10所示。DSR構建在上一節中介紹的直通負載均衡器上。DSR是一種優化，只有入口/請求數據包才能通過負載均衡器。出口/響應數據包在負載平衡器周圍直接返回到客戶端。執行DSR很有趣的主要原因是，在許多工作負載中，響應流量對請求流量（例如，典型的HTTP請求/響應模式）產生了不滿。假設10％的流量是請求流量，90％的流量是響應流量，如果使用DSR的負載均衡器為1/10的容量可以滿足系統的需求。由于歷史上負載平衡器非常昂貴，因此這種優化可能會對系統成本和可靠性產生重大影響。DSR負載均衡器將直通負載均衡器的概念擴展如下：

• 負載平衡器通常仍然執行部分連接跟蹤。由于響應數據包不會遍歷負載均衡器，因此負載均衡器將不會意識到完整的TCP連接狀態。但是，負載均衡器可以通過查看客戶端數據包并使用各種類型的空閑超時來強烈推斷狀態。

• 負載均衡器通常使用通用路由封裝（GRE）來封裝從負載均衡器發送到后端的IP數據包，而不使用NAT 。因此，當后端收到封裝的數據包時，可以對其進行解封裝，并知道客戶端的原始IP地址和TCP端口。這允許后端直接響應客戶端，而無需響應數據包流經負載平衡器。

• DSR負載平衡器的一個重要組成部分是后端參與負載均衡。后端需要有一個正確配置的GRE隧道，根據網絡設置的低層細節，可能需要自己的連接跟蹤，NAT等。

請注意，在直通負載均衡器和DSR負載均衡器設計中，可以通過負載均衡器和后端來設置連接跟蹤，NAT，GRE等多種方式。

通過高可用性配對的容錯

圖11：通過HA對和連接跟蹤的L4容錯

到目前為止，我們一直在考慮L4負載平衡器的設計。直通和DSR負載平衡器都需要負載均衡器本身的一些連接跟蹤和狀態。如果負載平衡器死了怎么辦？如果負載平衡器的單個實例死亡，則所有通過負載平衡器的連接將被切斷。取決于應用程序，這可能會對應用程序性能產生重大影響。

歷史上，L4負載均衡器是從典型供應商（Cisco，Juniper，F5等）購買的硬件設備。這些設備非常昂貴，處理大量的流量。為了避免單個負載均衡器發生故障切斷所有連接，并導致大量應用程序中斷，負載均衡器通常部署在高可用性配對中，如圖11所示。典型的HA負載均衡器設置具有以下設計：

• 一對HA邊緣路由器為虛擬IP（VIP）提供服務。這些邊緣路由器使用邊界網關協議（BGP）宣布虛擬IP 。主邊緣路由器具有比備份更高的BGP權重，因此在穩定狀態下，它服務所有流量。（BGP是一個非常復雜的協議; 就本文而言，考慮BGP是網絡設備宣布可以從其他網絡設備獲取流量的機制，并且每個鏈路都可以具有優先考慮鏈路流量的權重）。

• 同樣，主L4負載均衡器向邊緣路由器宣布自己的BGP權重高于備份，因此在穩定狀態下，它將服務所有流量。

• 主負載均衡器交叉連接到備份，并共享其所有連接跟蹤狀態。因此，如果主負載宕機，備份可以接管處理所有活動的連接。

• 兩臺邊緣路由器和兩臺負載均衡器都是交叉連接的。這意味著如果其中一個邊緣路由器或負載平衡器中的一個死亡，或者由于某種其他原因撤消BGP通知，備份可以接管所有通信。

上面的設置是目前具有高流量的互聯網應用還在使用的方式。但是，上述方法有很大的缺點：

• 考慮到容量使用情況，虛擬 IP （VIP）必須在HA負載平衡器對之間正確分片。如果單個VIP超出單個HA對的容量，則需要將VIP分成多個VIP。

• 系統的資源使用情況很差。50％的容量在穩定狀態下閑置。鑒于歷史上硬件負載平衡器非常昂貴，這導致大量閑置資本。

• 現代分布式系統設計比主動/備份提供更高的容錯能力。例如，最佳地，系統應該能夠同時遭受多個故障并繼續運行。如果主動和備用負載均衡器同時死亡，則HA負載均衡器對可能會發生完全故障。

• 來自供應商的專有大型硬件設備非常昂貴，并導致供應商鎖定。通常希望用可商購計算服務器構建的可橫向擴展的軟件解決方案替代這些硬件設備。

通過具有分布式一致散列的集群進行容錯和擴展

圖12：L4容錯和通過集群負載平衡器和一致性哈希的擴展

上一節介紹了通過HA對的L4負載平衡器容錯以及該設計中固有的問題。從21世紀初到中期，大型互聯網基礎設施開始設計和部署新的大規模并行L4負載平衡系統，如圖12所示。這些系統的目標是：

• 減輕上一節中描述的HA對設計的所有缺點。

• 從供應商的專有硬件負載平衡器轉移到使用標準計算服務器和NIC構建的商品軟件解決方案。

這個L4負載均衡器設計最好稱為容錯和擴展，通過集群和分布式一致的散列。它的工作原理如下：

• N個邊緣路由器以相同的BGP權重宣布所有Anycast VIP。等價多路徑路由（ECMP）用于確保通常來自單個流的所有數據包到達相同的邊緣路由器。流程通常是源IP /端口和目標IP /端口的四元組。（簡而言之，ECMP是一種使用一致散列在一組相同加權的網絡鏈路上分發數據包的方法）。盡管邊緣路由器本身并不特別關心哪個分組到達哪里，但是通常優選的是，來自一個流的所有分組都經過相同的一組鏈路，以避免亂序分組，從而降低性能。

• N個L4負載均衡器機器以與邊緣路由器相同的BGP權重宣布所有的VIP。再次使用ECMP，邊緣路由器將通常為流選擇相同的負載平衡器機器。

• 每個L4負載均衡器機器通常會執行部分連接跟蹤，然后使用一致的哈希來為流選擇一個后端。GRE用于封裝從負載均衡器發送到后端的數據包。

• DSR然后被用來通過邊緣路由器直接從后端發送數據包到客戶端。

• L4負載均衡器使用的實際一致性散列算法是一個活躍的研究領域。主要圍繞均衡負載進行權衡，最小化延遲，最大限度地減少后端更改期間的中斷， 并最大限度地減少內存開銷。關于這個主題的完整討論超出了本文的范圍。

讓我們看看上面的設計是如何緩解HA對方法的所有缺點的：

• 新的邊緣路由器和負載平衡器機器可以根據需要添加。在添加新機器時，每層都使用一致的散列來盡可能減少受影響的流量。

• 系統的資源使用可以按照需要高速運行，同時保持足夠的突發容限和容錯。

• 邊緣路由器和負載平衡器現在都可以使用商用硬件來構建，而傳統硬件負載平衡器的成本只是其中的一小部分（下面會詳細介紹）。

• 通常被問及這個設計的一個問題是“為什么邊緣路由器不通過ECMP直接與后端對話？為什么我們需要負載平衡器？“其原因主要是減少DoS和后端操作的簡化。如果沒有負載平衡器，每個后端都必須參與BGP，并且執行滾動部署的時間將更加困難。

所有現代化的L4負載均衡系統都在朝著這種設計方向發展（或其他變體）。最著名的兩個例子是Google的Maglev和Amazon 的 網絡負載均衡器（NLB） 。目前還沒有實現這種設計的OSS負載平衡器，但是，我知道有一家公司計劃在2018年將其發布到OSS。我對這個版本感到非常興奮，因為現代L4負載平衡器是一個至關重要的部分在網絡空間中缺少OSS。

5

L7負載平衡的現有技術狀態

在過去的幾年中，L7負載平衡器/代理的發展已經復蘇。隨著分布式系統中的微服務架構的不斷推進，這方面也在不斷進步。從根本上說，固有故障的網絡在使用更頻繁時變得更加難以有效地運行。而且，自動擴展，容器調度等等的出現意味著在靜態文件中配置靜態IP的日子早已不復存在。系統不僅要利用網絡，還要變得更加動態，需要負載平衡器的新功能。本節將簡要概述在現代L7負載平衡器的最新發展。

協議支持

現代L7負載平衡器為許多不同的協議增加了明確的支持。負載平衡器對于應用程序流量的知識越多，關于可觀察性輸出，高級負載平衡和路由等方面可以做的更復雜的事情。例如，在撰寫本文時，Envoy明確支持L7協議解析和路由用于HTTP / 1，HTTP2，gRPC，Redis，MongoDB和DynamoDB。未來可能會有更多協議被添加，包括MySQL和Kafka。

動態配置

如上所述，分布式系統越來越具有動態性，需要并行投資來創建動態和反應式控制系統。Istio就是這樣一個例子。

高級負載平衡

L7負載均衡器現在通常內置對高級負載平衡功能的支持，如超時，重試，速率限制，斷路，屏蔽，緩沖，基于內容的路由等。

可觀察性

如上面有關一般負載平衡器功能的部分所述，正在部署的日益動態的系統越來越難以調試。強大的協議特定的可觀測性輸出是現代L7負載平衡器最重要的特性。任何L7負載平衡解決方案現在都需要輸出數字統計信息，分布式跟蹤和可自定義日志記錄。

可擴展性

現代L7負載平衡器的用戶通常希望輕松擴展以添加自定義功能。這可以通過寫入加載到負載均衡器的可插入過濾器來完成。許多負載平衡器也支持腳本，通常通過Lua。

容錯

L7負載均衡器的容錯性如何？一般來說，我們把L7負載平衡器視為可消耗和無狀態的。使用商業軟件就能夠對L7負載平衡器輕松水平擴展。此外，L7負載平衡器執行的處理和狀態跟蹤比L4復雜得多。試圖建立一個L7負載平衡器的HA配對在技術上是可能的，但非常繁雜。

總的來說，在L4和L7負載平衡領域，業界正在從HA配對轉向通過一致的哈希聚合橫向水平可擴展系統。

更多

L7負載平衡器正在以驚人的速度發展。有關Envoy提供的示例，請參閱Envoy的架構概述。

6

全球負載均衡和集中控制平面

圖13：全局負載平衡

負載平衡的未來將越來越多地將單個負載平衡器視為商品設備。我認為，真正的創新和商業機會都在控制層面。圖13顯示了一個全局負載均衡系統的例子。在這個例子中，幾個不同的事情正在發生：

• 每個Sidecar代理正在與三個不同區域（A，B和C）的后端進行通信。

• 如圖所示，90％的流量正被發送到區域C，而5％的流量正被發送到區域A和B。

• Sidecar代理和后端均向全局負載均衡器報告周期性狀態。這允許全局負載均衡器做出考慮延遲，成本，負載，當前故障等的決定。

• 全局負載均衡器使用當前路由信息周期性地配置每個邊車代理。

全球負載均衡器越來越能夠做復雜的事情。例如：

• 自動檢測并繞過區域故障。

• 應用全局安全和路由策略。

• 使用機器學習和神經網絡檢測和減輕流量異常，包括DDoS攻擊。

• 提供集中的用戶界面和可視化，使工程師能夠理解和操作整個分布式系統。

為了實現全局負載均衡，用作數據平面的負載平衡器必須具有復雜的動態配置能力。

7

從硬件到軟件的演變

本文只是簡單地提到了硬件和軟件，主要是在L4負載平衡器HA對的歷史背景下。這方面的業界趨勢又是怎樣呢？

• 歷史上的路由器和負載平衡器都是昂貴的專有硬件。

• 越來越多的專有L3 / L4網絡設備正在被商用服務器硬件，商用網卡和基于IPVS，DPDK和fd.io等框架的專業軟件解決方案取代。價格低于5K美元的現代數據中心機器可以使用Linux和自定義的基于DPDK的 user-space 應用，輕松飽和具有非常小數據包的80Gbps NIC。與此同時，廉價的路由器/交換機ASIC可以以驚人的總帶寬和數據包速率進行ECMP路由選擇，正在被打包成商品路由器。

• 像NGINX，HAProxy和Envoy這樣先進的L7軟件負載平衡器也在迅速地迭代和侵入之前像F5這樣的供應商領域。因此，L7負載平衡器也在積極地向商品軟件解決方案邁進。

與此同時，整個行業向主流云提供商推動的IaaS，CaaS和FaaS意味著越來越多的工程師需要了解物理網絡是如何工作的

8

結論和負載均衡的未來

這篇文章的主要內容是：

1. 負載平衡器是現代分布式系統中的關鍵組件。

2. 有兩種負載均衡器：L4和L7。

3. L4和L7負載平衡器都與現代架構中相關。

4. L4負載均衡器正朝著橫向可擴展的分布式一致哈希水平擴展解決方案邁進。

5. 由于動態微服務體系結構的激增，L7負載平衡器最近發展迅速。

6. 全局負載平衡和控制平面與數據平面之間的分離，是負載平衡的未來，存在大量商業機會。

7. 業界正在積極向商用OSS硬件和軟件提供網絡解決方案。相信像F5這樣的傳統負載均衡廠商將首先被OSS軟件和云供應商所取代。傳統的路由器/交換機廠商，如Arista / Cumulus /等。短期會有好的發展，但最終也將被公有云供應商和自研物理網絡所取代。

總的來說，現在是計算機網絡的一個激動人心的時代！大多數系統開始向OSS和軟件方向轉變，迭代速度加快。分布式系統向“無服務器”計算發展，必須繼續充滿活力，底層網絡和負載平衡系統的復雜性也將齊頭并進。

 

來自：http://mp.weixin.qq.com/s/LwmYMenIG77m8F_YaXqIAg