本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/husky-spring-cloud) || [GitEE·點這裡](https://gitee.com/cicadasmile/husky-spring-cloud) # 一、流量控制 ## 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 | [微服務架構：專案技術選型簡介，架構圖解說明](https://mp.weixin.qq.com/s/kxbNXupDxcuISm-vW9nhyA)| |02 | [微服務架構：業務架構設計，系統分層管理](https://mp.weixin.qq.com/s/sx_BSfA5zMJ9FaPAApS3Aw)| |03 | [微服務架構：資料庫選型簡介，業務資料規劃設計](https://mp.weixin.qq.com/s/hdS2IB0kx-ehBsEWed75xg)| |04 | [微服務架構：中介軟體整合，公共服務封裝](https://mp.weixin.qq.com/s/5yR5czRHu4EARw5MvnyxcQ)| |05 | [微服務架構：SpringCloud 基礎元件應用設計](https://mp.weixin.qq.com/s/ddyXWTtN2zMnWJZ-T8H8_w)| |06 | [微服務架構：通過業務、應用、技術、儲存，聊聊架構](https://mp.weixin.qq.com/s/mzOK_JOb_i_G1cqy0YAvYw)| |07 | [微服務技術棧：常見註冊中心元件，對比分析](https://mp.weixin.qq.com/s/yBrIZFXe6q7tfRrJ