點擊下方“JavaEdge”，選擇“設為星標”

第一時間關注技術干貨！

免責聲明~ 任何文章不要過度深思！ 萬事萬物都經(jīng)不起審視，因為世上沒有同樣的成長環(huán)境，也沒有同樣的認知水平，更「沒有適用于所有人的解決方案」； 不要急著評判文章列出的觀點，只需代入其中，適度審視一番自己即可，能「跳脫出來從外人的角度看看現(xiàn)在的自己處在什么樣的階段」才不為俗人。 怎么想、怎么做，全在乎自己「不斷實踐中尋找適合自己的大道」

0 引言

在 2020 年 11 月，我們在博客文章 通過優(yōu)先級負載丟棄保持 Netflix 的可靠性 中引入了在 API 網(wǎng)關層進行優(yōu)先級負載丟棄的概念。本文探討如何將這一策略擴展到單個服務層，特別是在視頻流控制平面和數(shù)據(jù)平面中，以進一步提升用戶體驗和系統(tǒng)彈性。

1 Netflix 負載丟棄的演進

最初的優(yōu)先級負載丟棄方法是在 Zuul API 網(wǎng)關層實現(xiàn)的。該系統(tǒng)能夠有效管理不同類型的網(wǎng)絡流量，確保關鍵的播放請求優(yōu)先于不太關鍵的遙測流量。

在此基礎上，我們認識到需要在架構的更深層次——具體到服務層——應用類似的優(yōu)先級邏輯，在同一服務中對不同類型的請求賦予不同的優(yōu)先級。在服務層以及邊緣 API 網(wǎng)關同時應用這些技術的優(yōu)勢包括：

1. 服務團隊可以自主掌控其優(yōu)先級邏輯，并應用更細粒度的優(yōu)先級控制。

2. 可用于后臺對后臺的通信，例如不通過邊緣 API 網(wǎng)關的服務之間的通信。

3. 服務可以通過將不同請求類型整合到一個集群中并在必要時丟棄低優(yōu)先級請求，而不是為失敗隔離維護單獨的集群，從而更高效地使用云資源。

PlayAPI 是視頻流控制平面上的一個關鍵后臺服務，負責處理設備發(fā)起的播放清單和許可證請求，這些請求是啟動播放所必需的。我們根據(jù)關鍵程度將這些請求分為兩類：

1. 用戶發(fā)起請求（關鍵）：這些請求在用戶點擊播放時發(fā)出，直接影響用戶開始觀看節(jié)目或電影的能力。

2. 預取請求（非關鍵）：這些請求是在用戶瀏覽內容時為了優(yōu)化潛在延遲而樂觀地發(fā)出的。如果用戶選擇觀看特定標題，預取失敗不會導致播放失敗，但會略微增加從點擊播放到視頻顯示在屏幕上的延遲。

用戶瀏覽內容時 Netflix 在 Chrome 上向 PlayAPI 發(fā)出的預取請求

2.1 問題

為了應對流量高峰、高后端延遲或后端服務擴展不足的情況，PlayAPI 過去使用并發(fā)限制器來限制請求，這會同時減少用戶發(fā)起請求和預取請求的可用性。這種方法存在以下問題：

1. 預取流量高峰降低了用戶發(fā)起請求的可用性。

2. 當系統(tǒng)有足夠的能力處理所有用戶發(fā)起請求時，后端延遲增加會同時降低用戶發(fā)起請求和預取請求的可用性。

將關鍵請求和非關鍵請求分片到單獨的集群是一個選項，這可以解決問題 1，并在兩種請求類型之間提供故障隔離，但其計算成本更高。分片的另一個缺點是增加了一些操作開銷——工程師需要確保 CI/CD、自動擴展、指標和警報針對新集群正確配置。

選項 1— 無隔離

選項 2— 隔離但計算成本更高

2.2 我們的解決方案

我們在 PlayAPI 中實現(xiàn)了一個并發(fā)限制器，該限制器在不物理分片兩個請求處理程序的情況下優(yōu)先處理用戶發(fā)起請求。這種機制使用了開源 Netflix/concurrency-limits Java 庫的分區(qū)功能。我們在限制器中創(chuàng)建了兩個分區(qū)：

• 用戶發(fā)起分區(qū)：保證 100% 的吞吐量。

• 預取分區(qū)：僅使用多余的容量。

選項 3— 單集群優(yōu)先級負載丟棄提供應用級隔離且計算成本更低。每個實例處理兩種請求類型，并具有一個動態(tài)調整大小的分區(qū)，確保預取請求僅使用多余容量。必要時，用戶發(fā)起請求可以“借用”預取容量。

分區(qū)限制器被配置為一個預處理 Servlet Filter，它通過設備發(fā)送的 HTTP 頭確定請求的關鍵性，從而避免了讀取和解析被拒絕請求的請求體的需要。這確保了限制器本身不會成為瓶頸，并且可以有效拒絕請求，同時使用最少的 CPU。例如，該過濾器可以初始化如下：

Filter filter = new ConcurrencyLimitServletFilter(
new ServletLimiterBuilder()
.named("playapi")
.partitionByHeader("X-Netflix.Request-Name")
.partition("user-initiated", 1.0)
.partition("pre-fetch", 0.0)
.build());

需要注意的是，在穩(wěn)定狀態(tài)下，沒有限流，優(yōu)先級對預取請求的處理沒有任何影響。優(yōu)先級機制僅在服務器達到并發(fā)限制并需要拒絕請求時啟動。

2.3 測試

為了驗證我們的負載削減是否按預期工作，我們使用了故障注入測試，在預取調用中注入了2秒的延遲，這些調用的典型p99延遲小于200毫秒。故障被注入到一個基線實例中，該實例有常規(guī)的負載削減，還有一個金絲雀實例中，有優(yōu)先級的負載削減。PlayAPI調用的一些內部服務使用單獨的集群來處理用戶發(fā)起的和預取請求，并使預取集群運行得更熱。這個測試案例模擬了一個預取集群對于下游服務正在經(jīng)歷高延遲的場景。

基線 — 沒有優(yōu)先級負載削減。預取和用戶發(fā)起的都看到了可用性的同等下降

金絲雀 — 有優(yōu)先級負載削減。只有預取可用性下降，而用戶發(fā)起的可用性保持在100%

沒有優(yōu)先級負載削減的情況下，當注入延遲時，用戶發(fā)起的和預取的可用性都會下降。然而，在添加了優(yōu)先級負載削減之后，用戶發(fā)起的請求保持了100%的可用性，只有預取請求被節(jié)流。

我們已經(jīng)準備好將這個功能推廣到生產(chǎn)環(huán)境，并看看它在實際中的表現(xiàn)如何！

2.4 現(xiàn)實世界的應用和結果

Netflix的工程師努力保持我們的系統(tǒng)可用，在我們部署優(yōu)先級負載削減幾個月后，Netflix發(fā)生了一次基礎設施故障，影響了我們許多用戶的流媒體播放。一旦故障被修復，我們從Android設備上看到了每秒預取請求的12倍激增，這可能是因為積累了大量的排隊請求。

Android預取RPS的激增

這可能會導致第二次故障，因為我們的系統(tǒng)沒有擴展到能夠處理這種流量激增。PlayAPI中的優(yōu)先級負載削減在這里有幫助嗎？

是的！雖然預取請求的可用性下降到了20%，但由于優(yōu)先級負載削減，用戶發(fā)起的請求的可用性保持在99.4%以上。

預取和用戶發(fā)起的請求的可用性

在某個時刻，我們節(jié)流了超過50%的所有請求，但用戶發(fā)起的請求的可用性繼續(xù)保持在99.4%以上。

3 通用服務工作優(yōu)先級

基于這種方法的成功，我們創(chuàng)建了一個內部庫，使服務能夠根據(jù)可插拔的利用率度量執(zhí)行優(yōu)先級負載削減，具有多個優(yōu)先級級別。

與需要處理大量具有不同優(yōu)先級的請求的API網(wǎng)關不同，大多數(shù)微服務通常只接收具有少數(shù)幾個不同優(yōu)先級的請求。為了在不同服務之間保持一致性，我們引入了四個預定義的優(yōu)先級桶，受到Linux tc-prio級別的啟發(fā)：

• CRITICAL：影響核心功能 — 如果我們沒有完全失敗，這些永遠不會被削減。

• DEGRADED：影響用戶體驗 — 隨著負載的增加，這些將逐步被削減。

• BEST_EFFORT：不影響用戶 — 這些將以最大努力的方式響應，并可能在正常操作中逐步被削減。

• BULK：后臺工作，預計這些將定期被削減。

服務可以選擇上游客戶端的優(yōu)先級或通過檢查各種請求屬性（如HTTP頭或請求體）將傳入請求映射到這些優(yōu)先級桶之一，以實現(xiàn)更精確的控制。以下是服務如何將請求映射到優(yōu)先級桶的一個示例：

ResourceLimiterRequestPriorityProvider requestPriorityProvider() {
return contextProvider -> {
if (contextProvider.getRequest().isCritical()) {
return PriorityBucket.CRITICAL;
} else if (contextProvider.getRequest().isHighPriority()) {
return PriorityBucket.DEGRADED;
} else if (contextProvider.getRequest().isMediumPriority()) {
return PriorityBucket.BEST_EFFORT;
} else {
return PriorityBucket.BULK;
}
};
}

Netflix的大多數(shù)服務都在CPU利用率上自動擴展，因此它是系統(tǒng)負載的自然度量，可以與優(yōu)先級負載削減框架結合使用。一旦請求被映射到優(yōu)先級桶，服務可以根據(jù)CPU利用率決定何時從特定桶中削減流量。為了維持自動擴展所需的信號，優(yōu)先級削減只有在達到目標CPU利用率后才開始削減負載，并且隨著系統(tǒng)負載的增加，更多關鍵流量將逐步被削減，以維持用戶體驗。

例如，如果一個集群針對自動擴展的目標是60%的CPU利用率，它可以被配置為在CPU利用率超過這個閾值時開始削減請求。當流量激增導致集群的CPU利用率顯著超過這個閾值時，它將逐步削減低優(yōu)先級流量以節(jié)省資源供高優(yōu)先級流量使用。這種方法還允許更多的時間為自動擴展添加更多實例到集群。一旦添加了更多實例，CPU利用率將下降，低優(yōu)先級流量將恢復正常服務。

基于CPU利用率的不同優(yōu)先級桶的請求被負載削減的百分比

3.2 基于CPU的負載削減實驗

我們進行了一系列實驗，向一個服務發(fā)送大量請求，該服務通常以45%的CPU為目標進行自動擴展，但為了防止其擴展，以便在極端負載條件下監(jiān)控CPU負載削減。實例被配置為在60%的CPU后削減非關鍵流量，在80%的CPU后削減關鍵流量。

隨著RPS超過自動擴展量的6倍，服務能夠首先削減非關鍵請求，然后削減關鍵請求。在整個過程中，延遲保持在合理的限制內，成功的RPS吞吐量保持穩(wěn)定。

使用合成流量的基于CPU的負載削減的實驗行為.

即使RPS超過了自動擴展目標的6倍，P99延遲在整個實驗中也保持在合理的范圍內.

3.3 負載削減的反模式反模式1 — 不削減

在上述圖表中，限制器很好地保持了成功請求的低延遲。如果沒有在這里削減，我們將看到所有請求的延遲增加，而不是一些可以重試的請求的快速失敗。此外，這可能導致死亡螺旋，其中一個實例變得不健康，導致其他實例負載增加，導致所有實例在自動擴展啟動之前變得不健康。

沒有負載削減：在沒有負載削減的情況下，增加的延遲可能會降低所有請求的質量，而不是拒絕一些可以重試的請求，并且可能使實例不健康

反模式2 — 充血性失敗

另一個需要注意的反模式是充血性失敗或過于激進的削減。如果負載削減是由于流量增加，成功的RPS在負載削減后不應該下降。以下是充血性失敗的一個例子：

充血性失敗：在16:57之后，服務開始拒絕大多數(shù)請求，并且無法維持在負載削減啟動之前成功的240 RPS。這可以在固定并發(fā)限制器中看到，或者當負載削減消耗太多CPU阻止其他工作被完成時

我們可以看到，在上述的基于CPU的負載削減實驗部分，我們的負載削減實現(xiàn)避免了這兩種反模式，通過保持低延遲并在負載削減期間維持與之前一樣多的成功RPS。

4 通用基于IO的負載削減

一些服務不是CPU限制的，而是由于后端服務或數(shù)據(jù)存儲在超載時通過增加延遲施加反向壓力，它們是IO限制的。對于這些服務，我們重用了優(yōu)先級負載削減技術，但我們引入了新的利用率度量來輸入到削減邏輯中。我們最初的實現(xiàn)支持兩種基于延遲的削減形式，除了標準的自適應并發(fā)限制器（本身是平均延遲的度量）：

1. 服務可以指定每個端點的目標和最大延遲，允許服務在服務異常緩慢時削減，無論后端如何。

2. 在Data Gateway上運行的Netflix存儲服務返回觀察到的存儲目標和最大延遲SLO利用率，允許服務在它們超載分配的存儲容量時削減。

這些利用率度量提供了早期警告跡象，表明服務正在向后端生成過多的負載，并允許它在壓倒后端之前削減低優(yōu)先級工作。這些技術與僅并發(fā)限制相比的主要優(yōu)勢是它們需要的調整更少，因為我們的服務已經(jīng)必須維持嚴格的延遲服務水平目標（SLOs），例如p50 < 10ms和p100 < 500ms。因此，將這些現(xiàn)有的SLOs重新表述為利用率使我們能夠及早削減低優(yōu)先級工作，以防止對高優(yōu)先級工作產(chǎn)生進一步的延遲影響。同時，系統(tǒng)將接受盡可能多的工作，同時維持SLO。

為了創(chuàng)建這些利用率度量，我們計算有多少請求處理慢于我們的目標和最大延遲目標，并發(fā)出未能滿足這些延遲目標的請求的百分比。例如，我們的KeyValue存儲服務為每個命名空間提供了10ms的目標和500ms的最大延遲，所有客戶端都接收到每個數(shù)據(jù)命名空間的利用率度量，以輸入到它們的優(yōu)先級負載削減中。這些度量看起來像：

utilization(namespace) = {
overall = 12
latency = {
slo_target = 12,
slo_max = 0
}
system = {
storage = 17,
compute = 10,
}
}

在這種情況下，12%的請求慢于10ms目標，0%慢于500ms最大延遲（超時），17%的分配存儲被利用。不同的用例在它們的優(yōu)先級削減中咨詢不同的利用率，例如，每天寫入數(shù)據(jù)的批次可能在系統(tǒng)存儲利用率接近容量時被削減，因為寫入更多數(shù)據(jù)會造成進一步的不穩(wěn)定。

一個延遲利用率有用的示例是我們的一個關鍵文件源服務，它接受在AWS云中新文件的寫入，并作為這些文件的源（為Open Connect CDN基礎設施提供讀取服務）。寫入是最關鍵的，服務永遠不應該削減，但當后端數(shù)據(jù)存儲超載時，逐步削減對CDN較不關鍵的文件的讀取是合理的，因為它可以重試這些讀取，它們不影響產(chǎn)品體驗。

為了實現(xiàn)這個目標，源服務配置了一個基于KeyValue延遲的限制器，當數(shù)據(jù)存儲報告的目標延遲利用率超過40%時，開始削減對CDN較不關鍵的文件的讀取。然后我們通過生成超過50Gbps的讀取流量來壓力測試系統(tǒng)，其中一些是針對高優(yōu)先級文件的，一些是針對低優(yōu)先級文件的：

在這個測試中，有一定數(shù)量的關鍵寫入和大量對低優(yōu)先級和高優(yōu)先級文件的讀取。在左上角的圖表中，我們增加到每秒2000次讀取的~4MiB文件，直到我們可以在右上角的圖表中超過50Gbps觸發(fā)后端存儲的超載。當這種情況發(fā)生時，右上角的圖表顯示，即使在顯著負載下，源只削減低優(yōu)先級讀取工作以保留高優(yōu)先級寫入和讀取。在此之前，當我們達到斷裂點時，關鍵寫入和讀取會與低優(yōu)先級讀取一起失敗。在這個測試期間，文件服務的CPU負載是名義上的（<10%），所以在這種情況下，只有基于IO的限制器能夠保護系統(tǒng)。還需要注意的是，只要后端數(shù)據(jù)存儲繼續(xù)以低延遲接受它，源將服務更多的流量，防止我們過去與并發(fā)限制遇到的問題，它們要么在實際上沒有問題時過早削減，要么在我們已經(jīng)進入充血性失敗時太晚削減。

5 總結

服務級別的優(yōu)先級負載削減的實施已被證明是在保持高可用性和為Netflix客戶提供卓越用戶體驗方面邁出的重要一步，即使在意外的系統(tǒng)壓力下也是如此。

關注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

★ 作者簡介：魔都架構師，多家大廠后端一線研發(fā)經(jīng)驗，在分布式系統(tǒng)設計、數(shù)據(jù)平臺架構和AI應用開發(fā)等領域都有豐富實踐經(jīng)驗。 各大技術社區(qū)頭部專家博主。具有豐富的引領團隊經(jīng)驗，深厚業(yè)務架構和解決方案的積累。 負責： 中央/分銷預訂系統(tǒng)性能優(yōu)化 活動&券等營銷中臺建設 交易平臺及數(shù)據(jù)中臺等架構和開發(fā)設計 車聯(lián)網(wǎng)核心平臺-物聯(lián)網(wǎng)連接平臺、大數(shù)據(jù)平臺架構設計及優(yōu)化 LLM Agent應用開發(fā) 區(qū)塊鏈應用開發(fā) 大數(shù)據(jù)開發(fā)挖掘經(jīng)驗 推薦系統(tǒng)項目 目前主攻市級軟件項目設計、構建服務全社會的應用系統(tǒng)。 ”

參考：

• 編程嚴選網(wǎng)

編程嚴選網(wǎng)：http://www.javaedge.cn/ 專注分享軟件開發(fā)全生態(tài)相關技術文章、視頻教程資源、熱點資訊等，全站資源免費學習，快來看看吧~ 【編程嚴選】星球

歡迎長按圖片加好友，我會第一時間和你分享軟件行業(yè)趨勢，面試資源，學習方法等等。

添加好友備注【技術群交流】拉你進技術交流群

關注公眾號后，在后臺私信：

• 更多教程資源應有盡有，歡迎關注并加技術交流群，慢慢獲取

• 為避免大量資源被收藏白嫖而浪費各自精力，以上資源領取分別需要收取1元門檻費！