目標(biāo)

Netflix的云網(wǎng)關(guān)團(tuán)隊(duì)一直致力于幫助系統(tǒng)減少錯誤，獲得更高的可用性，并提高故障恢復(fù)能力。因?yàn)镹etflix每秒有超過一百萬次請求，即使是很低的錯誤率也會影響到會員體驗(yàn)，所以每一點(diǎn)提升都有幫助。

因此，我們向Zuul和其他團(tuán)隊(duì)學(xué)習(xí)，改進(jìn)負(fù)載均衡實(shí)現(xiàn)，以進(jìn)一步減少由服務(wù)器過載引起的錯誤。

背景

Zuul以前用基于輪詢的Ribbon負(fù)載均衡器[3]，并基于某些過濾機(jī)制將連接失敗率高的服務(wù)器列入黑名單。

過去幾年里，我們做了一些改進(jìn)和定制，比如向最近上線的服務(wù)器發(fā)送較少流量，以避免過載。這些改進(jìn)已經(jīng)取得了顯著效果，但對于某些問題比較多的原始集群，還是會看到與負(fù)載相關(guān)的錯誤率遠(yuǎn)高于預(yù)期。

如果集群中所有服務(wù)器都過載，那選擇哪一臺服務(wù)器幾乎沒有什么區(qū)別，不過現(xiàn)實(shí)中我們經(jīng)?？吹街挥心硞€服務(wù)器子集過載的情況。例如:

服務(wù)器冷啟動后(在紅黑部署和觸發(fā)自動伸縮期間)。

由于大量動態(tài)屬性/腳本/數(shù)據(jù)更新或大型GC事件，服務(wù)器暫時變慢/阻塞。

服務(wù)器硬件問題。經(jīng)常會看到某些服務(wù)器運(yùn)行得總是比其他服務(wù)器慢，有可能是由于鄰居節(jié)點(diǎn)占用太多資源，也可能因?yàn)橛布煌?/p>

指導(dǎo)原則

在開始一個項(xiàng)目時，需要記住一些原則，從而幫助指導(dǎo)在設(shè)計軟件時需要做出的大大小小的決定，這個項(xiàng)目基于的原則如下。

在現(xiàn)有負(fù)載均衡器框架的約束下工作

我們已經(jīng)將之前定制的負(fù)載均衡器集成到了Zuul代碼庫中，從而使得無法與Netflix的其他團(tuán)隊(duì)共享這些定制。因此，我們決定這次基于約束條件并做出額外投資，從一開始就考慮復(fù)用，從而能夠直接在其他系統(tǒng)中使用，減少重新發(fā)明輪子的代價。

向他人學(xué)習(xí)

嘗試在他人的想法和實(shí)現(xiàn)基礎(chǔ)上構(gòu)建，例如之前在Netflix其他IPC棧中試用的"二選一(choice-of-2)"和"試用期(probation)"算法。

避免分布式狀態(tài)

選擇本地決策，避免跨集群協(xié)調(diào)狀態(tài)的彈性問題、復(fù)雜性和滯后。

避免客戶端配置和手動調(diào)優(yōu)

多年來基于Zuul的操作經(jīng)驗(yàn)表明，將服務(wù)配置的部分置于不屬于同一團(tuán)隊(duì)的客戶服務(wù)中會導(dǎo)致問題。

一個問題是，客戶端配置往往與服務(wù)端不斷變化的現(xiàn)實(shí)不同步，或者在不同團(tuán)隊(duì)擁有的服務(wù)之間引入耦合的變更管理。

例如，用于服務(wù)X的EC2實(shí)例類型升級，導(dǎo)致該集群所需節(jié)點(diǎn)減少。因此，現(xiàn)在服務(wù)Y中的"每臺主機(jī)最大連接數(shù)"客戶端配置應(yīng)該增加，以反映新增加的容量。應(yīng)該先對客戶端進(jìn)行更改，還是先對服務(wù)端進(jìn)行更改，還是同時對兩者進(jìn)行更改？更有可能的是，完全忘了要改配置，從而導(dǎo)致更多問題。

盡可能不要配置靜態(tài)閾值，而是采用基于當(dāng)前流量、性能和環(huán)境變化的自適應(yīng)機(jī)制。

當(dāng)需要靜態(tài)閾值時，與其讓服務(wù)團(tuán)隊(duì)將閾值配置協(xié)調(diào)到每個客戶端，不如讓服務(wù)在運(yùn)行時進(jìn)行通信，以避免跨團(tuán)隊(duì)邊界推動更改的問題。

負(fù)載均衡方法

主要的想法是，雖然服務(wù)器延遲的最佳數(shù)據(jù)來源是客戶端視圖，但服務(wù)器利用率的最佳數(shù)據(jù)來源是服務(wù)器本身。結(jié)合這兩種數(shù)據(jù)源，可以得到最有效的負(fù)載均衡。

我們基于一組互補(bǔ)機(jī)制，其中大多數(shù)已經(jīng)被其他人開發(fā)和使用過，只是以前可能沒有以這種方式組合。

用于在服務(wù)器之間進(jìn)行選擇的二選一算法(choice-of-2 algorithm)。

基于服務(wù)器利用率的負(fù)載均衡器視圖進(jìn)行主負(fù)載均衡。

基于服務(wù)器利用率的服務(wù)器視圖進(jìn)行二次均衡。

基于試用期和基于服務(wù)器世代的機(jī)制，避免新啟動的服務(wù)器過載。

隨著時間推移，收集的服務(wù)器統(tǒng)計數(shù)據(jù)衰減為零。

Join-the-Shortest-Queue和服務(wù)器報告利用率相結(jié)合

我們選擇支持常用的Join-the-shortest-queue(JSQ)算法，并將服務(wù)器報告的利用率作為第二算法，以嘗試結(jié)合兩者達(dá)到最佳效果。

JSQ的問題

Join-the-shortest-queue對于單個負(fù)載均衡器非常有效，但如果跨負(fù)載均衡器集群使用，則會出現(xiàn)嚴(yán)重問題。負(fù)載均衡器會傾向于在同一時間選擇相同的低利用率服務(wù)器，從而造成超載，然后轉(zhuǎn)移到下一個利用率最低的服務(wù)器并造成超載，以此類推……

通過結(jié)合使用JSQ和二選一算法，可以在很大程度上消除羊群問題，除了負(fù)載均衡器沒有完整的服務(wù)器使用信息之外，其他方面都很好。

JSQ通常僅從本地負(fù)載均衡器計算到服務(wù)器的正在使用的連接數(shù)量來實(shí)現(xiàn)，但是當(dāng)有10到100個負(fù)載均衡器節(jié)點(diǎn)時，本地視圖可能會產(chǎn)生誤導(dǎo)。

單個負(fù)載平衡器的觀點(diǎn)可能與實(shí)際情況大不相同

例如，在上圖中，負(fù)載均衡器A有一個到服務(wù)器X的請求和一個到服務(wù)器Z的請求，但沒有到服務(wù)器Y的請求。所以當(dāng)它收到新請求時，基于本地數(shù)據(jù)，選擇利用率最小的服務(wù)器，會選擇服務(wù)器Y，但這不是正確的選擇。服務(wù)器Y實(shí)際上負(fù)載最重，其他兩個負(fù)載均衡器目前都有請求發(fā)送到服務(wù)器Y上，但負(fù)載均衡器A沒有辦法知道。

這說明單個負(fù)載均衡器的觀點(diǎn)與實(shí)際情況完全不同。

在只依賴客戶端視圖時遇到的另一個問題是，對于大型集群(特別是與低流量相結(jié)合時)，負(fù)載均衡器通常只有幾個活躍連接，和集群中的某個子集交互。因此，當(dāng)它選擇哪個服務(wù)器負(fù)載最少時，通常只是在若干個它認(rèn)為負(fù)載都是0的服務(wù)器之間進(jìn)行選擇，而并沒有關(guān)于所選服務(wù)器的利用率的數(shù)據(jù)，所以只能盲猜。

這個問題的解決方案是與所有其他負(fù)載均衡器共享所有活躍連接數(shù)狀態(tài)……但這樣就需要解決分布式狀態(tài)問題。

考慮到獲得的好處要大于付出的成本，因此我們通常只將分布式可變狀態(tài)作為最后手段:

分布式狀態(tài)增加了部署和金絲雀發(fā)布等任務(wù)的運(yùn)維開銷和復(fù)雜性。

彈性風(fēng)險與數(shù)據(jù)損壞的爆炸半徑相關(guān)(1%負(fù)載均衡器上數(shù)據(jù)損壞讓人煩惱，但100%負(fù)載均衡器上數(shù)據(jù)損壞會造成停機(jī))。

在負(fù)載均衡器之間實(shí)現(xiàn)P2P分布式狀態(tài)系統(tǒng)的成本，或者運(yùn)維一個具有處理大量讀寫流量所需的性能和彈性憑證的單一數(shù)據(jù)庫的成本。

另一種更簡單的解決方案(也是我們選擇的)，是依賴于服務(wù)器向每個負(fù)載均衡器報告資源使用情況……

服務(wù)器報告使用率

服務(wù)器主動上報其使用率的好處是可以提供所有使用了該服務(wù)器的負(fù)載均衡器的完整信息，從而避免JSQ的不完整問題。

對此有兩種實(shí)現(xiàn)方式:

運(yùn)行狀況檢查端點(diǎn)主動輪詢每個服務(wù)器的當(dāng)前利用率。

被動跟蹤來自服務(wù)器的響應(yīng)，并標(biāo)注其當(dāng)前利用率數(shù)據(jù)。

我們選擇第二種方式，其實(shí)現(xiàn)簡單，可以頻繁更新數(shù)據(jù)，避免了N個負(fù)載均衡器每隔幾秒鐘輪詢M個服務(wù)器所帶來的額外開銷。

被動策略的影響是，負(fù)載均衡器向一臺服務(wù)器發(fā)送請求的頻率越高，獲得的該服務(wù)器的利用率數(shù)據(jù)就越新。因此RPS越高，負(fù)載均衡的有效性就越高。但反過來，RPS越低，負(fù)載均衡的效果就越差。

這對我們來說不是問題，但對于通過特定負(fù)載均衡器處理低RPS(同時通過另一個負(fù)載均衡器處理高RPS)的服務(wù)來說，主動輪詢運(yùn)行狀況檢查可能更有效。臨界點(diǎn)是負(fù)載均衡器向每個服務(wù)器發(fā)送的RPS低于運(yùn)行狀況檢查的輪詢頻率。

服務(wù)端實(shí)現(xiàn)

我們在服務(wù)端通過簡單跟蹤活躍請求計數(shù)來實(shí)現(xiàn)，將其轉(zhuǎn)換為該服務(wù)器配置的最大百分比，并將其作為HTTP響應(yīng)報頭:

X-Netflix.server.utilization: [, target=]

服務(wù)器可以指定可選的目標(biāo)利用率，從而標(biāo)識預(yù)期在正常條件下運(yùn)行的利用率百分比，負(fù)載均衡器基于這一數(shù)據(jù)進(jìn)行粗粒度過濾，后面會詳細(xì)介紹。

我們嘗試使用活躍計數(shù)以外的指標(biāo)，例如操作系統(tǒng)報告的cpu利用率和平均負(fù)載，但發(fā)現(xiàn)它們會引起振蕩，原因似乎是因?yàn)樗鼈兪腔跐L動平均值計算的，因此有一定的延遲。所以我們決定現(xiàn)在只用相對簡單的實(shí)現(xiàn)，即只計算活躍請求。

用二選一算法代替輪詢

由于我們希望能夠通過比較服務(wù)器的統(tǒng)計數(shù)據(jù)來選擇服務(wù)器，因此不得不拋棄現(xiàn)有的簡單輪詢實(shí)現(xiàn)。

我們在Ribbon算法中嘗試的一個替代方案是JSQ與ServerListSubsetFilter相結(jié)合，以減少分布式JSQ的羊群問題。這樣可以得到合理的結(jié)果，但是結(jié)果在目標(biāo)服務(wù)器之間的請求分布仍然過于分散。

因此，我們參考了Netflix另一個團(tuán)隊(duì)的早期經(jīng)驗(yàn)，并實(shí)現(xiàn)了"二選一(Choice-of-2)"算法。這樣做的優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，使負(fù)載均衡器的cpu成本較低，并能提供良好的請求分布。

根據(jù)綜合因素進(jìn)行選擇

為了在服務(wù)器之間進(jìn)行選擇，我們比較了3個不同的因素:

客戶端運(yùn)行狀況: 該服務(wù)器連接相關(guān)錯誤的滾動百分比。

服務(wù)器利用率: 該服務(wù)器的最新利用率數(shù)據(jù)。

客戶端利用率: 從當(dāng)前負(fù)載均衡器發(fā)送到該服務(wù)器的活躍請求數(shù)。

這3個因素被用來為每個服務(wù)器計算分?jǐn)?shù)，然后比較總分?jǐn)?shù)選擇獲勝者。

像這樣使用多個因素確實(shí)會使實(shí)現(xiàn)更加復(fù)雜，但可以避免僅依賴一個因素可能出現(xiàn)的邊際問題。

例如，如果一臺服務(wù)器開始出現(xiàn)故障并拒絕所有請求，那么上報的利用率將會低得多(因?yàn)榫芙^請求比接受請求開銷更小)，如果這是唯一考慮的因素，那么所有負(fù)載均衡器將開始向那臺壞服務(wù)器發(fā)送更多請求?？蛻舳诉\(yùn)行狀況因素緩解了這種情況。

過濾

當(dāng)隨機(jī)選擇2臺服務(wù)器進(jìn)行比較時，會過濾掉任何超過安全利用率配置和運(yùn)行狀況閾值的服務(wù)器。

每個請求都會進(jìn)行這種過濾，以避免定期過濾會出現(xiàn)的過時問題。為了避免在負(fù)載均衡器上造成較高的cpu負(fù)載，我們盡力而為(best-effort)嘗試N次來隨機(jī)選擇一個可用服務(wù)器，然后在必要時回退到未篩選的服務(wù)器。

當(dāng)服務(wù)器池中有很大一部分存在長期問題時，這樣的篩選非常有用。在這種情況下，隨機(jī)選擇2個服務(wù)器通常會出現(xiàn)選擇了2個壞服務(wù)器進(jìn)行比較的情況。

但缺點(diǎn)是這依賴于靜態(tài)配置閾值，而這是我們試圖避免的。測試結(jié)果讓我們相信這點(diǎn)依賴是值得的，即使只依賴一些通用(非特定于服務(wù)的)閾值。

試用期

對于任何沒有發(fā)送響應(yīng)給負(fù)載均衡器的服務(wù)器，一次只允許一個活躍請求，隨后會過濾掉這些試用服務(wù)器，直到收到來自它們的響應(yīng)。

這有助于避免新啟動的服務(wù)器還沒有機(jī)會顯示使用率數(shù)據(jù)之前就因大量請求而超載。

基于服務(wù)器世代的預(yù)熱

我們基于服務(wù)器世代在服務(wù)器啟動的前90秒內(nèi)逐步增加流量。

這是另一種有用的機(jī)制，就像試用期一樣，可以在微妙的發(fā)布后增加一些關(guān)于服務(wù)器過載的警告。

統(tǒng)計衰變

為確保服務(wù)器不會被永久列入黑名單，我們將衰減率應(yīng)用到所有用于負(fù)載均衡的統(tǒng)計數(shù)據(jù)上(目前是30秒的線性衰減)。例如，如果一個服務(wù)器的錯誤率上升到80%，停止向它發(fā)送流量，使用的數(shù)據(jù)將在30秒內(nèi)衰減為零，比方說15秒后是會是40%)。

運(yùn)維影響

差距更大的請求分布

不用輪詢進(jìn)行負(fù)載均衡的負(fù)面影響是，以前服務(wù)器之間的請求分布非常均衡，現(xiàn)在服務(wù)器之間的負(fù)載差距更大。

"二選一"算法在很大程度上能緩解這種情況(與跨集群中所有服務(wù)器或服務(wù)器子集的JSQ相比)，但不可能完全避免。

因此，在運(yùn)維方面確實(shí)需要考慮這一點(diǎn)，特別是在金絲雀分析中，我們通常比較請求計數(shù)、錯誤率、cpu等的絕對值。

越慢的服務(wù)器接收的流量越少

顯然這是預(yù)期效果，但對于習(xí)慣于輪詢的團(tuán)隊(duì)來說，流量是平等分配的，這對運(yùn)維方面會產(chǎn)生連鎖反應(yīng)。

由于跨原始服務(wù)器的流量分布現(xiàn)在依賴于它們的利用率，如果一些服務(wù)器正在運(yùn)行效率更高或更低的不同構(gòu)建，那么將接收到更多或更少的流量。所以:

當(dāng)集群采用紅黑部署時，如果新的服務(wù)器組性能下降，那么該組的流量比例將小于50%。

同樣的效果可以在金絲雀集群中看到，基線組可能會接收到與金絲雀組不同的流量。所以當(dāng)我們著眼于指標(biāo)時，最好著眼于RPS和CPU的組合(例如RPS在金絲雀中可能更低，而CPU相同)。

更低效的異常值檢測。我們通常會自動監(jiān)控集群中的異常服務(wù)器(通常是由于硬件問題導(dǎo)致啟動速度變慢的虛擬機(jī))并終止它們，當(dāng)由于負(fù)載均衡而接收較少流量時，這種檢測就更加困難。

滾動動態(tài)數(shù)據(jù)更新

從輪詢遷移到新的負(fù)載均衡器取得了很好的效果，可以很好的配合動態(tài)數(shù)據(jù)和屬性的分階段更新。

最佳實(shí)踐是每次在一個區(qū)域(數(shù)據(jù)中心)部署數(shù)據(jù)更新，以限制意外問題的爆發(fā)半徑。

即使數(shù)據(jù)更新本身沒有引起任何問題，服務(wù)器應(yīng)用更新的行為也會導(dǎo)致短暫的負(fù)載高峰(通常與GC相關(guān))。如果此峰值同時出現(xiàn)在集群中所有服務(wù)器上，則可能導(dǎo)致負(fù)載下降以及向上游傳播大量錯誤。在這種情況下，因?yàn)樗蟹?wù)器的負(fù)載都很高，負(fù)載均衡器幾乎無法提供幫助。

然而，如果考慮與自適應(yīng)負(fù)載均衡器結(jié)合使用，一個解決方案是在集群服務(wù)器之間進(jìn)行滾動數(shù)據(jù)更新。如果只有一小部分服務(wù)器同時應(yīng)用更新，那么只要還有足夠服務(wù)器能夠承載流量，負(fù)載均衡器就可以短暫減少到這些服務(wù)器的流量。

合成負(fù)載測試結(jié)果

在開發(fā)、測試和調(diào)優(yōu)負(fù)載均衡器時，我們廣泛使用了合成負(fù)載測試場景，這在使用真實(shí)集群和網(wǎng)絡(luò)驗(yàn)證有效性時非常有用，可以作為單元測試之后的可重復(fù)步驟，但還沒有使用真實(shí)用戶流量。

測試的更多細(xì)節(jié)在后面的附錄中列出，現(xiàn)總結(jié)要點(diǎn)如下:

與輪詢實(shí)現(xiàn)相比，啟用了所有功能的新負(fù)載均衡器在負(fù)載下降和連接錯誤方面降低了幾個數(shù)量級。

平均和長尾延遲有了實(shí)質(zhì)性改善(與輪詢實(shí)現(xiàn)相比減少了3倍)。

服務(wù)器本身由于添加了特性，顯著增加了價值，減少了一個數(shù)量級的錯誤以及大部分延遲。

結(jié)果比較

對實(shí)際生產(chǎn)流量的影響

我們發(fā)現(xiàn)，只要服務(wù)器能夠處理，新負(fù)載均衡器就能非常有效的將盡可能多的流量分配到每個服務(wù)器。這對于在間歇和持續(xù)降級的服務(wù)器之間進(jìn)行路由具有很好的效果，無需任何人工干預(yù)，從而避免工程師在半夜被叫醒處理重大生產(chǎn)問題。

很難說明在正常運(yùn)行時的影響，但在生產(chǎn)事故中甚至在某些服務(wù)的正常穩(wěn)態(tài)運(yùn)行中，可以看到對應(yīng)的影響。

事故發(fā)生時

最近的事故涉及到服務(wù)中的錯誤，該錯誤導(dǎo)致越來越多的服務(wù)器線程隨著時間的推移而阻塞。從服務(wù)器啟動的那一刻起，每小時都會阻塞幾個線程，直到最終達(dá)到最大負(fù)載并造成負(fù)載下降。

在下面的服務(wù)器RPS圖表中，可以看到在凌晨3點(diǎn)之前，服務(wù)器負(fù)載分布差距較大，這是由于負(fù)載均衡器向阻塞線程數(shù)量較多的服務(wù)器發(fā)送較少流量的緣故。然后，在凌晨3點(diǎn)25分之后，自動縮放啟動更多服務(wù)器，由于這些服務(wù)器還沒有任何線程阻塞，每個服務(wù)器收到的RPS大約是現(xiàn)有服務(wù)器的兩倍，可以成功處理更多流量。

每服務(wù)器RPS

現(xiàn)在，如果我們看一下同一時間范圍內(nèi)每臺服務(wù)器的錯誤率圖表，可以看到，在整個事故過程中，所有服務(wù)器的錯誤分布是相當(dāng)均勻的，盡管某些服務(wù)器的容量比其他服務(wù)器小得多。這表明負(fù)載均衡器在有效工作，而由于集群整體可用容量太小，因此所有服務(wù)器都被推到稍稍超過其有效容量的位置。

然后，當(dāng)自動縮放啟動新服務(wù)器時，新服務(wù)器處理了盡可能多的流量，以至于出現(xiàn)了與集群其他部分相同的錯誤。

每服務(wù)器每秒錯誤

因此，綜上所述，負(fù)載均衡器在向服務(wù)器分配流量方面非常有效，但在這種情況下，沒有啟動足夠的新服務(wù)器，從而導(dǎo)致沒法將整體錯誤水平降至零。

穩(wěn)態(tài)

我們還看到，在某些服務(wù)中，由于GC事件而出現(xiàn)幾秒鐘的負(fù)載下降，因此穩(wěn)態(tài)噪聲顯著降低。從這里可以看出，啟用新的負(fù)載均衡器后，錯誤大幅減少:

啟用新負(fù)載均衡器前后數(shù)周內(nèi)與負(fù)載相關(guān)的錯誤率

告警中的差距

一個意料之外的影響是突出了我們自動告警中的一些差距。一些基于服務(wù)錯誤率的現(xiàn)有告警，以前會在漸進(jìn)式問題只影響到集群的一小部分時發(fā)出告警，現(xiàn)在因?yàn)殄e誤率一直很低，告警會晚得多，或者根本不發(fā)出告警。這意味著，有時沒法將影響集群的大問題通知給團(tuán)隊(duì)。解決方案是增加對利用率指標(biāo)的偏差而不僅僅是錯誤指標(biāo)的額外告警來彌補(bǔ)這些差距。

結(jié)論

本文并不是為Zuul做宣傳(盡管它是一個偉大的系統(tǒng))，只是為代理/服務(wù)網(wǎng)格/負(fù)載均衡社區(qū)分享和增加了一個有趣的方法。Zuul是測試、實(shí)施和改進(jìn)這些類型負(fù)載均衡方案的偉大系統(tǒng)，以Netflix的需求和規(guī)模來運(yùn)行，使我們有能力證明和改進(jìn)這些方法。

有許多不同方法可以改善負(fù)載均衡，而這個方法對我們來說效果很好，大大減少了與負(fù)載有關(guān)的錯誤率，并極大改善了真實(shí)流量的負(fù)載均衡。

然而，對于任何軟件系統(tǒng)來說，都應(yīng)該根據(jù)自己組織的限制和目標(biāo)來做決定，并盡量避免追求完美。

附錄--合成負(fù)載測試的結(jié)果

測試場景

這個負(fù)載測試場景重現(xiàn)了這樣一種情況: 小型原始集群正在進(jìn)行紅黑部署，而新部署的集群存在冷啟動問題或某種性能退化(通過人為在新部署的服務(wù)器上為每個請求注入額外延遲和cpu負(fù)載來模擬)。

該測試將4000 RPS發(fā)送到一個大型Zuul集群(200個節(jié)點(diǎn))，該集群反過來代理到一個小型Origin集群(20個實(shí)例)，幾分鐘后，啟用第二個緩慢的Origin集群(另外20個實(shí)例)。

啟用所有功能

以下是啟用了所有功能的新負(fù)載均衡器的指標(biāo)圖表。

啟用新負(fù)載均衡器所有功能進(jìn)行負(fù)載測試

作為參考，看看流量是如何在較快和較慢的服務(wù)器組之間分配的，可以看到，負(fù)載均衡器把發(fā)送到較慢組的比例減少到15%左右(預(yù)期50%)。

正常集群和慢速集群之間的流量分布

禁用服務(wù)器利用率

還是新負(fù)載均衡器，但禁用了服務(wù)器利用率功能，因此只有客戶端數(shù)據(jù)被用于均衡。

使用新負(fù)載均衡器進(jìn)行負(fù)載測試，但禁用了服務(wù)器利用率特性

原始實(shí)現(xiàn)

這是最初的輪詢負(fù)載均衡器與服務(wù)器黑名單功能。

使用原始負(fù)載均衡器進(jìn)行負(fù)載測試

審核編輯：湯梓紅