這篇文章主要為大家展示了“大數(shù)據(jù)中流控降級的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“大數(shù)據(jù)中流控降級的示例分析”這篇文章吧。
創(chuàng)新互聯(lián)建站堅信：善待客戶，將會成為終身客戶。我們能堅持多年，是因為我們一直可值得信賴。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。10多年網(wǎng)站建設(shè)經(jīng)驗創(chuàng)新互聯(lián)建站是成都老牌網(wǎng)站營銷服務(wù)商,為您提供成都網(wǎng)站設(shè)計、網(wǎng)站制作、網(wǎng)站設(shè)計、H5開發(fā)、網(wǎng)站制作、品牌網(wǎng)站制作、小程序定制開發(fā)服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。
生產(chǎn)環(huán)境經(jīng)常會出現(xiàn)以下不穩(wěn)定的情況：
大促時瞬間洪峰流量導(dǎo)致系統(tǒng)超出最大負載，load 飆高，系統(tǒng)崩潰導(dǎo)致用戶無法下單
“黑馬”熱點商品擊穿緩存，DB 被打垮，擠占正常流量
調(diào)用端被不穩(wěn)定服務(wù)拖垮，線程池被占滿，導(dǎo)致整個調(diào)用鏈路卡死
這些不穩(wěn)定的場景可能會導(dǎo)致嚴(yán)重后果。大家可能想問：如何做到均勻平滑的用戶訪問？如何預(yù)防這些不穩(wěn)定因素帶來的影響？這時候我們就要請出微服務(wù)穩(wěn)定性的法寶 —— 流控降級。流量控制和熔斷降級是保障微服務(wù)穩(wěn)定性重要的一環(huán)。本文將會幫助讀者理解流控降級的重要性，并介紹流控降級的各種最佳實踐場景。如有遺漏或錯誤，歡迎補充指正。
流控，即流量控制。流量控制在網(wǎng)絡(luò)傳輸中是一個常用的概念，它用于調(diào)整網(wǎng)絡(luò)包的發(fā)送數(shù)據(jù)。然而，從系統(tǒng)穩(wěn)定性角度考慮，在處理請求的速度上，也有非常多的講究。任意時間到來的請求往往是隨機不可控的，而系統(tǒng)的處理能力是有限的。我們需要根據(jù)系統(tǒng)的處理能力對流量進行控制，在保證系統(tǒng)吞吐量比較高的同時又不會把系統(tǒng)打垮。
熔斷降級則是在服務(wù)出現(xiàn)不穩(wěn)定因素的時候暫時切斷服務(wù)的調(diào)用，等待一段時間再進行嘗試。一方面防止給不穩(wěn)定服務(wù)“雪上加霜”，另一方面保護服務(wù)的調(diào)用方不被拖垮。這其實就是熔斷器（Circuit Breaker）的思想：
流量是非常隨機性的、不可預(yù)測的。前一秒可能還風(fēng)平浪靜，后一秒可能就出現(xiàn)流量洪峰了（例如雙十一零點的場景）。然而我們系統(tǒng)的容量總是有限的，如果突然而來的流量超過了系統(tǒng)的承受能力，就可能會導(dǎo)致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最后導(dǎo)致系統(tǒng)崩潰。因此，我們需要針對這種突發(fā)的流量來進行限制，在盡可能處理請求的同時來保障服務(wù)不被打垮。
一個服務(wù)常常會調(diào)用別的模塊，可能是另外的一個遠程服務(wù)、數(shù)據(jù)庫，或者第三方 API 等。例如，支付的時候，可能需要遠程調(diào)用銀聯(lián)提供的 API；查詢某個商品的價格，可能需要進行數(shù)據(jù)庫查詢。然而，這個被依賴服務(wù)的穩(wěn)定性是不能保證的。如果依賴的服務(wù)出現(xiàn)了不穩(wěn)定的情況，請求的響應(yīng)時間變長，那么調(diào)用服務(wù)的方法的響應(yīng)時間也會變長，線程會產(chǎn)生堆積，最終可能耗盡業(yè)務(wù)自身的線程池，服務(wù)本身也變得不可用。
現(xiàn)代微服務(wù)架構(gòu)都是分布式的，由非常多的服務(wù)組成。不同服務(wù)之間相互調(diào)用，組成復(fù)雜的調(diào)用鏈路。以上的問題在鏈路調(diào)用中會產(chǎn)生放大的效果。復(fù)雜鏈路上的某一環(huán)不穩(wěn)定，就可能會層層級聯(lián)，最終導(dǎo)致整個鏈路都不可用。因此我們需要對不穩(wěn)定的服務(wù)進行熔斷降級，暫時切斷不穩(wěn)定調(diào)用，避免局部不穩(wěn)定因素導(dǎo)致整體的雪崩。
那么是不是服務(wù)的量級很小就不用進行限流防護了呢？是不是微服務(wù)的架構(gòu)比較簡單就不用引入熔斷保護機制了呢？其實，這與請求的量級、架構(gòu)的復(fù)雜程度無關(guān)。很多時候，可能正是一個非常邊緣的服務(wù)出現(xiàn)故障而導(dǎo)致整體業(yè)務(wù)受影響，造成巨大損失。我們需要具有面向失敗設(shè)計的意識，在平時就做好容量規(guī)劃和強弱依賴的梳理，合理地配置流控降級規(guī)則，做好事前防護，而不是在線上出現(xiàn)問題以后再進行補救。
下面我們會介紹幾個常見場景下的流控降級最佳實踐，幫助大家合理地利用流控降級來保障服務(wù)的穩(wěn)定性。
在服務(wù)提供方（Service Provider）的場景下，我們需要保護服務(wù)提供方自身不被流量洪峰打垮。我們通常根據(jù)服務(wù)提供方的服務(wù)能力進行流量控制，或針對特定的服務(wù)調(diào)用方進行限制。
為了保護服務(wù)提供方不被激增的流量拖垮影響穩(wěn)定性，我們可以配置 QPS 模式的限流，當(dāng)每秒的請求量超過設(shè)定的閾值時，會自動拒絕多余的請求。
根據(jù)調(diào)用方的需求來分配服務(wù)提供方的處理能力也是常見的限流方式。例如，有兩個服務(wù)消費者 A 和 B 都向服務(wù)提供方發(fā)起調(diào)用請求，我們希望優(yōu)先處理消費者 A 的請求，而只對來自服務(wù) B 的請求進行限流。
除了根據(jù)服務(wù)能力進行流量控制以外，還有一種常見的場景，即對依賴方進行隔離和降級。前面提到過，分布式系統(tǒng)中難免會有不穩(wěn)定的服務(wù)節(jié)點（請求慢或請求處理失敗）。如果調(diào)用端不引入自我保護的機制，那么有可能會被依賴的不穩(wěn)定服務(wù)拖垮，導(dǎo)致自身也不可用。分布式系統(tǒng)中服務(wù)間的依賴關(guān)系是非常復(fù)雜的，一個服務(wù)不可用可能會導(dǎo)致上游數(shù)個服務(wù)不可用，最終會導(dǎo)致雪崩。
對這種情況，我們要在服務(wù)調(diào)用端（Service Consumer）對依賴的不穩(wěn)定服務(wù)進行隔離和熔斷。
服務(wù)隔離一般有兩種方式：
線程池隔離：即針對不同的業(yè)務(wù)調(diào)用分別創(chuàng)建不同的線程池，不同服務(wù)調(diào)用都發(fā)生在不同的線程池中，在線程池排隊、超時等阻塞情況時可以快速“掐斷”。線程池隔離的好處是隔離度比較高，可以針對某個服務(wù)調(diào)用的線程池去進行處理而不影響其它資源，但是代價就是可能會創(chuàng)建比較多的線程池，線程上下文切換的 overhead 比較大，而且線程池執(zhí)行會導(dǎo)致一些基于 ThreadLocal 的場景出現(xiàn)問題（如 Spring 事務(wù)）。Hystrix 主推線程池隔離模式。
信號量隔離：即限制某個服務(wù)調(diào)用的并發(fā)量，而不是為不同服務(wù)顯式創(chuàng)建線程池。這樣的隔離比較輕量，overhead 比較小，但是效果不錯，并且可以結(jié)合實時的響應(yīng)時間對慢調(diào)用進行熔斷，從而保障自身不被不穩(wěn)定服務(wù)調(diào)用所拖垮。Sentinel 主推信號量隔離模式。
當(dāng)服務(wù)依賴于多個下游服務(wù)，而某個下游服務(wù)調(diào)用非常慢或經(jīng)常出錯時，會嚴(yán)重影響當(dāng)前服務(wù)的調(diào)用。我們可以借助熔斷器的思想，當(dāng)異常比率或業(yè)務(wù)調(diào)用的平均時長超過某個閾值后將調(diào)用進行熔斷，直到一段時間過后再嘗試恢復(fù)。熔斷期間我們可以提供默認的處理邏輯（fallback），熔斷期間的調(diào)用都會返回 fallback 的結(jié)果，而不會再去嘗試本已非常不穩(wěn)定的服務(wù)。
需要注意的是，即使服務(wù)調(diào)用方引入了熔斷降級機制，我們還是需要在 HTTP 或 RPC 客戶端配置請求超時時間，來做一個兜底的防護。
當(dāng)系統(tǒng)長期處于低水位的情況下，流量突然增加時，直接把系統(tǒng)拉升到高水位可能瞬間把系統(tǒng)壓垮。我們可以利用 Guava 的 SmoothRateLimiter 或 Sentinel 的 Warm Up 流控模式，控制通過的流量緩慢增加，在一定時間內(nèi)逐漸增加到閾值上限，而不是在一瞬間全部放行。這樣可以給冷系統(tǒng)一個預(yù)熱的時間，避免冷系統(tǒng)被壓垮。
請求的到來往往是沒有規(guī)律的。很多時候流量可能都集中于某幾秒的時間，而在接下來的一段時間內(nèi)都沒有很多請求。例如，某應(yīng)用的處理能力是每秒 10 個請求。在某一秒，突然到來了 30 個請求，而接下來兩秒，都沒有請求到達。在這種情況下，如果直接拒絕 20 個請求，應(yīng)用在接下來的兩秒就會空閑。所以，需要把請求突刺均攤到一段時間內(nèi)，讓系統(tǒng)負載保持在請求處理水位之內(nèi)，同時盡可能地處理更多請求，從而起到“削峰填谷”的效果。常見的場景為消息隊列消費端處理消息的場景：
上圖中，紅色的部分代表超出消息處理能力的部分。觀察得出，消息突刺往往都是瞬時的、不規(guī)律的，其后一段時間系統(tǒng)往往都會有空閑資源。把紅色的那部分消息平攤到后面空閑時去處理，這樣既可以保證系統(tǒng)負載處在一個穩(wěn)定的水位，又可以盡可能地處理更多消息。我們可以利用 Leaky Bucket 算法 結(jié)合請求排隊來讓消息勻速消費，允許一部分消息排隊等待處理，超出最大等待時長的消息直接拒絕處理。
Sentinel 提供了勻速排隊模式，可以很好地適用這種場景。
網(wǎng)關(guān)作為流量的入口，會接收到大量的用戶請求。我們可以在網(wǎng)關(guān)層面，從流量入口處攔截激增的流量，防止下游服務(wù)被沖垮。網(wǎng)關(guān)流控常見的場景：
限制某個 API 的調(diào)用頻率，比如對外提供的 OpenAPI 每小時總調(diào)用量不超過 30000 次。
針對每個請求的客戶端 IP、Header 或者 URL 參數(shù)進行流控，比如限制每個 IP 的調(diào)用頻次來進行防刷。
結(jié)合集群限流來限制某個下游服務(wù)的總調(diào)用量，這樣多余的流量就直接在網(wǎng)關(guān)層被拒絕了，而不會再打到應(yīng)用層。
對于使用了 Nginx 的場景，我們可以借助 Nginx 自帶的 ngx_http_limit_req_module 模塊來對經(jīng)過 Nginx 的請求進行限制；對于常用的 Java API Gateway，如 Spring Cloud Gateway 和 Zuul，我們可以利用 Sentinel 的網(wǎng)關(guān)流量控制特性，配置網(wǎng)關(guān)流控規(guī)則來針對每個不同路由、不同的請求屬性（如 HTTP Header、URL 參數(shù)等）進行流量控制。
需要注意的是，限流降級的配置是需要結(jié)合容量規(guī)劃、依賴梳理來做的。我們可以借助 JMeter 或 阿里云 PTS 等壓測工具對我們的服務(wù)進行全鏈路壓測，了解每個服務(wù)的最大承受能力，來確定流控和熔斷降級的閾值。同時，業(yè)務(wù)系統(tǒng)需要具備實時監(jiān)控的能力，以便實時地根據(jù)流量情況做出相應(yīng)的限流降級策略調(diào)整。
以上是“大數(shù)據(jù)中流控降級的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
