微服務架構 | 5. 服務容災

@

目錄

• 前言
• 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 架構開發教程 周陽》

當伺服器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有政策的不處理或換種簡單的方式處理，進而釋放伺服器資源以保證核心交易正常運作或高效運作；

• A 服務調用 B 服務，B 服務調用 C 服務；
• 當 C 服務出現調用緩慢問題是，影響 B 服務的響應；B 服務又會影響 A 服務，導緻其他服務不可用；

• 在微服務架構中，我們将業務拆分成一個個的服務，服務與服務之間可以互相調用，但是由于網絡原因或者自身的原因，服務并不能保證服務的 100% 可用，如果單個服務出現問題，調用這個服務就會出現網絡延遲，此時若有大量的網絡湧入，會形成任務堆積，最終導緻服務癱瘓；
• 在分布式系統中，由于網絡原因或自身的原因，服務一般無法保證 100% 可用。如果一個服務出現了問題，調用這個服務就會出現線程阻塞的情況，此時若有大量的請求湧入，就會出現多條線程阻塞等待，進而導緻服務癱瘓；

• 用戶端負載均衡模式（client load balance）：讓用戶端從服務注冊中心查找服務的所有執行個體，然後緩存服務執行個體的實體位置；
• 斷路器模式（circuit breaker）：遠端服務調用時間太長，斷路器将會介入并中斷調用 ；
• 後備模式（fallback）：遠端服務調用失敗時，服務消費者将執行替代代碼路徑， 并嘗試通過其他方式執行操作，而不是生成一個異常；
• 艙壁模式（bulkhead）：每個遠端資源、都是隔離的，并配置設定給線程池；

• 服務隔離：即艙壁模式。将系統按照一定的原則劃分為若幹個服務子產品，各個子產品之間相對獨立，無強依賴。常見的隔離方式有：線程池隔離和信号量隔離；
• 服務逾時：在上遊服務調用下遊服務的時候，設定一個最大響應時間，如果超過這個時間，下遊未作出反應，就斷開請求，釋放線程；
• 服務降級：即後備模式。服務提供一個托底方案，一旦服務無法正常調用，就使用托底方案；
• 服務熔斷：即斷路器。上遊服務為了保護系統整體的可用性，可以暫時切斷對下遊服務的調用。一種“犧牲局部，保全整體”的政策；
• 服務限流：限制系統的輸入和輸出流量已達到保護系統的目的；

• 服務降級需要有一個參考名額，一般來說有以下幾種常見方案；
  • 平均響應時間：比如15内持續進入5個請求，對應時刻的平均響應時間均超過門檻值，那麼接下來在一個固定的時間視窗内，對這個方法的通路都會自動熔斷；
  • 異常比例：當某個方法每秒調用所獲得的異常總數的比例超過設定的門檻值時，該資源會自動進入降級狀态，也就是在接下來的一個固定時間視窗中，對這個方法的調用都會自動傳回；
  • 異常數量：和異常比例類似，當某個方法在指定時間視窗内獲得的異常數量超過閩值時會觸發熔斷；

• 限流的主要目的是通過限制并發通路數或者限制一個時間視窗内允許處理的請求數量來保護系統，一旦達到限制數量則對目前請求進行處理采取對應的拒絕政策，比如跳轉到錯誤頁面拒絕請求、進入排隊系統、降級等；
• 從本質上來說，限流的主要作用是損失一部分使用者的可用性，為大部分使用者提供穩定可靠的服務；
• 實際開發中的限流應用：
  • 在 Nginx 層添加限流子產品限制平均通路速度；
  • 通過設定資料庫連接配接池、線程池的大小來限制總的并發數；
  • 通過 Guava 提供的 Ratelimiter 限制接口的通路速度；
  • TCP 通信協定中的流量整形；

• 一種比較簡單的限流實作算法；
• 原理：在指定周期内累加通路次數，當通路次數達到設定的閩值時，觸發限流政策，當進入下一個時間周期時進行通路次數的清零；
• 存在臨界問題：前一個周期的後半部分與後一個周期的前半部分的總通路次數可能超過門檻值；

• 是一種流量控制技術，在 TCP 網絡通信協定中，就采用了滑動視窗算法來解決網絡擁塞的情況；
• 原理：在固定視窗中分割出多個小時間視窗，分别在每個小時間視窗中記錄通路次數，然後根據時間将視窗往前滑動并删除過期的小時間視窗。最終隻需要統計滑動視窗範圍内的所有小時間視窗總的計數即可；
• 該算法解決了臨界問題，Sentinel 采用滑動視窗算法來實作限流；

• 是網絡流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法；
• 原理：對于每一個請求，都需要從令牌桶中獲得一個令牌，如果沒有獲得令牌，則需要觸發限流政策；
• 由于令牌桶有固定的大小，當請求速度小于令牌生成速度時，令牌桶會被填滿。是以令牌桶能夠處理突發流量，也就是在短時間内新增的流量系統能夠正常處理，這是令牌桶的特性；

• 主要作用是控制資料注入網絡的速度，平滑網絡上的突發流量；
• 原理：在漏桶算法内部同樣維護一個容器，這個容器會以恒定速度出水，不管上面的水流速度多快，漏桶水滴的流出速度始終保持不變；
• 消息中間件就使用了漏桶限流的思想；
• 請求速度大于漏桶流出水滴的速度時，觸發限流政策；
• 與令牌桶算法的差別：漏桶無法處理短時間内的突發流量，漏桶限流算法是一種恒定速度的限流算法；

• Postman 裡建立多線程集合組；

• 右鍵添加請求

• 将通路位址添加進新新線程組；

• 設定多線程組的運作狀态；

  

• 使用 postman 密集通路 testA，下面配置的含義是：
  • 20個線程每次間隔 0.3s 通路一次；

比較項	Hystrix	Sentinel	Resilience4j
貢獻者	Netflix	Alibaba	Apache 基金會
隔離政策	線程池隔離/信号量隔離	信号量隔離（并發線程數限流）	信号量隔離
熔斷降級政策	基于異常比率	基于響應時間、異常比率、異常數	基于異常比率、響應時間
實時統計實作	滑動視窗（基于 RxJava）	滑動視窗（LeapArray）	Ring Bit Buffer
動态規則配置	支援多種資料源		有限支援
擴充性	插件的形式	多個擴充點	接口的形式
基于注解的支援	支援
限流	有限的支援	基于 QPS，支援基于調用關系的限流	Rate Limiter
流量整形	不支援	支援預熱模式、勻速器模式、預熱排隊模式	簡單的 Rate Limiter模式
系統自适應保護
控制台	簡單的監控檢視	提供開箱即用的控制台，可配置規則、檢視秒級監控、機器發現等	不提供控制台，可對接其它監控系統

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

• 點選通路：微服務架構 | 5.1 使用 Netflix Hystrix 斷路器

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

• 點選通路：微服務架構 | 5.2 基于 Sentinel 的服務限流及熔斷
• 點選通路：微服務架構 | 5.4 Sentinel 流控、統計和熔斷的源碼分析

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

• 點選通路：

新人制作，如有錯誤，歡迎指出，感激不盡！

歡迎關注公衆号，會分享一些更日常的東西！

如需轉載，請标注出處！