本文翻譯自由 David Vroom, James Mulcahy, Ling Yuan, Rob Gulewich 編寫(xiě)的 Netflix 博客 Zero Configuration Service Mesh with On-Demand Cluster Discovery[1]。

Netflix 相信大家并不陌生，在 Spring Cloud 生態(tài)中就有 Netflix 全家桶。多年前，我也曾將基于 Netflix OSS 構(gòu)建的微服務(wù)架構(gòu)搬上了 Kubernetes 平臺(tái)，并持續(xù)折騰好幾年。

Spring Cloud Netflix 有著龐大的用戶(hù)群以及用戶(hù)場(chǎng)景，其提供了微服務(wù)治理的一整套解決方案：服務(wù)發(fā)現(xiàn) Eureka、客戶(hù)端負(fù)載均衡 Ribbon、斷路器 Hystrix、微服務(wù)網(wǎng)格 Zuul。

有過(guò)相同經(jīng)歷的小伙伴應(yīng)該都會(huì)同感，這樣一套微服務(wù)解決方案的架構(gòu)，經(jīng)過(guò)多年的演進(jìn)也會(huì)讓人痛苦不堪：復(fù)雜度越來(lái)越高、版本碎片化嚴(yán)重、多語(yǔ)言多框架的支持和功能無(wú)法統(tǒng)一等等。這也是 Netflix 自己也不得不面對(duì)的問(wèn)題，隨后他們將目光轉(zhuǎn)向了服務(wù)網(wǎng)格，并尋求一個(gè)無(wú)縫遷移的方案。

這篇文章中，他們給出了答案：Netflix 與社區(qū)合作，并自建控制平面與已有的服務(wù)發(fā)現(xiàn)體系兼容。這套實(shí)現(xiàn)下來(lái)可能并不容易，也未看到他們要將其開(kāi)源的想法，但是至少可以給大家一個(gè)參考。

順便預(yù)告一下自己正在計(jì)劃的一篇，如何將微服務(wù)平滑遷移到 Flomesh 服務(wù)網(wǎng)格平臺(tái)。不止無(wú)縫兼容 Eureka，還有 HashiCorp Consul，未來(lái)還會(huì)兼容更多的服務(wù)發(fā)現(xiàn)方案。

以下是原文的翻譯：

在這篇文章中，我們將討論 Netflix 服務(wù)網(wǎng)格（Service Mesh）實(shí)踐的相關(guān)信息：歷史背景、動(dòng)機(jī)，以及我們?nèi)绾闻c Kinvolk 和 Envoy 社區(qū)合作，在復(fù)雜的微服務(wù)環(huán)境中推動(dòng)服務(wù)網(wǎng)格落地的一個(gè)特征：按需集群發(fā)現(xiàn)（On-demand Cluster Discovery）。

Netflix 的 IPC 簡(jiǎn)史

Netflix 是早期云計(jì)算的采納者，特別是對(duì)于大規(guī)模的公司：我們?cè)?2008 年開(kāi)始了遷移，并且到 2010 年，Netflix的流媒體完全運(yùn)行在AWS上[2]。今天我們擁有豐富的工具，包括開(kāi)源和商業(yè)的，所有這些都是為云原生環(huán)境設(shè)計(jì)的。然而，在 2010 年，幾乎沒(méi)有這樣的工具存在：CNCF[3] 直到 2015 年才成立！由于沒(méi)有現(xiàn)成的解決方案，我們需要自己構(gòu)建它們。

對(duì)于服務(wù)間的進(jìn)程間通信（IPC），我們需要一個(gè)中間層負(fù)載均衡器通常提供的豐富功能集。我們還需要一種解決方案，來(lái)應(yīng)對(duì)云環(huán)境的現(xiàn)實(shí)：一個(gè)高度動(dòng)態(tài)的環(huán)境，其中節(jié)點(diǎn)不斷上線和下線，服務(wù)需要快速響應(yīng)變化并隔離失敗。為了提高可用性，我們?cè)O(shè)計(jì)了可以單獨(dú)發(fā)生故障的系統(tǒng)組件，以避免單點(diǎn)故障。這些設(shè)計(jì)原則引導(dǎo)我們走向了客戶(hù)端負(fù)載均衡，而 2012年圣誕節(jié)的宕機(jī)[4] 進(jìn)一步堅(jiān)定了這個(gè)決策。在云早期，我們構(gòu)建了Eureka[5] 用于服務(wù)發(fā)現(xiàn)，以及 Ribbon（內(nèi)部名為NIWS）用于IPC[6]。Eureka 解決了服務(wù)如何發(fā)現(xiàn)與其通信的實(shí)例的問(wèn)題，而 Ribbon 提供了負(fù)載均衡的客戶(hù)端，以及許多其他的彈性特性。這兩項(xiàng)技術(shù)，加上一系列其他的彈性和混沌工具，產(chǎn)生了巨大的收益：我們的可靠性因此得到了顯著的改善。

Eureka 和 Ribbon 提供了一個(gè)簡(jiǎn)單而強(qiáng)大的接口，讓它們的使用變得容易。一個(gè)服務(wù)與另一個(gè)服務(wù)通信，需要知道兩件事：目的服務(wù)的名稱(chēng)，以及流量是否應(yīng)該是安全的。Eureka 為此提供的抽象是虛擬 IP（VIPs）用于非安全通信，和安全 VIPs（SVIPs）用于安全通信。服務(wù)向 Eureka 宣布一個(gè) VIP 名和端口（例如：_myservice_，端口 _8080_），或一個(gè) SVIP 名和端口（例如：_myservice-secure_，端口 8443），或同時(shí)使用兩者。IPC 客戶(hù)端針對(duì)該 VIP 或 SVIP 進(jìn)行實(shí)例化，而 Eureka 客戶(hù)端代碼通過(guò)從 Eureka 服務(wù)器獲取它們來(lái)處理該 VIP 到一組 IP 和端口對(duì)的轉(zhuǎn)換。客戶(hù)端還可以選擇啟用像重試或熔斷這樣的 IPC 功能，或者使用一組合理的默認(rèn)值。

圖片

在這種架構(gòu)中，服務(wù)間通信不再通過(guò)負(fù)載均衡器的單點(diǎn)故障通道。但問(wèn)題是，Eureka 現(xiàn)在成為了 VIP 注冊(cè)主機(jī)真實(shí)性的新的單一故障點(diǎn)。然而，如果 Eureka 宕機(jī)，服務(wù)仍然可以互相通信，盡管它們的主機(jī)信息隨著 VIP 的上下線而逐漸過(guò)時(shí)。在故障期間以降級(jí)但可用的狀態(tài)運(yùn)行仍然是相比完全停止流量的明顯改進(jìn)。

在這種架構(gòu)中，服務(wù)與服務(wù)間的通信不再經(jīng)過(guò)負(fù)載均衡器的單一故障點(diǎn)。但問(wèn)題是，Eureka 現(xiàn)在成為了 VIP 注冊(cè)主機(jī)真實(shí)性的新的單一故障點(diǎn)。然而，如果 Eureka 宕機(jī)，服務(wù)仍然可以互相通信，盡管它們的主機(jī)信息隨著 VIP 的上下線而逐漸過(guò)時(shí)。在故障期間以降級(jí)但可用的狀態(tài)運(yùn)行仍然是相比完全停止流量的明顯改進(jìn)。

為什么選擇網(wǎng)格？

上述架構(gòu)在過(guò)去的十年里為我們服務(wù)得很好，但隨著業(yè)務(wù)需求的變化和行業(yè)標(biāo)準(zhǔn)的演變，我們的 IPC 生態(tài)系統(tǒng)在很多方面都增加了更多的復(fù)雜性。首先，我們?cè)黾恿瞬煌?IPC 客戶(hù)端的數(shù)量。我們的內(nèi)部 IPC 流量現(xiàn)在是純 REST、GraphQL[7] 和 gRPC[8] 的混合。其次，我們從只使用 Java 環(huán)境遷移到了多語(yǔ)言環(huán)境：我們現(xiàn)在也支持 node.js[9]、Python[10] 以及各種開(kāi)源和現(xiàn)成的軟件。第三，我們繼續(xù)為 IPC 客戶(hù)端增加更多功能，如 自適應(yīng)并發(fā)限制[11]、斷路器[12]、對(duì)沖和故障注入已成為我們工程師為使系統(tǒng)更可靠而采用的標(biāo)準(zhǔn)工具。與十年前相比，我們現(xiàn)在支持更多功能、更多語(yǔ)言、更多客戶(hù)端。確保所有這些實(shí)現(xiàn)之間的功能一致性并確保它們都以相同的方式運(yùn)行是具有挑戰(zhàn)性的：我們希望這些功能有一個(gè)單一、經(jīng)過(guò)充分測(cè)試的實(shí)現(xiàn)，這樣我們可以在一個(gè)地方進(jìn)行更改和修復(fù)錯(cuò)誤。

這就是服務(wù)網(wǎng)格的價(jià)值所在：我們可以在一個(gè)實(shí)現(xiàn)中集中 IPC 功能，并使每種語(yǔ)言的客戶(hù)端盡可能簡(jiǎn)單：它們只需要知道如何與本地代理通話。Envoy[13] 對(duì)我們來(lái)說(shuō)是代理的絕佳選擇：它是一個(gè)經(jīng)過(guò)戰(zhàn)斗考驗(yàn)的開(kāi)源產(chǎn)品，已經(jīng)在行業(yè)中被廣泛使用，擁有 許多關(guān)鍵的彈性功能[14]，以及當(dāng)我們需要擴(kuò)展其功能時(shí)的 良好的擴(kuò)展點(diǎn)[15]。能夠 通過(guò)一個(gè)集中的控制平面配置代理[16] 是一個(gè)殺手級(jí)的功能：這使我們可以動(dòng)態(tài)配置客戶(hù)端負(fù)載均衡，就像它是一個(gè)集中的負(fù)載均衡器，但仍然避免了服務(wù)到服務(wù)請(qǐng)求路徑中的負(fù)載均衡器作為單一的故障點(diǎn)。

為什么選擇網(wǎng)格？

過(guò)去十年，上述架構(gòu)已經(jīng)為我們提供了良好的服務(wù)，盡管不斷變化的業(yè)務(wù)需求和行業(yè)標(biāo)準(zhǔn)的演進(jìn)使我們的 IPC 生態(tài)系統(tǒng)變得更為復(fù)雜。首先，我們?cè)黾恿瞬煌?IPC 客戶(hù)端的數(shù)量。目前，我們的內(nèi)部 IPC 流量包含了簡(jiǎn)單的 REST，GraphQL[17]，和 gRPC[18]。其次，我們從僅 Java 環(huán)境轉(zhuǎn)變?yōu)槎嗾Z(yǔ)言環(huán)境：現(xiàn)在我們還支持 node.js[19]，Python[20]，以及各種開(kāi)源和現(xiàn)成的軟件。第三，我們繼續(xù)為 IPC 客戶(hù)端增加更多功能：諸如 自適應(yīng)并發(fā)限制[21]、熔斷[22]、hedging 和故障注入等功能已成為我們的工程師用來(lái)提高系統(tǒng)可靠性的標(biāo)準(zhǔn)工具。與十年前相比，我們現(xiàn)在在更多的語(yǔ)言、更多的客戶(hù)端中支持更多的功能。保持所有這些實(shí)現(xiàn)之間的功能一致性，確保它們的行為保持一致是具有挑戰(zhàn)性的：我們想要的是所有這些功能的單一、經(jīng)過(guò)良好測(cè)試的實(shí)現(xiàn)，以便我們能在一個(gè)地方進(jìn)行變更和修復(fù)錯(cuò)誤。

這就是服務(wù)網(wǎng)格的作用所在：我們可以將 IPC 功能集中在單一的實(shí)現(xiàn)中，并盡可能簡(jiǎn)化每種語(yǔ)言的客戶(hù)端：它們只需要知道如何與本地代理通信。Envoy[23] 作為代理對(duì)我們來(lái)說(shuō)非常合適：它是一個(gè)經(jīng)過(guò)實(shí)戰(zhàn)測(cè)試的開(kāi)源產(chǎn)品，在行業(yè)中應(yīng)用于高規(guī)模場(chǎng)景，擁有 許多關(guān)鍵的彈性功能[24]，以及 良好的擴(kuò)展點(diǎn)[25]，以便我們需要時(shí)能擴(kuò)展其功能。通過(guò) 中央控制平面配置代理的能力[26] 是一個(gè)殺手級(jí)的功能：這允許我們動(dòng)態(tài)配置客戶(hù)端負(fù)載均衡，就像它是中央負(fù)載均衡器一樣，但仍然避免了負(fù)載均衡器成為服務(wù)到服務(wù)請(qǐng)求路徑中的單點(diǎn)故障。

轉(zhuǎn)向服務(wù)網(wǎng)格

一旦認(rèn)定我們決定轉(zhuǎn)向服務(wù)網(wǎng)格是正確的選擇，下一個(gè)問(wèn)題便是：我們應(yīng)如何進(jìn)行遷移？我們確定了一些遷移的限制條件。首先：我們希望保留現(xiàn)有的接口。通過(guò)指定 VIP 名稱(chēng)加上安全服務(wù)的抽象為我們提供了良好服務(wù)，我們不想破壞向后兼容性。其次：我們希望自動(dòng)化遷移，并使其盡可能無(wú)縫。這兩個(gè)限制意味著我們需要支持 Envoy 中的 Discovery 抽象，以便 IPC 客戶(hù)端可以繼續(xù)在底層使用它。幸運(yùn)的是，Envoy 已經(jīng)有了 現(xiàn)成的抽象[27] 可以用。VIP 可以表示為 Envoy 集群，代理可以從我們的控制平面使用集群發(fā)現(xiàn)服務(wù) (CDS) 獲取它們。這些集群中的主機(jī)表示為 Envoy 端點(diǎn)，可以使用端點(diǎn)發(fā)現(xiàn)服務(wù) (EDS) 獲取。

我們很快遇到了一個(gè)無(wú)縫遷移的障礙：Envoy 要求在代理的配置中指定集群。如果服務(wù) A 需要與集群 B 和 C 通信，那么需要在 A 的代理配置中定義集群 B 和 C。這在規(guī)模上可能具有挑戰(zhàn)性：任何給定的服務(wù)可能會(huì)與數(shù)十個(gè)集群通信，而每個(gè)應(yīng)用程序的集群集合都是不同的。此外，Netflix 始終在變化：我們不斷推出新的項(xiàng)目，如直播、廣告[28] 和游戲，并且不斷發(fā)展我們的架構(gòu)。這意味著服務(wù)通信的集群會(huì)隨著時(shí)間的推移而改變。鑒于我們可用的 Envoy 原語(yǔ)，我們?cè)u(píng)估了一些填充集群配置的不同方法：

1. 讓服務(wù)所有者定義他們的服務(wù)需要與之通信的集群。這個(gè)選項(xiàng)看似簡(jiǎn)單，但實(shí)際上，服務(wù)所有者并不總是知道，或想要知道，他們與哪些服務(wù)通信。服務(wù)通常會(huì)導(dǎo)入由其他團(tuán)隊(duì)提供的庫(kù)，這些庫(kù)在底層與多個(gè)其他服務(wù)通信，或與像遙測(cè)和日志記錄等其他操作服務(wù)通信。這意味著服務(wù)所有者需要知道這些輔助服務(wù)和庫(kù)是如何在底層實(shí)現(xiàn)的，并在它們發(fā)生變化時(shí)調(diào)整配置。
2. 根據(jù)服務(wù)的調(diào)用圖自動(dòng)生成 Envoy 配置。這種方法對(duì)于預(yù)先存在的服務(wù)來(lái)說(shuō)很簡(jiǎn)單，但是在啟動(dòng)新服務(wù)或添加新的上游集群以進(jìn)行通信時(shí)具有挑戰(zhàn)性。
3. 將所有集群推送到每個(gè)應(yīng)用程序：這個(gè)選項(xiàng)以其簡(jiǎn)單性吸引了我們，但是紙巾上的簡(jiǎn)單計(jì)算很快向我們顯示，將數(shù)百萬(wàn)個(gè)端點(diǎn)推送到每個(gè)代理是不可行的。

考慮到我們無(wú)縫采納的目標(biāo)，每個(gè)選項(xiàng)都有足夠重大的缺點(diǎn)，使我們探索了另一個(gè)選項(xiàng)：如果我們能在運(yùn)行時(shí)按需獲取集群信息，而不是預(yù)先定義它，會(huì)怎樣？當(dāng)時(shí)，服務(wù)網(wǎng)格工作仍在啟動(dòng)階段，只有少數(shù)幾個(gè)工程師在致力于它。我們聯(lián)系了 Kinvolk[29]，看看他們是否能與我們和 Envoy 社區(qū)合作實(shí)施這個(gè)功能。這次合作的結(jié)果是 按需集群發(fā)現(xiàn)[30](On-Demand Cluster Discovery，ODCDS)。有了這個(gè)功能，代理現(xiàn)在可以在第一次嘗試連接它時(shí)查找集群信息，而不是在配置中預(yù)先定義所有集群。

有了這個(gè)功能，我們需要給代理提供集群信息以供查詢(xún)。我們已經(jīng)開(kāi)發(fā)了一個(gè)實(shí)現(xiàn) Envoy XDS 服務(wù)的服務(wù)網(wǎng)格控制平面。然后我們需要從 Eureka 獲取服務(wù)信息以返回給代理。我們將 Eureka 的 VIP 和 SVIP 表示為單獨(dú)的 Envoy Cluster Discovery Service (CDS) 集群（因此，服務(wù) myservice 可能有集群 myservice.vip

1. 客戶(hù)端請(qǐng)求進(jìn)入 Envoy。
2. 根據(jù) Host / :authority 頭（此處使用的頭可配置，但這是我們的方法）提取目標(biāo)集群。如果已知該集群，跳到步驟 7。
3. 集群不存在，所以我們暫停了正在傳輸?shù)恼?qǐng)求。
4. 向控制平面的 Cluster Discovery Service (CDS) 端點(diǎn)發(fā)出請(qǐng)求?？刂破矫娓鶕?jù)服務(wù)的配置和 Eureka 注冊(cè)信息生成定制的 CDS 響應(yīng)。
5. Envoy 獲取集群（CDS），觸發(fā)通過(guò) Endpoint Discovery Service (EDS) 拉取端點(diǎn)。根據(jù)該 VIP 或 SVIP 的 Eureka 狀態(tài)信息返回集群的端點(diǎn)。
6. 客戶(hù)端請(qǐng)求解除暫停。
7. Envoy 正常處理請(qǐng)求：它使用負(fù)載平衡算法選擇一個(gè)端點(diǎn)并發(fā)出請(qǐng)求。

這個(gè)流程在幾毫秒內(nèi)完成，但只在對(duì)集群的第一次請(qǐng)求時(shí)。之后，Envoy 的行為就好像集群是在配置中定義的一樣。關(guān)鍵是，該系統(tǒng)允許我們無(wú)需任何配置即可無(wú)縫遷移服務(wù)至服務(wù)網(wǎng)格，滿(mǎn)足我們的主要采納限制之一。我們呈現(xiàn)的抽象繼續(xù)是 VIP 名稱(chēng)加上安全，并且我們可以通過(guò)配置單個(gè) IPC 客戶(hù)端連接到本地代理而不是直接連接到上游應(yīng)用程序來(lái)遷移到網(wǎng)格。我們繼續(xù)使用 Eureka 作為 VIP 和實(shí)例狀態(tài)的真實(shí)來(lái)源，這使得我們能夠在遷移時(shí)支持一些應(yīng)用程序在網(wǎng)格上，而另一些不在網(wǎng)格上的異構(gòu)環(huán)境。還有一個(gè)額外的好處：我們可以通過(guò)僅為我們實(shí)際通信的集群獲取數(shù)據(jù)來(lái)保持 Envoy 的內(nèi)存使用率較低。

圖片

上圖展示了一個(gè) Java 應(yīng)用中的 IPC 客戶(hù)端通過(guò) Envoy 與注冊(cè)為 SVIP A 的主機(jī)通信。 Envoy 從網(wǎng)格控制平面獲取 SVIP A 的集群和端點(diǎn)信息。網(wǎng)格控制平面從 Eureka 獲取主機(jī)信息。

按需獲取此數(shù)據(jù)的缺點(diǎn)是：這會(huì)增加對(duì)集群的第一次請(qǐng)求的延遲。我們遇到了服務(wù)在第一次請(qǐng)求時(shí)需要非常低延遲訪問(wèn)的用例，并且增加了幾毫秒額外的開(kāi)銷(xiāo)。對(duì)于這些用例，服務(wù)需要預(yù)定義它們通信的集群，或在第一次請(qǐng)求之前準(zhǔn)備好連接。我們還考慮過(guò)根據(jù)歷史請(qǐng)求模式在代理啟動(dòng)時(shí)從控制平面預(yù)推送集群?？偟膩?lái)說(shuō)，我們覺(jué)得系統(tǒng)中的降低的復(fù)雜性證明了對(duì)少量服務(wù)的缺點(diǎn)是合理的。

我們?cè)诜?wù)網(wǎng)格之旅的初期?，F(xiàn)在我們真誠(chéng)地使用它，我們希望與社區(qū)合作做出更多的 Envoy 改進(jìn)。將我們的 自適應(yīng)并發(fā)限制[31] 實(shí)現(xiàn)移植到 Envoy 是一個(gè)很好的開(kāi)始 - 我們期待著與社區(qū)在更多方面合作。我們特別對(duì)社區(qū)在增量 EDS 方面的工作感興趣。EDS 端點(diǎn)占了更新量的最大部分，這對(duì)控制平面和 Envoy 造成了不必要的壓力。

我們要非常感謝 Kinvolk 的人員對(duì) Envoy 的貢獻(xiàn)：Alban Crequy, Andrew Randall, Danielle Tal, 特別是 Krzesimir Nowak 的出色工作。我們也要感謝 Envoy 社區(qū)的支持和鋒利的審查：Adi Peleg, Dmitri Dolguikh, Harvey Tuch, Matt Klein, 和 Mark Roth。與你們所有人合作是一次很好的經(jīng)歷。

這是我們通向服務(wù)網(wǎng)格之旅的系列文章的第一篇，敬請(qǐng)期待。

參考資料

[1] 

Zero Configuration Service Mesh with On-Demand Cluster Discovery: https://netflixtechblog.com/zero-configuration-service-mesh-with-on-demand-cluster-discovery-ac6483b52a51

[2] Netflix的流媒體完全運(yùn)行在AWS上: https://netflixtechblog.com/four-reasons-we-choose-amazons-cloud-as-our-computing-platform-4aceb692afec

[3] CNCF: https://www.cncf.io/

[4] 2012年圣誕節(jié)的宕機(jī): https://netflixtechblog.com/a-closer-look-at-the-christmas-eve-outage-d7b409a529ee

[5] 我們構(gòu)建了Eureka: https://netflixtechblog.com/netflix-shares-cloud-load-balancing-and-failover-tool-eureka-c10647ef95e5

[6] Ribbon（內(nèi)部名為NIWS）用于IPC: https://netflixtechblog.com/announcing-ribbon-tying-the-netflix-mid-tier-services-together-a89346910a62

[7] GraphQL: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2

[8] gRPC: https://netflixtechblog.com/practical-api-design-at-netflix-part-1-using-protobuf-fieldmask-35cfdc606518

[9] node.js: https://netflixtechblog.com/debugging-node-js-in-production-75901bb10f2d

[10] Python: https://netflixtechblog.com/python-at-netflix-bba45dae649e

[11] 自適應(yīng)并發(fā)限制: https://netflixtechblog.medium.com/performance-under-load-3e6fa9a60581

[12] 斷路器: https://netflixtechblog.com/making-the-netflix-api-more-resilient-a8ec62159c2d

[13] Envoy: https://www.envoyproxy.io/

[14] 許多關(guān)鍵的彈性功能: https://github.com/envoyproxy/envoy/issues/7789

[15] 良好的擴(kuò)展點(diǎn): https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/wasm_filter.html

[16] 通過(guò)一個(gè)集中的控制平面配置代理: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration

[17] GraphQL: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2

[18] gRPC: https://netflixtechblog.com/practical-api-design-at-netflix-part-1-using-protobuf-fieldmask-35cfdc606518

[19] node.js: https://netflixtechblog.com/debugging-node-js-in-production-75901bb10f2d

[20] Python: https://netflixtechblog.com/python-at-netflix-bba45dae649e

[21] 自適應(yīng)并發(fā)限制: https://netflixtechblog.medium.com/performance-under-load-3e6fa9a60581

[22] 熔斷: https://netflixtechblog.com/making-the-netflix-api-more-resilient-a8ec62159c2d

[23] Envoy: https://www.envoyproxy.io/

[24] 許多關(guān)鍵的彈性功能: https://github.com/envoyproxy/envoy/issues/7789

[25] 良好的擴(kuò)展點(diǎn): https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/wasm_filter.html

[26] 中央控制平面配置代理的能力: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration

[27] 現(xiàn)成的抽象: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology

[28] 廣告: https://netflixtechblog.com/ensuring-the-successful-launch-of-ads-on-netflix-f99490fdf1ba

[29] Kinvolk: https://kinvolk.io/

[30] 按需集群發(fā)現(xiàn): https://github.com/envoyproxy/envoy/pull/18723

[31] 自適應(yīng)并發(fā)限制: https://github.com/envoyproxy/envoy/issues/7789