@

• 前言
• 1. 服務容災基礎知識
  • 1.1 由一個服務資源耗盡引發的連鎖反應
  • 1.2 服務雪崩效應
  • 1.3 四種客戶端彈性模式
  • 1.4 服務容災的幾種解決方案
  • 1.5 服務降級的參考指標
  • 1.6 服務限流的作用
  • 1.7 常見的幾種限流演算法
    • 1.7.1 計數器演算法
    • 1.7.2 滑動視窗演算法
    • 1.7.3 令牌桶演算法
    • 1.7.4 漏桶限流演算法
  • 1.8 利用 Postman 模擬請求高并發場景
  • 1.9 目前幾種流行的服務降級組件對比
• 2. Hystrix
• 3. Sentinel
• 4. Resilience4j
• 最后

前言

參考資料：
《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 目前幾種流行的服務降級組件對比

2. Hystrix

Hystrix 是一個延遲和容災庫，旨在隔離遠程系統、服務和第三方庫的訪問點，停止級聯故障，并在故障不可避免的復雜分布式系統中實作彈性；

• 點擊訪問：微服務架構 | 5.1 使用 Netflix Hystrix 斷路器

3. Sentinel

Sentinel 是面向分布式服務架構的輕量級流量控制組件，主要以流量為切入點，從限流、流量整形、服務降級、系統負載保護等多個維度來幫助我們保障微服務的穩定性；

• 點擊訪問：微服務架構 | 5.2 基于 Sentinel 的服務限流及熔斷
• 點擊訪問：微服務架構 | 5.4 Sentinel 流控、統計和熔斷的原始碼分析

4. Resilience4j

Resilicence4j 一款非常輕量、簡單，并且檔案非常清晰、豐富的熔斷工具，這也是Hystrix官方推薦的替代產品，不僅如此，Resilicence4j 還原生支持Spring Boot 1.x/2.x，而且監控也支持和 prometheus 等多款主流產品進行整合

• 點擊訪問：

最后

新人制作，如有錯誤，歡迎指出，感激不盡！ 歡迎關注公眾號，會分享一些更日常的東西！ 如需轉載，請標注出處！

標籤：架構設計

上一篇：Java 音頻自定義時長靜音

下一篇：微服務架構 | 5. 服務容災