@
目錄
前言
參考資料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服務原理與實戰》
《B站 尚矽谷 SpringCloud 框架開發教程 周陽》
當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放伺服器資源以保證核心交易正常運作或高效運作；
1. 服務容災基礎知識
1.1 由一個服務資源耗盡引發的連鎖反應
- A 服務呼叫 B 服務，B 服務呼叫 C 服務；
- 當 C 服務出現呼叫緩慢問題是，影響 B 服務的響應；B 服務又會影響 A 服務，導致其他服務不可用；
1.2 服務雪崩效應
- 在微服務架構中，我們將業務拆分成一個個的服務，服務與服務之間可以相互呼叫，但是由於網路原因或者自身的原因，服務並不能保證服務的 100% 可用，如果單個服務出現問題，呼叫這個服務就會出現網路延遲，此時若有大量的網路湧入，會形成任務堆積，最終導致服務癱瘓；
- 在分散式系統中，由於網路原因或自身的原因，服務一般無法保證 100% 可用。如果一個服務出現了問題，呼叫這個服務就會出現執行緒阻塞的情況，此時若有大量的請求湧入，就會出現多條執行緒阻塞等待，進而導致服務癱瘓；
1.3 四種客戶端彈性模式
- 客戶端負載均衡模式（client load balance）：讓客戶端從服務註冊中心查詢服務的所有例項，然後快取服務例項的物理位置；
- 斷路器模式（circuit breaker）：遠端服務呼叫時間太長，斷路器將會介入並中斷呼叫 ；
- 後備模式（fallback）：遠端服務呼叫失敗時，服務消費者將執行替代程式碼路徑， 並嘗試通過其他方式執行操作，而不是生成一個異常；
- 艙壁模式（bulkhead）：每個遠端資源、都是隔離的，並分配給執行緒池；
1.4 服務容災的幾種解決方案
- 服務隔離：即艙壁模式。將系統按照一定的原則劃分為若干個服務模組，各個模組之間相對獨立，無強依賴。常見的隔離方式有：執行緒池隔離和訊號量隔離；
- 服務超時：在上游服務呼叫下游服務的時候，設定一個最大響應時間，如果超過這個時間，下游未作出反應，就斷開請求，釋放執行緒；
- 服務降級：即後備模式。服務提供一個託底方案，一旦服務無法正常呼叫，就使用託底方案；
- 服務熔斷：即斷路器。上游服務為了保護系統整體的可用性，可以暫時切斷對下游服務的呼叫。一種“犧牲區域性，保全整體”的策略；
- 服務限流：限制系統的輸入和輸出流量已達到保護系統的目的；
1.5 服務降級的參考指標
- 服務降級需要有一個參考指標，一般來說有以下幾種常見方案；
- 平均響應時間：比如15內持續進入5個請求，對應時刻的平均響應時間均超過閾值，那麼接下來在一個固定的時間視窗內，對這個方法的訪問都會自動熔斷；
- 異常比例：當某個方法每秒呼叫所獲得的異常總數的比例超過設定的閾值時，該資源會自動進入降級狀態，也就是在接下來的一個固定時間視窗中，對這個方法的呼叫都會自動返回；
- 異常數量：和異常比例類似，當某個方法在指定時間視窗內獲得的異常數量超過閩值時會觸發熔斷；
1.6 服務限流的作用
- 限流的主要目的是通過限制併發訪問數或者限制一個時間視窗內允許處理的請求數量來保護系統，一旦達到限制數量則對當前請求進行處理採取對應的拒絕策略，比如跳轉到錯誤頁面拒絕請求、進入排隊系統、降級等；
- 從本質上來說，限流的主要作用是損失一部分使用者的可用性，為大部分使用者提供穩定可靠的服務；
- 實際開發中的限流應用：
- 在 Nginx 層新增限流模組限制平均訪問速度；
- 通過設定資料庫連線池、執行緒池的大小來限制總的併發數；
- 通過 Guava 提供的 Ratelimiter 限制介面的訪問速度；
- TCP 通訊協議中的流量整形；
1.7 常見的幾種限流演算法
1.7.1 計數器演算法
- 一種比較簡單的限流實現演算法；
- 原理：在指定週期內累加訪問次數，當訪問次數達到設定的閩值時，觸發限流策略，當進入下一個時間週期時進行訪問次數的清零；
- 存在臨界問題：前一個週期的後半部分與後一個週期的前半部分的總訪問次數可能超過閾值；
1.7.2 滑動視窗演算法
- 是一種流量控制技術，在 TCP 網路通訊協議中，就採用了滑動視窗演算法來解決網路擁塞的情況；
- 原理：在固定視窗中分割出多個小時間視窗，分別在每個小時間視窗中記錄訪問次數，然後根據時間將視窗往前滑動並刪除過期的小時間視窗。最終只需要統計滑動視窗範圍內的所有小時間視窗總的計數即可；
- 該演算法解決了臨界問題，Sentinel 採用滑動視窗演算法來實現限流；
1.7.3 令牌桶演算法
- 是網路流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種演算法；
- 原理：對於每一個請求，都需要從令牌桶中獲得一個令牌，如果沒有獲得令牌，則需要觸發限流策略；
- 由於令牌桶有固定的大小，當請求速度小於令牌生成速度時，令牌桶會被填滿。所以令牌桶能夠處理突發流量，也就是在短時間內新增的流量系統能夠正常處理，這是令牌桶的特性；
1.7.4 漏桶限流演算法
- 主要作用是控制資料注入網路的速度，平滑網路上的突發流量；
- 原理：在漏桶演算法內部同樣維護一個容器，這個容器會以恆定速度出水，不管上面的水流速度多快，漏桶水滴的流出速度始終保持不變；
- 訊息中介軟體就使用了漏桶限流的思想；
- 請求速度大於漏桶流出水滴的速度時，觸發限流策略；
- 與令牌桶演算法的區別：漏桶無法處理短時間內的突發流量，漏桶限流演算法是一種恆定速度的限流演算法；
1.8 利用 Postman 模擬請求高併發場景
- Postman 裡新建多執行緒集合組；
- 右鍵新增請求
- 將訪問地址新增進新新執行緒組；
- 設定多執行緒組的執行狀態；
- 使用 postman 密集訪問 testA，下面配置的含義是：
- 20個執行緒每次間隔 0.3s 訪問一次；
1.9 目前幾種流行的服務降級元件對比
| 比較項 | Hystrix | Sentinel | Resilience4j |
|---|---|---|---|
| 貢獻者 | Netflix | Alibaba | Apache 基金會 |
| 隔離策略 | 執行緒池隔離/訊號量隔離 | 訊號量隔離（併發執行緒數限流） | 訊號量隔離 |
| 熔斷降級策略 | 基於異常比率 | 基於響應時間、異常比率、異常數 | 基於異常比率、響應時間 |
| 實時統計實現 | 滑動視窗（基於 RxJava） | 滑動視窗（LeapArray） | Ring Bit Buffer |
| 動態規則配置 | 支援多種資料來源 | 支援多種資料來源 | 有限支援 |
| 擴充套件性 | 外掛的形式 | 多個擴充套件點 | 介面的形式 |
| 基於註解的支援 | 支援 | 支援 | 支援 |
| 限流 | 有限的支援 | 基於 QPS，支援基於呼叫關係的限流 | Rate Limiter |
| 流量整形 | 不支援 | 支援預熱模式、勻速器模式、預熱排隊模式 | 簡單的 Rate Limiter模式 |
| 系統自適應保護 | 不支援 | 支援 | 不支援 |
| 控制檯 | 簡單的監控檢視 | 提供開箱即用的控制檯，可配置規則、檢視秒級監控、機器發現等 | 不提供控制檯，可對接其它監控系統 |
2. Hystrix
Hystrix 是一個延遲和容災庫，旨在隔離遠端系統、服務和第三方庫的訪問點，停止級聯故障，並在故障不可避免的複雜分散式系統中實現彈性；
3. Sentinel
Sentinel 是面向分散式服務架構的輕量級流量控制元件，主要以流量為切入點，從限流、流量整形、服務降級、系統負載保護等多個維度來幫助我們保障微服務的穩定性；
4. Resilience4j
Resilicence4j 一款非常輕量、簡單，並且文件非常清晰、豐富的熔斷工具，這也是Hystrix官方推薦的替代產品。不僅如此，Resilicence4j 還原生支援Spring Boot 1.x/2.x，而且監控也支援和 prometheus 等多款主流產品進行整合
最後
