大數據中流控降級的示例分析

這篇文章主要為大家展示了“大數據中流控降級的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“大數據中流控降級的示例分析”這篇文章吧。

流控降級最佳實踐

• 生產環境經常會出現以下不穩定的情況：

• 大促時瞬間洪峰流量導致系統超出最大負載，load 飆高，系統崩潰導致用戶無法下單

• “黑馬”熱點商品擊穿緩存，DB 被打垮，擠占正常流量

• 調用端被不穩定服務拖垮，線程池被占滿，導致整個調用鏈路卡死

這些不穩定的場景可能會導致嚴重后果。大家可能想問：如何做到均勻平滑的用戶訪問？如何預防這些不穩定因素帶來的影響？這時候我們就要請出微服務穩定性的法寶 —— 流控降級。流量控制和熔斷降級是保障微服務穩定性重要的一環。本文將會幫助讀者理解流控降級的重要性，并介紹流控降級的各種最佳實踐場景。如有遺漏或錯誤，歡迎補充指正。

什么是流控降級

流控，即流量控制。流量控制在網絡傳輸中是一個常用的概念，它用于調整網絡包的發送數據。然而，從系統穩定性角度考慮，在處理請求的速度上，也有非常多的講究。任意時間到來的請求往往是隨機不可控的，而系統的處理能力是有限的。我們需要根據系統的處理能力對流量進行控制，在保證系統吞吐量比較高的同時又不會把系統打垮。

熔斷降級則是在服務出現不穩定因素的時候暫時切斷服務的調用，等待一段時間再進行嘗試。一方面防止給不穩定服務“雪上加霜”，另一方面保護服務的調用方不被拖垮。這其實就是熔斷器（Circuit Breaker）的思想：

<img src="https://user-images.githubusercontent.com/9434884/62473394-3bc10a00-b7d3-11e9-8998-68d9cf3e01f2.png" alt="circuit-breaker" width="50%"/>

為什么需要流控降級

流量是非常隨機性的、不可預測的。前一秒可能還風平浪靜，后一秒可能就出現流量洪峰了（例如雙十一零點的場景）。然而我們系統的容量總是有限的，如果突然而來的流量超過了系統的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最后導致系統崩潰。因此，我們需要針對這種突發的流量來進行限制，在盡可能處理請求的同時來保障服務不被打垮。

一個服務常常會調用別的模塊，可能是另外的一個遠程服務、數據庫，或者第三方 API 等。例如，支付的時候，可能需要遠程調用銀聯提供的 API；查詢某個商品的價格，可能需要進行數據庫查詢。然而，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變長，那么調用服務的方法的響應時間也會變長，線程會產生堆積，最終可能耗盡業務自身的線程池，服務本身也變得不可用。

現代微服務架構都是分布式的，由非常多的服務組成。不同服務之間相互調用，組成復雜的調用鏈路。以上的問題在鏈路調用中會產生放大的效果。復雜鏈路上的某一環不穩定，就可能會層層級聯，最終導致整個鏈路都不可用。因此我們需要對不穩定的服務進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素導致整體的雪崩。

那么是不是服務的量級很小就不用進行限流防護了呢？是不是微服務的架構比較簡單就不用引入熔斷保護機制了呢？其實，這與請求的量級、架構的復雜程度無關。很多時候，可能正是一個非常邊緣的服務出現故障而導致整體業務受影響，造成巨大損失。我們需要具有面向失敗設計的意識，在平時就做好容量規劃和強弱依賴的梳理，合理地配置流控降級規則，做好事前防護，而不是在線上出現問題以后再進行補救。

流控降級最佳實踐

下面我們會介紹幾個常見場景下的流控降級最佳實踐，幫助大家合理地利用流控降級來保障服務的穩定性。

服務提供方流控

在服務提供方（Service Provider）的場景下，我們需要保護服務提供方自身不被流量洪峰打垮。我們通常根據服務提供方的服務能力進行流量控制，或針對特定的服務調用方進行限制。

為了保護服務提供方不被激增的流量拖垮影響穩定性，我們可以配置 QPS 模式的限流，當每秒的請求量超過設定的閾值時，會自動拒絕多余的請求。

根據調用方的需求來分配服務提供方的處理能力也是常見的限流方式。例如，有兩個服務消費者 A 和 B 都向服務提供方發起調用請求，我們希望優先處理消費者 A 的請求，而只對來自服務 B 的請求進行限流。

服務調用方隔離/熔斷

除了根據服務能力進行流量控制以外，還有一種常見的場景，即對依賴方進行隔離和降級。前面提到過，分布式系統中難免會有不穩定的服務節點（請求慢或請求處理失敗）。如果調用端不引入自我保護的機制，那么有可能會被依賴的不穩定服務拖垮，導致自身也不可用。分布式系統中服務間的依賴關系是非常復雜的，一個服務不可用可能會導致上游數個服務不可用，最終會導致雪崩。

對這種情況，我們要在服務調用端（Service Consumer）對依賴的不穩定服務進行隔離和熔斷。

服務隔離一般有兩種方式：

• 線程池隔離：即針對不同的業務調用分別創建不同的線程池，不同服務調用都發生在不同的線程池中，在線程池排隊、超時等阻塞情況時可以快速“掐斷”。線程池隔離的好處是隔離度比較高，可以針對某個服務調用的線程池去進行處理而不影響其它資源，但是代價就是可能會創建比較多的線程池，線程上下文切換的 overhead 比較大，而且線程池執行會導致一些基于 ThreadLocal 的場景出現問題（如 Spring 事務）。Hystrix 主推線程池隔離模式。

• 信號量隔離：即限制某個服務調用的并發量，而不是為不同服務顯式創建線程池。這樣的隔離比較輕量，overhead 比較小，但是效果不錯，并且可以結合實時的響應時間對慢調用進行熔斷，從而保障自身不被不穩定服務調用所拖垮。Sentinel 主推信號量隔離模式。

當服務依賴于多個下游服務，而某個下游服務調用非常慢或經常出錯時，會嚴重影響當前服務的調用。我們可以借助熔斷器的思想，當異常比率或業務調用的平均時長超過某個閾值后將調用進行熔斷，直到一段時間過后再嘗試恢復。熔斷期間我們可以提供默認的處理邏輯（fallback），熔斷期間的調用都會返回 fallback 的結果，而不會再去嘗試本已非常不穩定的服務。

需要注意的是，即使服務調用方引入了熔斷降級機制，我們還是需要在 HTTP 或 RPC 客戶端配置請求超時時間，來做一個兜底的防護。

冷系統預熱

當系統長期處于低水位的情況下，流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。我們可以利用 Guava 的 SmoothRateLimiter 或 Sentinel 的 Warm Up 流控模式，控制通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，而不是在一瞬間全部放行。這樣可以給冷系統一個預熱的時間，避免冷系統被壓垮。

削峰填谷

請求的到來往往是沒有規律的。很多時候流量可能都集中于某幾秒的時間，而在接下來的一段時間內都沒有很多請求。例如，某應用的處理能力是每秒 10 個請求。在某一秒，突然到來了 30 個請求，而接下來兩秒，都沒有請求到達。在這種情況下，如果直接拒絕 20 個請求，應用在接下來的兩秒就會空閑。所以，需要把請求突刺均攤到一段時間內，讓系統負載保持在請求處理水位之內，同時盡可能地處理更多請求，從而起到“削峰填谷”的效果。常見的場景為消息隊列消費端處理消息的場景：

上圖中，紅色的部分代表超出消息處理能力的部分。觀察得出，消息突刺往往都是瞬時的、不規律的，其后一段時間系統往往都會有空閑資源。把紅色的那部分消息平攤到后面空閑時去處理，這樣既可以保證系統負載處在一個穩定的水位，又可以盡可能地處理更多消息。我們可以利用 Leaky Bucket 算法 結合請求排隊來讓消息勻速消費，允許一部分消息排隊等待處理，超出最大等待時長的消息直接拒絕處理。

Sentinel 提供了勻速排隊模式，可以很好地適用這種場景。

網關流控

網關作為流量的入口，會接收到大量的用戶請求。我們可以在網關層面，從流量入口處攔截激增的流量，防止下游服務被沖垮。網關流控常見的場景：

• 限制某個 API 的調用頻率，比如對外提供的 OpenAPI 每小時總調用量不超過 30000 次。

• 針對每個請求的客戶端 IP、Header 或者 URL 參數進行流控，比如限制每個 IP 的調用頻次來進行防刷。

• 結合集群限流來限制某個下游服務的總調用量，這樣多余的流量就直接在網關層被拒絕了，而不會再打到應用層。

對于使用了 Nginx 的場景，我們可以借助 Nginx 自帶的 ngx_http_limit_req_module 模塊來對經過 Nginx 的請求進行限制；對于常用的 Java API Gateway，如 Spring Cloud Gateway 和 Zuul，我們可以利用 Sentinel 的網關流量控制特性，配置網關流控規則來針對每個不同路由、不同的請求屬性（如 HTTP Header、URL 參數等）進行流量控制。

流控降級規則的配置

需要注意的是，限流降級的配置是需要結合容量規劃、依賴梳理來做的。我們可以借助 JMeter 或 阿里云 PTS 等壓測工具對我們的服務進行全鏈路壓測，了解每個服務的最大承受能力，來確定流控和熔斷降級的閾值。同時，業務系統需要具備實時監控的能力，以便實時地根據流量情況做出相應的限流降級策略調整。

以上是“大數據中流控降級的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！