微服務技術棧：流量整形算法，服務熔斷與降級

本文源碼：GitHub·點這裏 || GitEE·點這裏

1、流量控制

一、基本概念

流量控制的核心做用是限制流出某一網絡的某一鏈接的流量與突發，使這類報文以比較均勻的速度流動發送，達到保護系統相對穩定的目的。一般是將請求放入緩衝區或隊列內，而後基於特定策略處理請求，勻速或者批量處理，該過程也稱流量整形。

流量控制的核心算法有如下兩種：漏桶算法和令牌桶算法。

二、漏桶算法

基礎描述

漏桶算法是流量整形或速率限制時常用的一種算法，它的主要目的是控制數據注入到網絡的速率，平滑網絡上的突發流量。漏桶算法提供了一種機制，經過它，突發流量能夠被整形以便爲網絡提供一個穩定的流量。

漏桶算法基本思路：請求（水流）先進入到容器（漏桶）裏，漏桶以必定的速度出水，這裏就是指流量流出的策略，當流量流入速度過大容器沒法承接就會直接溢出，經過該過程限制數據的傳輸速率。

核心要素

經過上述流程，不難發現漏桶算法涉及下面幾個要素：

容器容量

容器的大小直接決定能承接流量的多少，容器一但接近飽和，要麼溢出，要麼加快流速；

流出速度

流量流出的速度取決於服務的請求處理能力，接口支撐的併發越高，流速就能夠越大；

時間控制

基於時間記錄，判斷流量流出速度，控制勻速模式，

注意：須要一個基本的斷定策略，漏桶算法在系統能承接當前併發流量時，不須要啓用。

三、令牌桶算法

基礎描述

令牌桶可自行以恆定的速率源源不斷地產生令牌。若是令牌不被消耗，或者被消耗的速度小於產生的速度，令牌就會不斷地增多，直到把桶填滿。後面再產生的令牌就會從桶中溢出。

令牌桶算法雖然根本目的也是控制流量速度，可是當令牌桶內的令牌足夠多時，則容許流量階段性的併發。傳送到令牌桶的數據包須要消耗令牌。不一樣大小的數據包，消耗的令牌數量不同。

核心要素

令牌桶

存放按照特定的速率生成的令牌，以此控制流量速度。

匹配規則

這裏的匹配規則更可能是服務於分佈式系統，例如服務A是系統的核心交易，當出現併發時，基於令牌桶最匹配規則，只容許交易請求經過，例如：常見雙十一期間，各大電商平臺提示，爲保證核心交易，邊緣服務的數據延遲或暫停等。

注意：令牌桶算法和漏桶算法的目的雖然相同，可是實現策略是相反的，不過都存在一個問題，爲保證大部分請求流量成功，會犧牲小部分請求。

2、限流組件

一、Nginx代理組件

Nginx反向代理實際運行方式是指以代理服務器來接收客戶端鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給客戶端，此時代理服務器對外就表現爲一個服務器。

流量限制是Nginx做爲代理服務中一個很是實用的功能，經過配置方式來限制用戶在給定時間內HTTP請求的數量，兩個主要的配置指令limit_req_zone和limit_req，以此保護高併發下系統的穩定。

二、CDN邊緣節點

CDN邊緣節點，準確的說並非用來處理流量限制的，而是存放靜態頁面。內容緩存爲CDN網絡節點，位於用戶接入點，是面向最終用戶的內容提供設備，可緩存靜態Web內容和流媒體內容，實現內容的邊緣傳播和存儲，以便用戶的就近訪問，這樣避免用戶大量刷新數據服務器，節省骨幹網帶寬，減小帶寬需求量。

在高併發場景下，尤爲是倒計時搶購相似業務，在活動開始先後用戶會產生大量刷新頁面的操做，基於CDN節點，這些請求不會下沉到數據的服務接口上。也能夠基於頁面作一些請求攔截，好比點擊頁面單位時間內只放行必定量的請求，以此也能夠實現一個限流控制。

3、熔斷器組件

所謂熔斷器機制，即相似電流的保險器，固然電壓太高會自動跳閘，從而保護電路系統。微服務架構中服務保護也是這個策略，當服務被判斷異常，會從服務列表斷開，等待恢復在從新鏈接。服務熔斷降級的策略實現有以下幾個經常使用的組件。

一、Hystrix組件

基礎簡介

Hystrix當前處於維護模式，即再也不更新，做爲SpringCloud微服務組件中，最原生的一個熔斷組件，不少思路仍是有必要了解一下。例如：服務熔斷，阻止故障的連鎖反應，快速失敗並迅速恢復，服務降級等。

某個微服務發生故障時，要快速切斷服務，提示用戶，後續請求，不調用該服務，直接返回，釋放資源，這就是服務熔斷。

熔斷器策略

服務器高併發下，壓力劇增的時候,根據當業務狀況以及流量，對一些服務和頁面有策略的降級(能夠理解爲關閉沒必要要的服務)，以此緩解服務器資源的壓力以保障核心任務的正常運行。熔斷生效後，會在指定的時間後調用請求來測試依賴是否恢復，依賴的應用恢復後關閉熔斷。

基本流程：

首先判斷服務熔斷器開關狀態，服務若是未熔斷則放行請求；若是服務處於熔斷中則直接返回。

每次調用都執行兩個函數markSuccess(duration)和markFailure(duration) 來統計在必定的時間段內的調用是成功和失敗次數。

基於上述的成功和失敗次數的計算策略，來判斷是否應該打開熔斷器，若是錯誤率高於必定的閾值，就會觸發熔斷機制。

熔斷器有一個生命週期，週期事後熔斷器器進入半開狀態，容許放行一個試探請求；不然，不容許放行。

二、Sentinel組件

基礎簡介

基於微服務的模式，服務和服務之間的穩定性變得愈來愈重要。Sentinel以流量爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

Sentinel能夠針對不一樣的調用關係，以不一樣的運行指標（如QPS、併發調用數、系統負載等）爲基準，收集資源的路徑，並將這些資源的調用路徑以樹狀結構存儲起來，用於根據調用路徑對資源進行流量控制。

流量整形策略

直接拒絕模式是默認的流量控制方式，即請求超出任意規則的閾值後，新的請求就會被當即拒絕。

啓動預熱模式：當流量激增的時候，控制流量經過的速率，讓經過的流量緩慢增長，在必定時間內逐漸增長到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

勻速排隊方式會嚴格控制請求經過的間隔時間，也便是讓請求以均勻的速度經過，對應的是漏桶算法。

熔斷策略

Sentinel本質上是基於熔斷器模式，支持基於異常比率的熔斷降級，在調用達到必定量級而且失敗比率達到設定的閾值時自動進行熔斷，此時全部對該資源的調用都會被阻塞，直到過了指定的時間窗口後才啓發性地恢復。

4、源代碼地址

GitHub·地址
https://github.com/cicadasmile/husky-spring-cloud
GitEE·地址
https://gitee.com/cicadasmile/husky-spring-cloud

推薦閱讀：微服務架構系列

序號	標題
01	微服務架構：項目技術選型簡介，架構圖解說明
02	微服務架構：業務架構設計，系統分層管理
03	微服務架構：數據庫選型簡介，業務數據規劃設計
04	微服務架構：中間件集成，公共服務封裝
05	微服務架構：SpringCloud 基礎組件應用設計
06	微服務架構：經過業務、應用、技術、存儲，聊聊架構
07	微服務技術棧：常見註冊中心組件，對比分析