本文源碼:GitHub·點這裡 || GitEE·點這裡 一、流量控制 1、基本概念 流量控制的核心作用是限制流出某一網路的某一連接的流量與突發,使這類報文以比較均勻的速度流動發送,達到保護系統相對穩定的目的。通常是將請求放入緩衝區或隊列內,然後基於特定策略處理請求,勻速或者批量處理,該過程也稱流量 ...
本文源碼:GitHub·點這裡 || GitEE·點這裡
一、流量控制
1、基本概念
流量控制的核心作用是限制流出某一網路的某一連接的流量與突發,使這類報文以比較均勻的速度流動發送,達到保護系統相對穩定的目的。通常是將請求放入緩衝區或隊列內,然後基於特定策略處理請求,勻速或者批量處理,該過程也稱流量整形。
流量控制的核心演算法有以下兩種:漏桶演算法和令牌桶演算法。
2、漏桶演算法
基礎描述
漏桶演算法是流量整形或速率限制時經常使用的一種演算法,它的主要目的是控制數據註入到網路的速率,平滑網路上的突發流量。漏桶演算法提供了一種機制,通過它,突發流量可以被整形以便為網路提供一個穩定的流量。
漏桶演算法基本思路:請求(水流)先進入到容器(漏桶)里,漏桶以一定的速度出水,這裡就是指流量流出的策略,當流量流入速度過大容器無法承接就會直接溢出,通過該過程限制數據的傳輸速率。
核心要素
通過上述流程,不難發現漏桶演算法涉及下麵幾個要素:
容器容量
容器的大小直接決定能承接流量的多少,容器一但接近飽和,要麼溢出,要麼加快流速;
流出速度
流量流出的速度取決於服務的請求處理能力,介面支撐的併發越高,流速就可以越大;
時間控制
基於時間記錄,判斷流量流出速度,控制勻速模式,
註意:需要一個基本的判定策略,漏桶演算法在系統能承接當前併發流量時,不需要啟用。
3、令牌桶演算法
基礎描述
令牌桶可自行以恆定的速率源源不斷地產生令牌。如果令牌不被消耗,或者被消耗的速度小於產生的速度,令牌就會不斷地增多,直到把桶填滿。後面再產生的令牌就會從桶中溢出。
令牌桶演算法雖然根本目的也是控制流量速度,但是當令牌桶內的令牌足夠多時,則允許流量階段性的併發。傳送到令牌桶的數據包需要消耗令牌。不同大小的數據包,消耗的令牌數量不一樣。
核心要素
令牌桶
存放按照特定的速率生成的令牌,以此控制流量速度。
匹配規則
這裡的匹配規則更多是服務於分散式系統,例如服務A是系統的核心交易,當出現併發時,基於令牌桶最匹配規則,只允許交易請求通過,例如:常見雙十一期間,各大電商平臺提示,為保證核心交易,邊緣服務的數據延遲或暫停等。
註意:令牌桶演算法和漏桶演算法的目的雖然相同,但是實現策略是相反的,不過都存在一個問題,為保證大部分請求流量成功,會犧牲小部分請求。
二、限流組件
1、Nginx代理組件
Nginx反向代理實際運行方式是指以代理伺服器來接收客戶端連接請求,然後將請求轉發給內部網路上的伺服器,並將從伺服器上得到的結果返回給客戶端,此時代理伺服器對外就表現為一個伺服器。
流量限制是Nginx作為代理服務中一個非常實用的功能,通過配置方式來限制用戶在給定時間內HTTP請求的數量,兩個主要的配置指令limit_req_zone
和limit_req
,以此保護高併發下系統的穩定。
2、CDN邊緣節點
CDN邊緣節點,準確的說並不是用來處理流量限制的,而是存放靜態頁面。內容緩存為CDN網路節點,位於用戶接入點,是面向最終用戶的內容提供設備,可緩存靜態Web內容和流媒體內容,實現內容的邊緣傳播和存儲,以便用戶的就近訪問,這樣避免用戶大量刷新數據伺服器,節省骨幹網帶寬,減少帶寬需求量。
在高併發場景下,尤其是倒計時搶購類似業務,在活動開始前後用戶會產生大量刷新頁面的操作,基於CDN節點,這些請求不會下沉到數據的服務介面上。也可以基於頁面做一些請求攔截,比如點擊頁面單位時間內只放行一定量的請求,以此也可以實現一個限流控制。
三、熔斷器組件
所謂熔斷器機制,即類似電流的保險器,當然電壓過高會自動跳閘,從而保護電路系統。微服務架構中服務保護也是這個策略,當服務被判斷異常,會從服務列表斷開,等待恢覆在重新連接。服務熔斷降級的策略實現有如下幾個常用的組件。
1、Hystrix組件
基礎簡介
Hystrix當前處於維護模式,即不再更新,作為SpringCloud微服務組件中,最原生的一個熔斷組件,很多思路還是有必要瞭解一下。例如:服務熔斷,阻止故障的連鎖反應,快速失敗並迅速恢復,服務降級等。
某個微服務發生故障時,要快速切斷服務,提示用戶,後續請求,不調用該服務,直接返回,釋放資源,這就是服務熔斷。
熔斷器策略
伺服器高併發下,壓力劇增的時候,根據當業務情況以及流量,對一些服務和頁面有策略的降級(可以理解為關閉不必要的服務),以此緩解伺服器資源的壓力以保障核心任務的正常運行。熔斷生效後,會在指定的時間後調用請求來測試依賴是否恢復,依賴的應用恢復後關閉熔斷。
基本流程:
首先判斷服務熔斷器開關狀態,服務如果未熔斷則放行請求;如果服務處於熔斷中則直接返回。
每次調用都執行兩個函數markSuccess(duration)和markFailure(duration) 來統計在一定的時間段內的調用是成功和失敗次數。
基於上述的成功和失敗次數的計算策略,來判斷是否應該打開熔斷器,如果錯誤率高於一定的閾值,就會觸發熔斷機制。
熔斷器有一個生命周期,周期過後熔斷器器進入半開狀態,允許放行一個試探請求;否則,不允許放行。
2、Sentinel組件
基礎簡介
基於微服務的模式,服務和服務之間的穩定性變得越來越重要。Sentinel以流量為切入點,從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。
Sentinel可以針對不同的調用關係,以不同的運行指標(如QPS、併發調用數、系統負載等)為基準,收集資源的路徑,並將這些資源的調用路徑以樹狀結構存儲起來,用於根據調用路徑對資源進行流量控制。
流量整形策略
直接拒絕模式是預設的流量控制方式,即請求超出任意規則的閾值後,新的請求就會被立即拒絕。
啟動預熱模式:當流量激增的時候,控制流量通過的速率,讓通過的流量緩慢增加,在一定時間內逐漸增加到閾值上限,給冷系統一個預熱的時間,避免冷系統被壓垮。
勻速排隊方式會嚴格控制請求通過的間隔時間,也即是讓請求以均勻的速度通過,對應的是漏桶演算法。
熔斷策略
Sentinel本質上是基於熔斷器模式,支持基於異常比率的熔斷降級,在調用達到一定量級並且失敗比率達到設定的閾值時自動進行熔斷,此時所有對該資源的調用都會被阻塞,直到過了指定的時間視窗後才啟發性地恢復。
四、源代碼地址
GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud
推薦閱讀:微服務架構系列
序號 | 標題 |
---|---|
01 | 微服務架構:項目技術選型簡介,架構圖解說明 |
02 | 微服務架構:業務架構設計,系統分層管理 |
03 | 微服務架構:資料庫選型簡介,業務數據規劃設計 |
04 | 微服務架構:中間件集成,公共服務封裝 |
05 | 微服務架構:SpringCloud 基礎組件應用設計 |
06 | 微服務架構:通過業務、應用、技術、存儲,聊聊架構 |
07 | 微服務技術棧:常見註冊中心組件,對比分析 |