最近我注意到，關(guān)于當(dāng)代網(wǎng)絡(luò)負(fù)載均衡和代理的入門教材非常匱乏。我心想：為什么會這樣便脊？負(fù)載均衡是構(gòu)建可靠的分布式系統(tǒng)所需要的核心概念之一。應(yīng)當(dāng)可以獲取到一些有用的信息的吧光戈？我在網(wǎng)上搜了搜哪痰，卻沒有得到多少有用的信息。維基百科上關(guān)于負(fù)載均衡和代理服務(wù)器的文章包含了一些概念久妆，但是對于這個課題沒有一個完美的解答晌杰，更別提與現(xiàn)代微服務(wù)架構(gòu)的聯(lián)系了。Google上關(guān)于負(fù)載均衡的搜索結(jié)果主要是一些供應(yīng)商的網(wǎng)頁筷弦，顯示的主要是一些流行術(shù)語肋演，細(xì)節(jié)方面的內(nèi)容很少。

在本文中烂琴，我將嘗試改變這種信息匱乏的情況爹殊，詳細(xì)介紹現(xiàn)代網(wǎng)絡(luò)負(fù)載均衡和代理。坦率地講奸绷，這是一個非常大的話題梗夸，圍繞它寫一本書都不為過晾嘶。為了在一定程度上控制本篇文章的篇幅痒筒，我試著化繁為簡玩荠，對這一系列復(fù)雜的話題進(jìn)行了提煉朴爬；根據(jù)讀者的興趣和反饋，我會考慮在后續(xù)帖子中詳細(xì)介紹一些單獨(dú)的話題惰帽。

介紹了一點(diǎn)我寫作本文的背景之后，讓我們開始正文吧父虑！

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

維基百科將負(fù)載均衡定義為：

在計(jì)算機(jī)領(lǐng)域，負(fù)載均衡優(yōu)化了多個計(jì)算資源間的工作量分布士嚎。這些計(jì)算資源包括計(jì)算機(jī)呜魄、計(jì)算機(jī)集群、網(wǎng)絡(luò)連接莱衩、CPU或者硬盤等爵嗅。負(fù)載均衡的目的是優(yōu)化資源利用、最大化吞吐量笨蚁、最小化響應(yīng)時間睹晒，并且避免任何單個資源過載。通過冗余機(jī)制括细，使用多個負(fù)載均衡組件而不是單一組件可以增加可靠性和可用性伪很。負(fù)載均衡通常涉及專門的軟件或硬件，例如多層交換機(jī)或者域名系統(tǒng)服務(wù)器進(jìn)程奋单。

上述定義適用于所有計(jì)算機(jī)領(lǐng)域锉试，而不僅僅是網(wǎng)絡(luò)。操作系統(tǒng)使用負(fù)載均衡來調(diào)度物理處理器間的任務(wù)览濒，容器編排工具（例如Kubernetes）使用負(fù)載均衡來調(diào)度計(jì)算機(jī)集群內(nèi)的任務(wù)呆盖，網(wǎng)絡(luò)負(fù)載均衡器使用負(fù)載均衡來調(diào)度可用后端間的網(wǎng)絡(luò)任務(wù)。本文剩余部分將只涵蓋網(wǎng)絡(luò)負(fù)載均衡相關(guān)的內(nèi)容贷笛。

image

圖1高度概括了網(wǎng)絡(luò)負(fù)載均衡应又。一些客戶端從一些后端請求資源。負(fù)載均衡器位于客戶端和后端之間乏苦，執(zhí)行一些非常重要的任務(wù)：

• 服務(wù)發(fā)現(xiàn)：系統(tǒng)中有哪些后端可用丁频？它們的地址是什么？（例如邑贴，負(fù)載均衡器如何和它們通信席里？）
• 狀態(tài)檢查：哪些后端現(xiàn)在可以接受請求？
• 負(fù)載均衡：應(yīng)該使用什么算法來均衡后端間的請求拢驾？

在分布式系統(tǒng)中合理使用負(fù)載均衡可以帶來以下好處：

• 抽象命名：客戶端可以通過一個預(yù)定義的機(jī)制尋址到負(fù)載均衡器奖磁，然后將名稱解析委托給負(fù)載均衡器，而不是每一個客戶端都需要知道每一個后端的（有關(guān)服務(wù)發(fā)現(xiàn)的）信息繁疤。預(yù)定義機(jī)制包括內(nèi)置庫和眾所周知的DNS/IP/端口地址咖为，這些稍后都會詳細(xì)討論秕狰。
• 容錯性：通過狀態(tài)檢查和各種算法技術(shù)，負(fù)載均衡器可以有效繞開掛掉的或者過載的后端躁染。這意味著鸣哀，運(yùn)維人員通常可以在他們空閑時修復(fù)掛掉的后端而不是必須將這作為一個緊急事件來處理吞彤。
• 成本和性能方面的好處：分布式系統(tǒng)網(wǎng)絡(luò)復(fù)雜多變我衬。系統(tǒng)可能會包含多個網(wǎng)絡(luò)區(qū)域和行政區(qū)。在一個區(qū)域內(nèi)饰恕，網(wǎng)絡(luò)可能相對過載挠羔。而不同區(qū)域間，網(wǎng)絡(luò)通常又會有空余埋嵌。（這里破加，網(wǎng)絡(luò)過載或空余是指通過網(wǎng)卡消耗的帶寬數(shù)量占不同路由器間的可用帶寬的百分比）。智能負(fù)載均衡可以盡可能多地維持一個區(qū)域內(nèi)的請求數(shù)量雹嗦，這提高了性能（延遲降低）并且減少了整個系統(tǒng)的成本（不同區(qū)域間需要更少的寬帶和光纖）范舀。

負(fù)載均衡vs代理

談到網(wǎng)絡(luò)負(fù)載均衡器的時候，“負(fù)載均衡器”和“代理”這兩個術(shù)語通常在行業(yè)內(nèi)是差不多相同的意思了罪。本文通常也會將這兩個術(shù)語作為相同意思的詞尿背。（嚴(yán)格來說，并不是所有的代理都是負(fù)載均衡器捶惜，但是大部分代理將負(fù)載均衡作為首要功能）田藐。

有人也許會爭論說，當(dāng)用嵌入式客戶端庫來完成負(fù)載均衡時吱七，負(fù)載均衡器并不是一個代理汽久。然而，我認(rèn)為這個話題本來就十分容易令人混淆踊餐，而這種區(qū)分會為這個話題增加更多不必要的復(fù)雜性景醇。下面會詳細(xì)介紹負(fù)載均衡器的各種拓?fù)浣Y(jié)構(gòu)，但是本文仍將嵌入式負(fù)載均衡器拓?fù)浣Y(jié)構(gòu)作為一種特殊的代理吝岭；應(yīng)用程序通過嵌入式庫進(jìn)行代理三痰，這個庫提供了作為一個獨(dú)立于應(yīng)用進(jìn)程外的負(fù)載均衡器的所有相同的抽象。

L4（連接/session）負(fù)載均衡

現(xiàn)在討論行業(yè)內(nèi)的負(fù)載均衡方案時窜管，通常會歸結(jié)為兩類：L4和L7.這兩種分類指的是OSI模型的第4層和第7層散劫。當(dāng)我講到L7負(fù)載均衡的時候，會明顯發(fā)現(xiàn)我們使用這些術(shù)語來分類是錯誤的幕帆。OSI模型是負(fù)載均衡方案的復(fù)雜性的一種非常粗劣的抽象获搏，因?yàn)樨?fù)載均衡方案中雖然包含傳統(tǒng)的第4層協(xié)議，例如TCP和UDP失乾，但是通常最后還會或多或少包含一些其它OSI層級的協(xié)議常熙。例如纬乍，如果一個L4 TCP負(fù)載均衡器也支持TLS終端，那么它現(xiàn)在是不是一個L7負(fù)載均衡器呢裸卫？

image

圖2展示了一個傳統(tǒng)的L4 TCP負(fù)載均衡器仿贬。在這個例子中，客戶端與負(fù)載均衡器建立TCP連接墓贿。負(fù)載均衡器終止連接（例如茧泪，直接響應(yīng)SYN），選擇一個后端募壕，與這個后端建立一個新的TCP連接（例如调炬，發(fā)送一個新的SYN）语盈。示意圖中的細(xì)節(jié)并不重要舱馅，會在后面關(guān)于L4負(fù)載均衡的章節(jié)詳細(xì)討論。

本章節(jié)的要點(diǎn)是刀荒，L4負(fù)載均衡器通常只操作L4層的TCP/UDP連接或session代嗤。因此，負(fù)載均衡器只是來回地搬運(yùn)bytes缠借，并確保來自同一個session的bytes發(fā)送到相同的后端干毅。L4負(fù)載均衡器不清楚這些搬運(yùn)的bytes組成的應(yīng)用的任何細(xì)節(jié)。這些bytes可以是HTTP泼返、Redis硝逢、MongoDB或者其他任何應(yīng)用層協(xié)議。

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

L4負(fù)載均衡很簡單并且仍被廣泛使用绅喉。L4負(fù)載均衡的哪些不足導(dǎo)致需要使用L7（應(yīng)用層）負(fù)載均衡渠鸽？可以參考下列L4具體例子：

• 兩個gRPC/HTTP2客戶端通過一個L4負(fù)載均衡器來和后端通信。
• L4負(fù)載均衡器針對每個收到的TCP連接都會建立一個單獨(dú)外出的TCP連接柴罐，導(dǎo)致會有2個收到的連接和2個外出的連接徽缚。
• 然而，客戶端A通過它建立的連接每分鐘發(fā)送1個請求（1 RPM）革屠，而客戶端B通過它建立的連接每秒發(fā)送50個請求（50 RPS）凿试。

在上述情景中，處理客戶端A請求的后端比處理客戶端B請求的后端處理的請求少了大約3000倍似芝！這是一個非常重大的問題那婉，也是違背負(fù)載均衡目標(biāo)的首要問題。另外要注意到党瓮，這個問題在任何多路復(fù)用的長連接的協(xié)議中都會發(fā)生吧恃。（多路復(fù)用的意思是，通過單個L4連接并行發(fā)送應(yīng)用請求麻诀。長連接的意思是痕寓，即使沒有活躍請求也不關(guān)閉連接傲醉。）所有現(xiàn)代網(wǎng)絡(luò)協(xié)議為了效率都會采用多路復(fù)用和長連接（通常建立連接的成本非常大，特別是連接使用TLS加密的時候）呻率，因此硬毕，隨著時間的推移，L4負(fù)載均衡器調(diào)節(jié)負(fù)載失敗的現(xiàn)象變得越來越明顯礼仗。這個問題可以被L7負(fù)載均衡器修復(fù)吐咳。

image

圖3展示了一個L7 HTTP/2負(fù)載均衡器。在這個例子中元践，客戶端與負(fù)載均衡器建立了單個HTTP/2 TCP連接韭脊。負(fù)載均衡器然后建立了兩個后端連接。當(dāng)客戶端向負(fù)載均衡器發(fā)送了兩個HTTP/2信息流時单旁，信息流1被送到后端1沪羔，而信息流2被送到后端2。因此象浑，即使多路復(fù)用的客戶端會發(fā)送各種不同的請求蔫饰，后端的負(fù)載也會被很高效地均衡分配。這就是為什么L7負(fù)載均衡對于現(xiàn)代網(wǎng)絡(luò)協(xié)議是這么的重要愉豺。（L7負(fù)載均衡能夠監(jiān)測應(yīng)用流量篓吁，由此產(chǎn)生了非常多額外的好處，這些會在后面講到）蚪拦。

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

正如我在上面關(guān)于L4負(fù)載均衡的章節(jié)講到的杖剪，使用OSI模型來描述負(fù)載均衡的特性是有問題的。至少如OSI模型描述的那樣驰贷，L7自身就包含了其它層的負(fù)載均衡盛嘿。例如，對于HTTP流量需要考慮以下子層：

• 可選的傳輸層安全（Transport Layer Security饱苟，TLS）孩擂。網(wǎng)絡(luò)領(lǐng)域人士對于TLS歸屬于OSI模型哪一層存在爭議。在本文的討論中箱熬，我們認(rèn)為TLS屬于L7类垦。
• HTTP物理層協(xié)議（HTTP/1或HTTP/2）。
• HTTP邏輯層協(xié)議（協(xié)議頭城须、數(shù)據(jù)體蚤认、協(xié)議尾）。
• 通信協(xié)議（gRPC糕伐、REST等等）砰琢。

一個復(fù)雜的L7負(fù)載均衡器會提供與上述每一個子層相關(guān)的功能。而另外一個L7負(fù)載均衡器可能只會包含L7范疇內(nèi)的一小部分功能∨闫總之训唱，從功能比較的視角來看，L7負(fù)載均衡器比L4復(fù)雜得多挚冤。（當(dāng)然况增，本章節(jié)只涉及了HTTP；Redis训挡、Kafka澳骤、MongoDB等都是受益于L7負(fù)載均衡的L7應(yīng)用層協(xié)議）。

負(fù)載均衡器的功能

本節(jié)中澜薄，我將簡要總結(jié)負(fù)載均衡器提供的高級功能为肮。不是所有的負(fù)載均衡器都提供所有這些功能。

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

服務(wù)發(fā)現(xiàn)是負(fù)載均衡器判斷可用后端集合的過程肤京。服務(wù)發(fā)現(xiàn)的方法各不相同颊艳，包括以下一些例子：

• 靜態(tài)配置文件。
• NDS蟆沫。
• Zookeeper籽暇、Etcd温治、Consul等饭庞。
• Envoy的統(tǒng)一數(shù)據(jù)層API。

健康檢查

健康檢查是負(fù)載均衡器判斷后端是否服務(wù)可用的過程熬荆。健康檢查通常分為兩類：

• 主動的：負(fù)載均衡器以固定時間間隔向后端發(fā)送ping請求（例如舟山，每個健康檢查的端點(diǎn)發(fā)送一個HTTP請求），并以此來判斷健康狀態(tài)卤恳。
• 被動的：負(fù)載均衡器從主要的數(shù)據(jù)流中檢測健康狀態(tài)累盗。例如，如果在一段時間內(nèi)有三次連接錯誤突琳，L4負(fù)載均衡器可能會認(rèn)為這個后端是不健康的若债。如果在一段時間內(nèi)有三次HTTP 503響應(yīng)代碼，L7負(fù)載均衡器可能會認(rèn)為該后端是不健康的拆融。

負(fù)載均衡

是的蠢琳，負(fù)載均衡器要真的能夠均衡負(fù)載！如果有一堆狀態(tài)良好的后端镜豹，如何選中一個后端來服務(wù)一個連接或請求傲须？負(fù)載均衡算法是一個熱門的研究領(lǐng)域，從比較簡化的算法趟脂，例如隨機(jī)選擇法和循環(huán)淘汰法泰讽，到復(fù)雜一些的考慮到延遲和后端負(fù)載變化的算法。最流行的負(fù)載均衡算法之一是power of 2 request load balancing，具有良好的性能和較低的復(fù)雜度已卸。（這種算法的機(jī)制是：當(dāng)請求到達(dá)負(fù)載均衡器時佛玄，負(fù)載均衡器會先從系統(tǒng)中隨機(jī)選擇2個后端，然后從這2個后端中選擇負(fù)載最小的那個來響應(yīng)請求累澡。）

粘性session

在特定應(yīng)用中翎嫡，同一個session的請求到達(dá)同一個后端是非常重要的。這可能與緩存永乌、臨時創(chuàng)建的復(fù)雜狀態(tài)等有關(guān)惑申。session的定義很多，可能包括HTTP cookies翅雏、客戶端連接屬性或者其它一些屬性圈驼。許多L7負(fù)載均衡器支持粘性session。另外望几，我要提醒你注意的是绩脆，session的粘性本質(zhì)上是脆弱的（后端持有的session可能會消亡），因此建議在設(shè)計(jì)依賴粘性session的系統(tǒng)時保持謹(jǐn)慎橄抹。

TLS終端

關(guān)于TLS和它在服務(wù)和保障服務(wù)間通信中的角色的話題值得深入探討靴迫。許多L7負(fù)載均衡器承擔(dān)了許多TLS處理流程，包括終止請求楼誓、證書驗(yàn)證和綁定玉锌、使用SNI的證書服務(wù)等。

觀測性

正如我常說的：“觀測性疟羹、觀測性主守、觀測性￠冢”網(wǎng)絡(luò)本質(zhì)上是不可靠的参淫，負(fù)載均衡器通常有責(zé)任導(dǎo)出統(tǒng)計(jì)數(shù)據(jù)、跟蹤數(shù)據(jù)和日志愧杯，這些信息可以幫助運(yùn)維人員發(fā)現(xiàn)問題從而修復(fù)這些問題涎才。負(fù)載均衡器在可觀測性輸出結(jié)果上有很大不同。最高級的負(fù)載均衡器提供豐富的輸出結(jié)果力九，包括數(shù)值統(tǒng)計(jì)耍铜、分布式跟蹤信息和自定義日志。我要指出的是畏邢，為了增強(qiáng)功能而增加的觀測性不是沒有代價的业扒；負(fù)載均衡器不得不做一些額外的工作來產(chǎn)出觀測結(jié)果。然而舒萎，這些數(shù)據(jù)帶來的好處遠(yuǎn)遠(yuǎn)超過了相對較小的性能影響程储。

安全性和DoS防御

特別是在邊緣部署拓?fù)浣Y(jié)構(gòu)中（見下文）蹭沛，負(fù)載均衡器通常實(shí)現(xiàn)各種安全功能，包括速率限制章鲤、認(rèn)證和DoS防御（例如摊灭，IP地址標(biāo)記、識別败徊、過濾等）帚呼。

配置控制層

負(fù)載均衡需要進(jìn)行配置。這對于大型部署來說皱蹦，是一種非常重要的保證煤杀。通常，配置負(fù)載均衡器的系統(tǒng)被稱為“控制層”沪哺，而且它有各種各樣的實(shí)現(xiàn)沈自。關(guān)于這個話題的更多信息，請查看我的關(guān)于《service mesh data plane vs. control plane》的博客辜妓。

更多內(nèi)容

本節(jié)初步涉獵了負(fù)載均衡器提供的各種功能枯途。其它的討論可以查看下文中關(guān)于L7負(fù)載均衡器的章節(jié)。

負(fù)載均衡器拓?fù)浣Y(jié)構(gòu)類型

既然我已經(jīng)高度概括了什么是負(fù)載均衡器籍滴、L4和L7負(fù)載均衡器的區(qū)別以及負(fù)載均衡器的功能總結(jié)酪夷，下面我將繼續(xù)介紹部署了負(fù)載均衡器的各種分布式系統(tǒng)的拓?fù)浣Y(jié)構(gòu)。（下面的每種拓?fù)浣Y(jié)構(gòu)都適用于L4和L7負(fù)載均衡器孽惰。）

中間代理

image

圖4所示的中間代理拓?fù)浣Y(jié)構(gòu)對于大部分讀者來說可能是最熟悉的使用負(fù)載均衡的方式晚岭。這類負(fù)載均衡包括Cisco、Juniper灰瞻、F5出產(chǎn)的硬件設(shè)備腥例；云端軟件解決方案辅甥，例如Amazon的ALB和NLB以及Google的云端負(fù)載均衡器（Cloud Load Balancer）酝润；自托管的純軟件解決方案，例如HAProxy璃弄、NGINX和Envoy要销。中間代理解決方案的優(yōu)點(diǎn)是簡單易用。通常夏块，用戶通過DNS連接到負(fù)載均衡器疏咐，然后就不需要再關(guān)心其它任何事情了。中間代理解決方案的缺點(diǎn)是脐供，代理（即使使用集群）是一個故障單點(diǎn)浑塞，同時也是一個擴(kuò)展瓶頸。中間代理通常也是一個黑盒子政己，運(yùn)維人員難以維護(hù)酌壕。如果發(fā)生了故障，那么這是一個在客戶端能夠觀察到的問題嗎？是發(fā)生在物理網(wǎng)絡(luò)嗎卵牍？還是發(fā)生在中間代理果港？或者是發(fā)生在后端？這很難說的清楚糊昙。

邊緣代理

image

圖5所示的邊緣代理拓?fù)浣Y(jié)構(gòu)只是中間代理拓?fù)浣Y(jié)構(gòu)的一個變種辛掠，其中負(fù)載均衡器通過Internet訪問。在這個場景中释牺，負(fù)載均衡器通常必須提供額外的“API網(wǎng)關(guān)”功能萝衩，例如TLS終端、速率限制没咙、身份認(rèn)證和復(fù)雜的流量路由欠气。邊緣代理的優(yōu)點(diǎn)和缺點(diǎn)與中間代理一樣。需要注意的是镜撩，通常在大型的面向互聯(lián)網(wǎng)的分布式系統(tǒng)中部署專用的邊緣代理是不可避免的预柒。客戶端通常會使用任意網(wǎng)絡(luò)庫經(jīng)過DNS訪問系統(tǒng)袁梗，但這些網(wǎng)絡(luò)庫不受客戶端的控制（這使得嵌入式客戶端庫負(fù)載均衡器或下面章節(jié)會提到的sidecar代理拓?fù)浣Y(jié)構(gòu)負(fù)載均衡器直接在客戶端上運(yùn)行變得不切實(shí)際）宜鸯。另外，為了安全原因設(shè)置一個單獨(dú)的安全網(wǎng)關(guān)是值得的遮怜，所有面向互聯(lián)網(wǎng)的流量都必須先經(jīng)過這個安全網(wǎng)關(guān)才能進(jìn)入系統(tǒng)淋袖。

嵌入式的客戶端庫

image

為了避免中間代理拓?fù)浣Y(jié)構(gòu)天生的單點(diǎn)故障和擴(kuò)展問題，更復(fù)雜的基礎(chǔ)設(shè)施朝著將負(fù)載均衡器通過一個庫直接嵌入到服務(wù)中的方向發(fā)展锯梁，正如圖6所示的那樣即碗。這些庫支持的功能各種各樣，其中最知名的功能豐富的庫有Finagle陌凳、Eureka/Ribbon/Hystrix和gRPC（基于一個Google內(nèi)部稱作Stubby的系統(tǒng)）剥懒。基于庫的解決方案的主要優(yōu)點(diǎn)是合敦，它完全將負(fù)載均衡器的所有功能分布到每一個客戶端初橘，因此消除了前面提到的單點(diǎn)故障和擴(kuò)展問題〕涞海基于庫的解決方案的主要缺點(diǎn)是所用的庫必須用一個機(jī)構(gòu)使用的每一種語言實(shí)現(xiàn)保檐。分布式架構(gòu)變得越來越“通曉各種語言”（使用多種語言編寫的）。在這種環(huán)境下崔梗，用多種不同的語言重新實(shí)現(xiàn)一個非常復(fù)雜的網(wǎng)絡(luò)庫的代價會非常大夜只。最后，跨一個大型服務(wù)架構(gòu)來升級庫會非常痛苦蒜魄，很可能會造成許多不同版本的庫同時在生產(chǎn)環(huán)境中運(yùn)行扔亥，從而增加運(yùn)維時了解網(wǎng)絡(luò)情況的負(fù)擔(dān)爪膊。

盡管如此，對于那些能夠限制使用的編程語言的種類并且克服升級庫的痛苦的公司來說砸王，上面提到的各種庫還是非常成功的推盛。

Sidecar代理

image

圖7所示的sidecar代理拓?fù)浣Y(jié)構(gòu)是客戶端嵌入式庫負(fù)載均衡拓?fù)浣Y(jié)構(gòu)的一個變種。最近幾年谦铃，這種拓?fù)浣Y(jié)構(gòu)被稱作“服務(wù)網(wǎng)格”并且非常流行耘成。sidecar代理背后的思路是，以切換到另外一個進(jìn)程造成輕微延遲的代價驹闰，獲得嵌入式庫方案的所有好處瘪菌，而且無需局限于任何編程語言。截至本文嘹朗，最流行的sidecar代理負(fù)載均衡器有Envoy师妙、NGINX、HAProxy和Linkerd屹培。如果想要更詳細(xì)地了解sidecar代理方案的優(yōu)化方法默穴，請查看我博客中介紹Envoy的帖子和關(guān)于《service mesh data plane vs. control plane》（服務(wù)網(wǎng)格數(shù)據(jù)層vs控制層）的帖子。

各種負(fù)載均衡器拓?fù)浣Y(jié)構(gòu)的優(yōu)缺點(diǎn)

• 中間代理拓?fù)浣Y(jié)構(gòu)是最容易使用的負(fù)載均衡拓?fù)浣Y(jié)構(gòu)褪秀。它的弊端是單點(diǎn)故障蓄诽、擴(kuò)展限制和黑箱操作端。
• 邊緣代理拓?fù)浣Y(jié)構(gòu)和中間代理類似媒吗，但通常還免不了會用到仑氛。
• 嵌入式客戶端庫拓?fù)浣Y(jié)構(gòu)提供了最好的性能和可擴(kuò)展性，但是需要用各種語言來實(shí)現(xiàn)這個庫而且需要跨所有服務(wù)來升級這個庫闸英。
• sidecar代理拓?fù)浣Y(jié)構(gòu)執(zhí)行性能雖然不如嵌入式客戶端庫拓?fù)浣Y(jié)構(gòu)锯岖，但是不會受到其中的任何限制。

總之甫何，我認(rèn)為sidecar代理拓?fù)浣Y(jié)構(gòu)（服務(wù)網(wǎng)格）正逐漸取代所有其它用來進(jìn)行服務(wù)間通信的拓?fù)浣Y(jié)構(gòu)出吹。在流量進(jìn)入服務(wù)網(wǎng)格之前需要使用邊緣代理拓?fù)浣Y(jié)構(gòu)

查看英文原文：Introduction to modern network load balancing and proxying