前言

參考資料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服務(wù)原理與實(shí)戰(zhàn)》
《B站 尚硅谷 SpringCloud 框架開發(fā)教程 周陽》

當(dāng)服務(wù)器壓力劇增的情況下，根據(jù)實(shí)際業(yè)務(wù)情況及流量，對一些服務(wù)和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務(wù)器資源以保證核心交易正常運(yùn)作或高效運(yùn)作；

1. 服務(wù)容災(zāi)基礎(chǔ)知識(shí)

1.1 由一個(gè)服務(wù)資源耗盡引發(fā)的連鎖反應(yīng)

服務(wù)資源耗盡引發(fā)的連鎖反應(yīng)

• A 服務(wù)調(diào)用 B 服務(wù)，B 服務(wù)調(diào)用 C 服務(wù)；
• 當(dāng) C 服務(wù)出現(xiàn)調(diào)用緩慢問題是，影響 B 服務(wù)的響應(yīng)；B 服務(wù)又會(huì)影響 A 服務(wù)，導(dǎo)致其他服務(wù)不可用；

1.2 服務(wù)雪崩效應(yīng)

• 在微服務(wù)架構(gòu)中，我們將業(yè)務(wù)拆分成一個(gè)個(gè)的服務(wù)，服務(wù)與服務(wù)之間可以相互調(diào)用，但是由于網(wǎng)絡(luò)原因或者自身的原因，服務(wù)并不能保證服務(wù)的 100% 可用，如果單個(gè)服務(wù)出現(xiàn)問題，調(diào)用這個(gè)服務(wù)就會(huì)出現(xiàn)網(wǎng)絡(luò)延遲，此時(shí)若有大量的網(wǎng)絡(luò)涌入，會(huì)形成任務(wù)堆積，最終導(dǎo)致服務(wù)癱瘓；

• 在分布式系統(tǒng)中，由于網(wǎng)絡(luò)原因或自身的原因，服務(wù)一般無法保證 100% 可用。如果一個(gè)服務(wù)出現(xiàn)了問題，調(diào)用這個(gè)服務(wù)就會(huì)出現(xiàn)線程阻塞的情況，此時(shí)若有大量的請求涌入，就會(huì)出現(xiàn)多條線程阻塞等待，進(jìn)而導(dǎo)致服務(wù)癱瘓；

  
  
  服務(wù)雪崩效應(yīng).png

1.3 四種客戶端彈性模式

• 客戶端負(fù)載均衡模式（client load balance）：讓客戶端從服務(wù)注冊中心查找服務(wù)的所有實(shí)例，然后緩存服務(wù)實(shí)例的物理位置；
• 斷路器模式（circuit breaker）：遠(yuǎn)程服務(wù)調(diào)用時(shí)間太長，斷路器將會(huì)介入并中斷調(diào)用 ；
• 后備模式（fallback）：遠(yuǎn)程服務(wù)調(diào)用失敗時(shí)，服務(wù)消費(fèi)者將執(zhí)行替代代碼路徑， 并嘗試通過其他方式執(zhí)行操作，而不是生成一個(gè)異常；
• 艙壁模式（bulkhead）：每個(gè)遠(yuǎn)程資源、都是隔離的，并分配給線程池；

四種客戶端彈性模式.png

1.4 服務(wù)容災(zāi)的幾種解決方案

• 服務(wù)隔離：即艙壁模式。將系統(tǒng)按照一定的原則劃分為若干個(gè)服務(wù)模塊，各個(gè)模塊之間相對獨(dú)立，無強(qiáng)依賴。常見的隔離方式有：線程池隔離和信號(hào)量隔離；
• 服務(wù)超時(shí)：在上游服務(wù)調(diào)用下游服務(wù)的時(shí)候，設(shè)置一個(gè)最大響應(yīng)時(shí)間，如果超過這個(gè)時(shí)間，下游未作出反應(yīng)，就斷開請求，釋放線程；
• 服務(wù)降級(jí)：即后備模式。服務(wù)提供一個(gè)托底方案，一旦服務(wù)無法正常調(diào)用，就使用托底方案；
• 服務(wù)熔斷：即斷路器。上游服務(wù)為了保護(hù)系統(tǒng)整體的可用性，可以暫時(shí)切斷對下游服務(wù)的調(diào)用。一種“犧牲局部，保全整體”的策略；
• 服務(wù)限流：限制系統(tǒng)的輸入和輸出流量已達(dá)到保護(hù)系統(tǒng)的目的；

1.5 服務(wù)降級(jí)的參考指標(biāo)

• 服務(wù)降級(jí)需要有一個(gè)參考指標(biāo)，一般來說有以下幾種常見方案；
  • 平均響應(yīng)時(shí)間：比如15內(nèi)持續(xù)進(jìn)入5個(gè)請求，對應(yīng)時(shí)刻的平均響應(yīng)時(shí)間均超過閾值，那么接下來在一個(gè)固定的時(shí)間窗口內(nèi)，對這個(gè)方法的訪問都會(huì)自動(dòng)熔斷；
  • 異常比例：當(dāng)某個(gè)方法每秒調(diào)用所獲得的異常總數(shù)的比例超過設(shè)定的閾值時(shí)，該資源會(huì)自動(dòng)進(jìn)入降級(jí)狀態(tài)，也就是在接下來的一個(gè)固定時(shí)間窗口中，對這個(gè)方法的調(diào)用都會(huì)自動(dòng)返回；
  • 異常數(shù)量：和異常比例類似，當(dāng)某個(gè)方法在指定時(shí)間窗口內(nèi)獲得的異常數(shù)量超過閩值時(shí)會(huì)觸發(fā)熔斷；

1.6 服務(wù)限流的作用

• 限流的主要目的是通過限制并發(fā)訪問數(shù)或者限制一個(gè)時(shí)間窗口內(nèi)允許處理的請求數(shù)量來保護(hù)系統(tǒng)，一旦達(dá)到限制數(shù)量則對當(dāng)前請求進(jìn)行處理采取對應(yīng)的拒絕策略，比如跳轉(zhuǎn)到錯(cuò)誤頁面拒絕請求、進(jìn)入排隊(duì)系統(tǒng)、降級(jí)等；
• 從本質(zhì)上來說，限流的主要作用是損失一部分用戶的可用性，為大部分用戶提供穩(wěn)定可靠的服務(wù)；
• 實(shí)際開發(fā)中的限流應(yīng)用：
  • 在 Nginx 層添加限流模塊限制平均訪問速度；
  • 通過設(shè)置數(shù)據(jù)庫連接池、線程池的大小來限制總的并發(fā)數(shù)；
  • 通過 Guava 提供的 Ratelimiter 限制接口的訪問速度；
  • TCP 通信協(xié)議中的流量整形；

1.7 常見的幾種限流算法

1.7.1 計(jì)數(shù)器算法

• 一種比較簡單的限流實(shí)現(xiàn)算法；
• 原理：在指定周期內(nèi)累加訪問次數(shù)，當(dāng)訪問次數(shù)達(dá)到設(shè)定的閩值時(shí)，觸發(fā)限流策略，當(dāng)進(jìn)入下一個(gè)時(shí)間周期時(shí)進(jìn)行訪問次數(shù)的清零；
• 存在臨界問題：前一個(gè)周期的后半部分與后一個(gè)周期的前半部分的總訪問次數(shù)可能超過閾值；

計(jì)數(shù)器算法.png

1.7.2 滑動(dòng)窗口算法

• 是一種流量控制技術(shù)，在 TCP 網(wǎng)絡(luò)通信協(xié)議中，就采用了滑動(dòng)窗口算法來解決網(wǎng)絡(luò)擁塞的情況；
• 原理：在固定窗口中分割出多個(gè)小時(shí)間窗口，分別在每個(gè)小時(shí)間窗口中記錄訪問次數(shù)，然后根據(jù)時(shí)間將窗口往前滑動(dòng)并刪除過期的小時(shí)間窗口。最終只需要統(tǒng)計(jì)滑動(dòng)窗口范圍內(nèi)的所有小時(shí)間窗口總的計(jì)數(shù)即可；
• 該算法解決了臨界問題，Sentinel 采用滑動(dòng)窗口算法來實(shí)現(xiàn)限流；

滑動(dòng)窗口算法.png

1.7.3 令牌桶算法

• 是網(wǎng)絡(luò)流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一種算法；
• 原理：對于每一個(gè)請求，都需要從令牌桶中獲得一個(gè)令牌，如果沒有獲得令牌，則需要觸發(fā)限流策略；
• 由于令牌桶有固定的大小，當(dāng)請求速度小于令牌生成速度時(shí)，令牌桶會(huì)被填滿。所以令牌桶能夠處理突發(fā)流量，也就是在短時(shí)間內(nèi)新增的流量系統(tǒng)能夠正常處理，這是令牌桶的特性；

令牌桶算法.png

1.7.4 漏桶限流算法

• 主要作用是控制數(shù)據(jù)注入網(wǎng)絡(luò)的速度，平滑網(wǎng)絡(luò)上的突發(fā)流量；
• 原理：在漏桶算法內(nèi)部同樣維護(hù)一個(gè)容器，這個(gè)容器會(huì)以恒定速度出水，不管上面的水流速度多快，漏桶水滴的流出速度始終保持不變；
• 消息中間件就使用了漏桶限流的思想；
• 請求速度大于漏桶流出水滴的速度時(shí)，觸發(fā)限流策略；
• 與令牌桶算法的區(qū)別：漏桶無法處理短時(shí)間內(nèi)的突發(fā)流量，漏桶限流算法是一種恒定速度的限流算法；

漏桶限流算法.png

1.8 利用 Postman 模擬請求高并發(fā)場景

• Postman 里新建多線程集合組；

Postman 里新建多線程集合組.png

• 右鍵添加請求

右鍵添加請求.png

• 將訪問地址添加進(jìn)新新線程組；

將訪問地址添加進(jìn)新新線程組.png

• 設(shè)置多線程組的運(yùn)行狀態(tài)；

  
  
  設(shè)置多線程組的運(yùn)行狀態(tài).png

• 使用 postman 密集訪問 testA，下面配置的含義是：

  • 20個(gè)線程每次間隔 0.3s 訪問一次；

    
    
    使用 postman 密集訪問 testA.png

1.9 目前幾種流行的服務(wù)降級(jí)組件對比

2. Hystrix

Hystrix 是一個(gè)延遲和容災(zāi)庫，旨在隔離遠(yuǎn)程系統(tǒng)、服務(wù)和第三方庫的訪問點(diǎn)，停止級(jí)聯(lián)故障，并在故障不可避免的復(fù)雜分布式系統(tǒng)中實(shí)現(xiàn)彈性；

• 點(diǎn)擊訪問：微服務(wù)架構(gòu) | 5.1 使用 Netflix Hystrix 斷路器

3. Sentinel

Sentinel 是面向分布式服務(wù)架構(gòu)的輕量級(jí)流量控制組件，主要以流量為切入點(diǎn)，從限流、流量整形、服務(wù)降級(jí)、系統(tǒng)負(fù)載保護(hù)等多個(gè)維度來幫助我們保障微服務(wù)的穩(wěn)定性；

• 點(diǎn)擊訪問：微服務(wù)架構(gòu) | 5.2 基于 Sentinel 的服務(wù)限流及熔斷
• 點(diǎn)擊訪問：微服務(wù)架構(gòu) | 5.4 Sentinel 流控、統(tǒng)計(jì)和熔斷的源碼分析

4. Resilience4j

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

• 點(diǎn)擊訪問：

最后