Envoy服務網格如何減輕級聯故障？

banq發表於2018-10-23

級聯故障是高吞吐量分散式系統中不可用的主要原因之一。在過去的四年中，Lyft已從單片架構轉變為數百種微服務。隨著微服務數量的增加，由於級聯故障或意外內部拒絕服務導致的中斷次數也在增加。

今天，這些故障情況在Lyft基礎設施中基本上是一個已解決的問題。Lyft部署的每項服務都會自動獲得吞吐量和併發保護。透過對我們最關鍵的服務進行一些有針對性的配置更改，基於負載的事件減少了95％，從而提高了使用者體驗。 

速率限制和併發
併發和速率限制是同一枚硬幣的兩面。在考慮限制系統負載時，運營商傳統上會考慮每秒的請求數。限制傳送到系統的請求的速率的行為是速率限制。通常進行壓力測試以確定服務什麼時候將變為過載的請求率，然後將請求率限制配置在低於該點數值的某處。在某些情況下，業務邏輯決定了速率限制。

在硬幣的另一面，我們還需要併發性，即同時使用多少個單元。這些單位可以是請求，連線等。例如，我們可以考慮某個時間點的併發飛行請求數，而不是考慮請求率。當我們考慮併發請求時，我們可以應用排隊理論來確定一個服務最大能處理多少請求數，超過這個數值將導致請求延遲增加，以及服務因資源耗盡而失敗。

速率限制

lyft / ratelimit  是一種開源Go / gRPC服務，旨在為各種應用程式啟用通用速率限制方案，可以是每IP速率限制，或每秒對資料庫的連線數。
Ratelimit在Lyft投入了生產，每秒處理數十萬個速率限制請求。我們在邊緣代理和內部服務網格中使用Ratelimit。

Envoy提供以下與這個速率限制的整合：

  1. 網路級別速率限制過濾器：Envoy可以為安裝過濾器的偵聽器上的每個新連線呼叫速率限制服務。配置指定特定域和描述符設定為速率限制。這具有限制每秒透過收聽者的連線的速率的最終效果。
  2. HTTP級別速率限制過濾器：Envoy可以為安裝過濾器的偵聽器上的每個新請求呼叫速率限制服務。

在Lyft，我們主要使用速率限制來抵禦基礎設施邊緣的負載。例如，每個使用者ID允許的請求率。這樣可以保護Lyft的服務  免受外部客戶端意外或惡意負載造成的資源匱乏 。

併發處理
 Envoy的主要優點之一是它透過網路級別的斷路系統強制執行併發限制，而不必獨立地在每個應用程式中配置和實現模式。特使支援各種型別的全分散式斷路器：

  • 最大連線數：Envoy將為上游群集中的所有主機建立的最大連線數。實際上，這通常用於保護HTTP / 1叢集，因為HTTP / 2可以透過單個連線複用請求，因此限制了減速期間的連線增長。
  • 最大掛起請求數：等待池中可用連線時將排隊的最大請求數。實際上，這僅適用於HTTP / 1群集，因為HTTP / 2連線池從不對請求進行排隊。HTTP / 2請求立即被多路複用。
  • 最大請求數：在任何給定時間，群集中所有主機可能未完成的最大請求數。實際上，這主要用於HTTP / 2，因為HTTP / 1通常每個連線有一個請求。
  • 最大活動重試次數：在任何給定時間，群集中所有主機可以執行的最大重試次數。通常，我們建議積極地進行斷路重試，以便允許重試故障，但整體重試量不會爆炸並導致大規模級聯故障。此設定可防止  重試放大。


在Lyft，我們專注於兩種管理服務網格中併發性的機制：
  1. 限制入口層的併發連線數。鑑於Lyft的每項服務都執行一個特使邊車來管理進入服務的入口請求（入口），我們可以配置邊車對應用程式的併發連線數，從而限制入口併發進入應用程式。我們提供合理的值作為預設值，但鼓勵服務所有者分析其併發模式並收緊設定。
  2. 限制出口層的併發請求數。執行邊車來管理來自服務的出口流量的另一個好處是，我們可以管理從服務（出口）到Lyft的任何其他服務的傳出併發請求。這意味著“位置”服務的所有者可以有選擇地配置他們想要支援Lyft的每個其他服務的併發級別，例如，他們可以決定並配置“遊樂設施”服務可以向“位置”發出100個併發請求“，但”使用者“服務只能向”位置“發出50個併發請求。


對Lyft的每個服務的出口和入口執行併發限制的一個有趣結果是，更容易跟蹤不需要的行為。如上所述，所見的常見故障情形是突發性，出口和入口的併發限制使得透過檢視請求路徑中併發溢位的位置，可以輕鬆查明整個系統的突發行為。

缺陷
具體引數值很難選擇；整個服務網路中每天有數百個部署。對服務及其依賴項的任何更改都可以更改資源和負載配置檔案。一旦選擇了某個引數值，由於這些變化又將過時。

併發限制很容易實施，因為Envoy存在於網路的每一次呼叫中，透過Envoy可以容易控制併發呼叫；但是速率限制很難確定，因為它需要服務所有者完全理解系統的所有約束。此外，由於網路拓撲結構的不斷髮展和彈性，當今的網際網路規模公司，尤其是那些處於成長階段的公司迅速增長。 

Netflix在這個問題上投入了大量資金，最近  開源了一個庫，  用於衡量或估算網路中每個點的併發限制。更重要的是，隨著系統規模和命中而限制每個節點，[系統中]每個節點將調整並強制執行其區域性極限值檢視。他們透過將系統的併發約束等同於TCP擁塞視窗，借用了常見的TCP擁塞控制演算法。 

Envoy的設計原則之一包括豐富且功能強大的過濾器堆疊，以提供可擴充套件性。Envoy具有L3 / L4（TCP級別）和L7（HTTP級別）過濾器堆疊。可以編寫HTTP過濾器以對HTTP級別訊息進行操作。HTTP過濾器可以停止並繼續迭代到後續過濾器。這種豐富的過濾器架構允許複雜的場景，例如執行狀況檢查處理，呼叫速率限制服務，緩衝，路由，生成應用程式流量統計資料，如DynamoDB等。  

在接下來的幾個月裡，Lyft將與Netflix的併發限制庫背後的團隊合作，將基於其庫的系統帶入特使L7過濾器。這意味著在Lyft - 以及使用Envoy的任何其他公司 - 我們將遷移到自動化系統，我們的服務工程師不必靜態配置併發限制。這意味著，例如，如果由於意外情況導致服務減速，則自適應限制系統可以自動抑制檢測到的限制，從而防止由於不可預見的減速而導致的故障  。一般而言，自適應系統消除了我們過去遇到的兩個問題：確定適當的限制是非直觀的，並且靜態限制無法面對彈性分散式系統的快速增長。

banq: Netflix將重點放在了Envoy整合，這些都足以替代Zuul，因此Zuul 2.0還需要嗎？






 

相關文章