Sentinel簡介
背景分析
在我們日常生活中，經常會在淘寶、天貓、京東、拼多多等平臺上參與商品的秒殺、搶購以及一些優惠活動，也會在節假日使用12306 手機APP搶火車票、高鐵票，甚至有時候還要幫助同事、朋友為他們家小孩拉投票、刷票，這些場景都無一例外的會引起服務器流量的暴漲，導致網頁無法顯示、APP反應慢、功能無法正常運轉，甚至會引起整個網站的崩潰，
我們如何在這些業務流量變化無常的情況下，保證各種業務安全運營，系統在任何情況下都不會崩潰呢？我們可以在系統負載過高時，采用限流、降級和熔斷，三種措施來保護系統，由此一些流量控制中間件誕生，例如Sentinel，
Sentinel概述
Sentinel (分布式系統的流量防衛兵) 是阿里開源的一套用于服務容錯的綜合性解決方案，它以流量為切入點, 從流量控制、熔斷降級、系統負載保護等多個維度來保護服務的穩定性，
Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景, 例如秒殺（即突發流量控制在系統容量可以承受的范圍）、訊息削峰填谷、集群流量控制、實時熔斷下游不可用應用等，
Sentinel核心分為兩個部分:
- 核心庫（Java 客戶端）：能夠運行于所有 Java 運行時環境，同時對Dubbo /Spring Cloud 等框架也有較好的支持，
- 控制臺（Dashboard）：基于 Spring Boot 開發，打包后可以直接運行，
安裝Sentinel服務
Sentinel 提供一個輕量級的控制臺, 它提供機器發現、單機資源實時監控以及規則管理等功能，其控制臺安裝步驟如下：
第一步：打開sentinel下載網址
https://github.com/alibaba/Sentinel/releases
第二步：下載Jar包（可以存盤到一個sentinel目錄），如圖所示：
第三步：在sentinel對應目錄，打開命令列(cmd),啟動運行sentinel
java -Dserver.port=8180 -Dcsp.sentinel.dashboard.server=localhost:8180 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.0.jar
檢測啟動程序，如圖所示：
訪問Sentinal服務
第一步：假如Sentinal啟動ok，通過瀏覽器進行訪問測驗，如圖所示：
第二步：登陸sentinel,默認用戶和密碼都是sentinel,登陸成功以后的界面如圖所示：
Sentinel限流入門
概述
我們系統中的資料庫連接池，執行緒池，nginx的瞬時并發，MQ訊息等在使用時都會跟定一個限定的值，這本身就是一種限流的設計，限流的目的防止惡意請求流量、惡意攻擊，或者防止流量超過系統峰值，
Sentinel集成
第一步：Sentinel 應用于服務消費方(Consumer)，在消費方添加依賴如下：
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
第二步：打開服務消費方組態檔application.yml，添加sentinel配置，代碼如下：
spring:
cloud:
sentinel:
transport:
port: 8099 #跟sentinel控制臺交流的埠,隨意指定一個未使用的埠即可
dashboard: localhost:8180 # 指定sentinel控制臺地址，
第三步：啟動服務提供者，服務消費者，然后在瀏覽器訪問消費者url，如圖所示：
第四步：重繪sentinel 控制臺，檢測服務串列，如圖所示：
Sentinel的控制臺其實就是一個SpringBoot撰寫的程式，我們需要將我們的服務注冊到控制臺上，即在微服務中指定控制臺的地址，并且還要在消費端開啟一個與sentinel控制臺傳遞資料端的埠，控制臺可以通過此埠呼叫微服務中的監控程式來獲取各種資訊，
Sentinel限流快速入門
我們設定一下指定介面的流控(流量控制)，QPS（每秒請求次數）單機閾值為1，代表每秒請求不能超出1次，要不然就做限流處理，處理方式直接呼叫失敗，
第一步：選擇要限流的鏈路，如圖所示：
第二步：設定限流策略，如圖所示：
第三步：反復重繪訪問消費端端服務，檢測是否有限流資訊輸出，如圖所示：
Sentinel流控規則分析
閾值型別分析
-
QPS(Queries Per Second)：當呼叫這個api的時，QPS達到單機閾值時，就會限流，
-
執行緒數：當呼叫這個api的時，執行緒數達到單機閾值時，就會限流，
設定限流模式
Sentinel的流控模式代表的流控的方式，默認【直接】，還有關聯，鏈路，
直接模式：
Sentinel默認的流控處理就是【直接->快速失敗】，
鏈路模式
鏈路模式只記錄指定鏈路入口的流量，也就是當多個服務對指定資源呼叫時，假如流量超出了指定閾值，則進行限流，被呼叫的方法用@SentinelResource進行注解，然后分別用不同業務方法對此業務進行呼叫，假如A業務設定了鏈路模式的限流,在B業務中是不受影響的，例如現在設計一個業務物件，代碼如下(為了簡單,可以直接寫在啟動類內部)：
@Service
public class ConsumerService{
@SentinelResource("doGetResource")
public String doGetResource(){
return "doGetResource";
}
}
接下來我們在/consumer/doRestEcho1對應的方法中對ConsumerService中的doGetResource方法進行呼叫(應用consumerService物件之前,要先在doRestEcho01方法所在的類中進行consumerService值的注入)，例如:
@GetMapping("/consumer/doRestEcho1")
public String doRestEcho01() throws InterruptedException {
consumerService.doGetResource();
//Thread.sleep(200);
String url="http://localhost:8081/provider/echo/"+server;
//遠程程序呼叫-RPC
return restTemplate.getForObject(url,String.class);//String.class呼叫服務回應資料型別
}
其路由規則配置如下：
說明，流控模式為鏈路模式時，假如是sentinel 1.7.2以后版本，Sentinel Web過濾器默認收斂所有URL的入口背景關系(sentinel_spring_web_context)，因此互連限流不生效，需要在application.yml添加如下陳述句來關閉URL PATH聚合(了解,可以自己嘗試)：
sentinel:
web-context-unify: false
修改配置以后，重新sentinel，并設定鏈路流控規則，然后再頻繁對鏈路/consumer/doRestEcho1進行訪問，檢測是否會出現500例外，
設計限流效果(了解)
此模塊做為課后了解內容,感興趣自學即可.
快速失敗
流量達到指定閥值，直接回傳報例外，（類似路前方坍塌，后面設定路標，讓后面的車輛回傳）
WarmUp (預熱)
WarmUp也叫預熱，根據codeFactor（默認3）的值，（閥值/codeFactor）為初始閾值，經過預熱時長，才到達設定的QPS的閾值，假如單機閾值為100，系統初始化的閾為 100/3 ，即閾值為33，然后過了10秒，閾值才恢復到100，這個預熱的應用場景，如：秒殺系統在開啟的瞬間，會有很多流量上來，很有可能把系統打死，預熱方式就是把為了保護系統，可慢慢的把流量放進來，慢慢的把閾值增長到設定的閾值，例如：
排隊等待
從字面上面就能夠猜到，勻速排隊，讓請求以均勻的速度通過，閾值型別必須設成QPS，否則無效，比如有時候系統在某一個時刻會出現大流量，之后流量就恢復穩定，可以采用這種排隊模式，大流量來時可以讓流量請求先排隊，等恢復了在慢慢進行處理，例如：
小節面試分析
- Sentinel是什么？(阿里推出一個流量控制平臺，防衛兵)
- 類似Sentinel的產品你知道有什么？(hystrix-一代微服務產品)
- 你了解哪些限流演算法？(計數器、令牌桶、漏斗演算法，滑動視窗演算法，…)
- Sentinel 默認的限流演算法是什么？(滑動視窗演算法)
- 你了解sentinel中的閾值應用型別嗎?（兩種-QPS,執行緒數）
- Sentinel 限流規則中默認有哪些限流模式?(直連，關聯，鏈路)
- Sentinel的限流效果有哪些？(快速失敗，預熱，排隊)
- Sentinel 為什么可以對我們的業務進行限流，原理是什么？
我們在訪問web應用時，在web應用內部會有一個攔截器，這個攔截器會對請求的url進行攔截，攔截到請求以后，讀取sentinel 控制臺推送到web應用的流控規則，基于流控規則對流量進行限流操作，
Sentinel降級入門
概述
除了流量控制以外，對呼叫鏈路中不穩定的資源進行熔斷降級也是保障高可用的重要措施之一，由于呼叫關系的復雜性，如果呼叫鏈路中的某個資源不穩定，最侄訓導致請求發生堆積，
Sentinel 熔斷降級會在呼叫鏈路中某個資源出現不穩定狀態時（例如呼叫超時或例外比例升高），對這個資源的呼叫進行限制，讓請求快速失敗，避免影響到其它的資源而導致級聯錯誤，當資源被降級后，在接下來的降級時間視窗之內，對該資源的呼叫都自動熔斷（默認行為是拋出 DegradeException），
準備作業
修改ConumserController 類中的doRestEcho01方法,假如沒有創建即可,基于此方法演示慢呼叫程序下的限流,代碼如下:
//AtomicLong 類支持執行緒安全的自增自減操作
private AtomicLong atomicLong=new AtomicLong(1);
@GetMapping("/consumer/doRestEcho1")
public String doRestEcho01() throws InterruptedException {
//consumerService.doGetResource();
//獲取自增物件的值,然后再加1
long num=atomicLong.getAndIncrement();
if(num%2==0){//模擬50%的慢呼叫比例
Thread.sleep(200);
}
String url="http://localhost:8081/provider/echo/"+server;
//遠程程序呼叫-RPC
return restTemplate.getForObject(url,String.class);//String.class呼叫服務回應資料型別
}
Sentinel降級入門
第一步：服務啟動后，選擇要降級的鏈路，如圖所示：
第二步：選擇要降級的鏈路，如圖所示：
這里表示熔斷策略為慢呼叫比例，表示鏈路請求數超過3時，假如平均回應時間假如超過200毫秒的有50%，則對請求進行熔斷，熔斷時長為10秒鐘，10秒以后恢復正常，
第三步：對指定鏈路進行重繪，多次訪問測驗，假如出現了降級熔斷，會出現如下結果：
我們也可以進行斷點除錯，在DefaultBlockExceptionHandler中的handle方法內部加斷點，分析例外型別，假如例外型別為DegradeException則為降級熔斷，
Sentinel 例外處理
系統提供了默認的例外處理機制，假如默認處理機制不滿足我們需求，我們可以自己進行定義，定義方式上可以直接或間接實作BlockExceptionHandler介面，并將物件交給spring管理，
@Component
public class ServiceBlockExceptionHandler implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest request, HttpServletResponse response,BlockException e) throws Exception {
//response.setStatus(601);
//設定回應資料的編碼
response.setCharacterEncoding("utf-8");
//告訴客戶端要回應的資料型別以及客戶端以什么編碼呈現資料
response.setContentType("text/html;charset=utf-8");
PrintWriter pw=response.getWriter();
Map<String,Object> map=new HashMap<>();
if(e instanceof DegradeException){//降級、熔斷
map.put("status",601);
map.put("message", "服務被熔斷了!");
}else if(e instanceof FlowException){
map.put("status",602);
map.put("message", "服務被限流了!");
}else{
map.put("status",603);
map.put("message", "Blocked by Sentinel (flow limiting)");
}
//將map物件轉換為json格式字串
String jsonStr=new ObjectMapper().writeValueAsString(map);
pw.println(jsonStr);
pw.flush();
}
}
小節面試分析
- 何為降級熔斷？（讓外部應用停止對服務的訪問，生活中跳閘，路障設定-此路不通）
- 為什么要進行熔斷呢？(平均回應速度越來越慢或經常出現例外，這樣可能會導致呼叫鏈堆積，最終系統崩潰)
- Sentinel中限流，降級的例外父類是誰？(BlockException)
- Sentinel 出現降級熔斷時，系統底層拋出的例外是誰？(DegradeException)
- Sentinel中例外處理介面是誰？（BlockExceptionHandler）
- Sentinel中例外處理介面下默認的實作類為? (DefaultBlockExceptionHandler)
- 假如Sentinel中默認的例外處理規則不滿足我們的需求怎么辦?(自己定義)
- 我們如何自己定義Sentinel中例外處理呢？（直接或間接實作BlockExceptionHandler ）
Sentinel降級策略分析(重點)
Sentinel熔斷降級支持慢呼叫比例、例外比例、例外數三種策略，
慢呼叫比例
慢呼叫指耗時大于閾值RT（Response Time）的請求稱為慢呼叫，閾值RT由用戶設定，其屬性具體含義說明如下：
慢呼叫邏輯中的狀態分析如下：
- 熔斷（OPEN）：請求數大于最小請求數并且慢呼叫的比率大于比例閾值則發生熔斷，熔斷時長為用戶自定義設定，
- 探測（HALFOPEN）：當熔斷過了定義的熔斷時長，狀態由熔斷（OPEN）變為探測（HALFOPEN），
- 關閉（CLOSED）：如果接下來的一個請求小于最大RT，說明慢呼叫已經恢復，結束熔斷，狀態由探測（HALF_OPEN）變更為關閉（CLOSED），如果接下來的一個請求大于最大RT，說明慢呼叫未恢復，繼續熔斷，熔斷時長保持一致
注意：Sentinel默認統計的RT上限是4900ms，超出此閾值的都會算作4900ms，若需要變更此上限可以通過啟動配置項-Dcsp.sentinel.statistic.max.rt=xxx來配置
例外比例
當資源的每秒請求數大于等于最小請求數，并且例外總數占通過量的比例超過比例閾值時，資源進入降級狀態，其屬性說明如下：
例外比例中的狀態分析如下：
- 熔斷（OPEN）：當請求數大于最小請求并且例外比例大于設定的閾值時觸發熔斷，熔斷時長由用戶設定，
- 探測（HALFOPEN）：當超過熔斷時長時，由熔斷（OPEN）轉為探測（HALFOPEN）
- 關閉（CLOSED）：如果接下來的一個請求未發生錯誤，說明應用恢復，結束熔斷，狀態由探測（HALF_OPEN）變更為關閉（CLOSED），如果接下來的一個請求繼續發生錯誤，說明應用未恢復，繼續熔斷，熔斷時長保持一致，
例外數量
當資源近1分鐘的例外數目超過閾值（例外數）之后會進行服務降級，注意，由于統計時間視窗是分鐘級別的，若熔斷時長小于60s，則結束熔斷狀態后仍可能再次進入熔斷狀態，其屬性說明如下：
基于例外數的狀態分析如下：
- 熔斷（OPEN）：當請求數大于最小請求并且例外數量大于設定的閾值時觸發熔斷，熔斷時長由用戶設定，
- 探測（HALFOPEN）：當超過熔斷時長時，由熔斷（OPEN）轉為探測（HALFOPEN）
- 關閉（CLOSED）：如果接下來的一個請求未發生錯誤，說明應用恢復，結束熔斷，狀態由探測（HALF_OPEN）變更為關閉（CLOSED）如果接下來的一個請求繼續發生錯誤，說明應用未恢復，繼續熔斷，熔斷時長保持一致，
小節面試分析
- Sentinel 降級熔斷策略有哪些？（慢呼叫，例外比例，例外數）
- Sentinel 熔斷處理邏輯中的有哪些狀態？(Open，HalfOpen,Closed)
- Sentinel 對服務呼叫進行熔斷以后處于什么狀態？(熔斷打開狀態-Open)
- Sentinel 設定的熔斷時長到期以后，Sentinel的熔斷會處于什么狀態？(探測-HalfOpen,假如再次訪問時依舊回應時間比較長或依舊有例外，則繼續熔斷)
- Sentinel 中的熔斷邏輯恢復正常呼叫以后，會出現什么狀態?(熔斷關閉-closed)
Sentinel熱點規則分析（重點）
概述
何為熱點？熱點即經常訪問的資料，很多時候我們希望統計某個熱點資料中訪問頻次最高的 Top N 資料，并對其訪問進行限制，比如：
- 商品 ID 為引數，統計一段時間內最常購買的商品 ID 并進行限制，
- 用戶 ID 為引數，針對一段時間內頻繁訪問的用戶 ID 進行限制，
熱點引數限流會統計傳入引數中的熱點資料，并根據配置的限流閾值與模式，對包含熱點引數的資源呼叫進行限流，熱點引數限流可以看做是一種特殊的流量控制，僅對包含熱點引數的資源呼叫生效，其中，Sentinel會利用 LRU 策略統計最近最常訪問的熱點引數，結合令牌桶演算法來進行引數級別的流控，
4.8.2 快速入門
第一步：定義熱點業務代碼，如圖所示：
//http://ip:port/consumer/doFindById?id=10
@GetMapping("/consumer/findById")
@SentinelResource("res")
public String doFindById(@RequestParam("id") Integer id){
return "resource id is "+id;
}
第二步：服務啟動后，選擇要限流的熱點鏈路，如圖所示：
熱點規則的限流模式只有QPS模式（這才叫熱點），引數索引為@SentinelResource注解的方法引數下標，0代表第一個引數，1代表第二個引數，單機閾值以及統計視窗時長表示在此視窗時間超過閾值就限流，
第四步：多次訪問熱點引數方法，前端會出現如下界面，如圖所示：
然后，在后臺出現如下例外表示限流成功，
com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException: 2
其中，熱點引數其實說白了就是特殊的流控，流控設定是針對整個請求的；但是熱點引數他可以設定到具體哪個引數，甚至引數針對的值，這樣更靈活的進行流控管理，
一般應用在某些特殊資源的特殊處理，如：某些商品流量大，其他商品流量很正常，就可以利用熱點引數限流的方案，
特定引數設計
配置引數例外項，如圖所示：
這里表示引數值為5時閾值為100，其它引數值閾值為1，例如當我們訪問http://ip:port/consumer/doRestEcho1?id=5時的限流閾值為100，
小節面試分析
- 如何理解熱點資料？(訪問頻度比較高的資料，某些商品、謀篇文章、某個視頻)
- 熱點資料的限流規則是怎樣的?(主要是針對引數進行限流設計)
- 熱點資料中的特殊引數如何理解？(熱點限流中的某個引數值的閾值設計)
- 對于熱點資料的訪問出現限流以后底層例外是什么？(ParamFlowException)
Sentinel系統規則（了解）
概述
系統在生產環境運行程序中，我們經常需要監控服務器的狀態，看服務器CPU、記憶體、IO等的使用率；主要目的就是保證服務器正常的運行，不能被某些應用搞崩潰了；而且在保證穩定的前提下，保持系統的最大吞吐量，
長期以來，系統自適應保護的思路是根據硬指標，即系統的負載 (load1) 來做系統過載保護，當系統負載高于某個閾值，就禁止或者減少流量的進入；當 load 開始好轉，則恢復流量的進入，
快速入門
Sentinel的系統保護規則是從應用級別的入口流量進行控制，從單臺機器的總體 Load、RT、入口 QPS 、執行緒數和CPU使用率五個維度監控應用資料，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性，如圖所示：
其中，
- Load（僅對 Linux/Unix-like 機器生效）：當系統 load1 超過閾值，且系統當前的并發執行緒數超過系統容量時才會觸發系統保護，系統容量由系統的 maxQps * minRt 計算得出，設定參考值一般是 CPU cores * 2.5，
- CPU使用率：當系統 CPU 使用率超過閾值即觸發系統保護（取值范圍 0.0-1.0），
- RT：當單臺機器上所有入口流量的平均 RT 達到閾值即觸發系統保護，單位是毫秒，
- 執行緒數：當單臺機器上所有入口流量的并發執行緒數達到閾值即觸發系統保護，
- 入口 QPS：當單臺機器上所有入口流量的 QPS 達到閾值即觸發系統保護，
系統保護規則是應用整體維度的，而不是資源維度的，并且僅對入口流量生效，入口流量指的是進入應用的流量（EntryType.IN），比如 Web 服務，
小節面試分析
- 如何理解sentinel中的系統規則？(是對所有鏈路的控制規則,是一種系統保護策略)
- Sentinel的常用系統規則有哪些？(RT,QPS,CPU,執行緒,Load-linux,unix)
- Sentinel系統保護規則被觸發以后底層會拋出什么例外？（SystemBlockException）
Sentinel授權規則(重要)
概述
很多時候，我們需要根據呼叫方來限制資源是否通過，這時候可以使用 Sentinel 的黑白名單控制的功能，黑白名單根據資源的請求來源（origin）限制資源是否通過，若配置白名單則只有請求來源位于白名單內時才可通過；若配置黑名單則請求來源位于黑名單時不通過，其余的請求通過，例如微信中的黑名單，
快速入門
sentinel可以基于黑白名單方式進行授權規則設計，如圖所示：
黑白名單規則（AuthorityRule）非常簡單，主要有以下配置項：
- 資源名:即限流規則的作用物件
- 流控應用:對應的黑名單/白名單中設定的規則值,多個值用逗號隔開.
- 授權型別:白名單，黑名單(不允許訪問).
案例實作:
定義請求決議器,用于對請求進行決議,并回傳決議結果,sentinel底層 在攔截到用戶請求以后,會對請求資料基于此物件進行決議,判定是否符合黑白名單規則
第一步:定義RequestOriginParser介面的實作類，基于業務在介面方法中決議請求資料并回傳.
@Component
public class DefaultRequestOriginParser implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest request) {
String origin = request.getParameter("origin");
return origin;
}
}
第二步:定義流控規則,如圖所示:
第三步:執行資源訪問,檢測授權規則應用,當我們配置的流控應用值為app1時，假如規則為黑名單，則基于
http://ip:port/path?origin=app1的請求不可以通過,會出現如下結果:
第四步:設計程序分析，如圖所示：
小節面試分析
- 如何理解Sentinel中的授權規則？(對指定資源的訪問給出的一種簡易的授權策略)
- Sentinel的授權規則是如何設計的？(白名單和黑名單)
- 如何理解Sentinel中的白名單？（允許訪問的資源名單）
- 如何理解Sentinel中的黑名單？（不允許訪問的資源名單）、
- Sentinel如何識別白名單和黑名單？(在攔截器中通過呼叫RequestOriginParser物件的方法檢測具體的規則)
- 授權規則中RequestOriginParser類的做用是什么？（對流控應用值進行決議，檢查服務訪問時傳入的值是否與RequestOriginParser的parseOrigin方法回傳值是否相同，）
總結(Summary)
總之，Sentinel可為秒殺、搶購、搶票、拉票等高并發應用，提供API介面層面的流量限制，讓突然暴漲而來的流量用戶訪問受到統一的管控，使用合理的流量放行規則使得用戶都能正常得到服務，
重難點分析
- Sentinel誕生的背景?(計算機的數量是否有限,處理能力是否有限,并發比較大或突發流量比較大)
- 服務中Sentinel環境的集成,初始化?(添加依賴-兩個,sentinel配置)
- Sentinel 的限流規則?(閾值型別-QPS&執行緒數,限流模式-直接,關聯,鏈路)
- Sentinel 的降級(熔斷)策略?(慢呼叫,例外比例,例外數)
- Sentinel 的熱點規則設計(掌握)?
- Sentinel 系統規則設計?(了解,全域規則定義,針對所有請求有效)
- Sentinel 授權規則設計?(掌握,黑白名單)
FAQ分析
- 為什么要限流?
- 你了解的那些限流框架?(sentinel)
- 常用的限流演算法有那些?(計數,令牌桶-電影票,漏桶-漏斗,滑動視窗)
- Sentinel有哪些限流規則?(QPS,執行緒數)
- Sentinel有哪些限流模式?(直接,關聯-創建訂單和查詢訂單,鏈路限流-北京六環外不限號,但是五環就限號)
- Sentinel 的降級(熔斷)策略有哪些?(慢呼叫-回應時長,例外比例-例外占比,例外數)
- Sentinel 的熱點規則中的熱點資料?(熱賣商品,微博大咖,新上映的電影)
- 如何理解Sentinel 授權規則中的黑白名單?
Bug分析
- 依賴下載失敗 (maven-本地庫,網路,鏡像倉庫)
- 單詞錯誤(拼寫錯誤)
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/291084.html
標籤：其他
上一篇：點對點視頻分發：從早期互聯網到ZB位元組（Zettabyte）時代的分布式網路
下一篇：容器型資料型別——字串