@
目錄
前言
參考資料：
《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 等多款主流產品進行整合
最后
