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
- 1
- 1
第二步:下載下傳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
- 1
- 1
檢測啟動過程,如圖所示:
通路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>
- 1
- 2
- 3
- 4
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
第二步:打開服務消費方配置檔案application.yml,添加sentinel配置,代碼如下:
spring:
cloud:
sentinel:
transport:
port: 8099 #跟sentinel控制台交流的端口,随意指定一個未使用的端口即可
dashboard: localhost:8180 # 指定sentinel控制台位址。
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
第三步:啟動服務提供者,服務消費者,然後在浏覽器通路消費者url,如圖所示:
第四步:重新整理sentinel 控制台,檢測服務清單,如圖所示:
Sentinel的控制台其實就是一個SpringBoot編寫的程式,我們需要将我們的服務注冊到控制台上,即在微服務中指定控制台的位址,并且還要在消費端開啟一個與sentinel控制台傳遞資料端的端口,控制台可以通過此端口調用微服務中的監控程式來擷取各種資訊。
Sentinel限流快速入門
我們設定一下指定接口的流控(流量控制),QPS(每秒請求次數)單機門檻值為1,代表每秒請求不能超出1次,要不然就做限流處理,處理方式直接調用失敗。
第一步:選擇要限流的鍊路,如圖所示:
第二步:設定限流政策,如圖所示:
第三步:反複重新整理通路消費端端服務,檢測是否有限流資訊輸出,如圖所示:
Sentinel流控規則分析
門檻值類型分析
- QPS(Queries Per Second):當調用這個api的時,QPS達到單機門檻值時,就會限流。
- 線程數:當調用這個api的時,線程數達到單機門檻值時,就會限流。
設定限流模式
Sentinel的流控模式代表的流控的方式,預設【直接】,還有關聯,鍊路。
直接模式:
Sentinel預設的流控處理就是【直接->快速失敗】。
。這種關聯模式有什麼應用場景呢?我們舉個例子,訂單服務中會有2個重要的接口,一個是讀取訂單資訊接口,一個是寫入訂單資訊接口。在高并發業務場景中,兩個接口都會占用資源,如果讀取接口通路過大,就會影響寫入接口的性能。業務中如果我們希望寫入訂單比較重要,要優先考慮寫入訂單接口。那就可以利用關聯模式;在關聯資源上面設定寫入接口,資源名設定讀取接口就行了;這樣就起到了優先寫入,一旦寫入請求多,就限制讀的請求。例如:
鍊路模式
鍊路模式隻記錄指定鍊路入口的流量。也就是當多個服務對指定資源調用時,假如流量超出了指定門檻值,則進行限流。被調用的方法用@SentinelResource進行注解,然後分别用不同業務方法對此業務進行調用,假如A業務設定了鍊路模式的限流,在B業務中是不受影響的。例如現在設計一個業務對象,代碼如下(為了簡單,可以直接寫在啟動類内部):
@Service
public class ConsumerService{
@SentinelResource("doGetResource")
public String doGetResource(){
return "doGetResource";
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
接下來我們在/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調用服務響應資料類型
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
其路由規則配置如下:
說明,流控模式為鍊路模式時,假如是sentinel 1.7.2以後版本,Sentinel Web過濾器預設收斂所有URL的入口上下文(sentinel_spring_web_context),是以互連限流不生效,需要在application.yml添加如下語句來關閉URL PATH聚合(了解,可以自己嘗試):
sentinel:
web-context-unify: false
- 1
- 2
- 1
- 2
修改配置以後,重新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調用服務響應資料類型
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
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();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
小節面試分析
- 何為降級熔斷?(讓外部應用停止對服務的通路,生活中跳閘,路障設定-此路不通)
- 為什麼要進行熔斷呢?(平均響應速度越來越慢或經常出現異常,這樣可能會導緻調用鍊堆積,最終系統崩潰)
- 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;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
第二步:服務啟動後,選擇要限流的熱點鍊路,如圖所示:
。參數索引為@SentinelResource注解的方法參數下标,0代表第一個參數,1代表第二個參數。單機門檻值以及統計視窗時長表示在此視窗時間超過門檻值就限流。
第四步:多次通路熱點參數方法,前端會出現如下界面,如圖所示:
然後,在背景出現如下異常表示限流成功。
com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException: 2
- 1
- 1
其中,熱點參數其實說白了就是特殊的流控,流控設定是針對整個請求的;但是熱點參數他可以設定到具體哪個參數,甚至參數針對的值,這樣更靈活的進行流控管理。
一般應用在某些特殊資源的特殊處理,如:某些商品流量大,其他商品流量很正常,就可以利用熱點參數限流的方案。
特定參數設計
配置參數例外項,如圖所示:
這裡表示參數值為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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
第二步:定義流控規則,如圖所示:
第三步:執行資源通路,檢測授權規則應用,當我們配置的流控應用值為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-本地庫,網絡,鏡像倉庫)
- 單詞錯誤(拼寫錯誤)
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
- 1
- 1
第二步:下載下傳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
- 1
- 1
檢測啟動過程,如圖所示:
通路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>
- 1
- 2
- 3
- 4
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
第二步:打開服務消費方配置檔案application.yml,添加sentinel配置,代碼如下:
spring:
cloud:
sentinel:
transport:
port: 8099 #跟sentinel控制台交流的端口,随意指定一個未使用的端口即可
dashboard: localhost:8180 # 指定sentinel控制台位址。
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
第三步:啟動服務提供者,服務消費者,然後在浏覽器通路消費者url,如圖所示:
第四步:重新整理sentinel 控制台,檢測服務清單,如圖所示:
Sentinel的控制台其實就是一個SpringBoot編寫的程式,我們需要将我們的服務注冊到控制台上,即在微服務中指定控制台的位址,并且還要在消費端開啟一個與sentinel控制台傳遞資料端的端口,控制台可以通過此端口調用微服務中的監控程式來擷取各種資訊。
Sentinel限流快速入門
我們設定一下指定接口的流控(流量控制),QPS(每秒請求次數)單機門檻值為1,代表每秒請求不能超出1次,要不然就做限流處理,處理方式直接調用失敗。
第一步:選擇要限流的鍊路,如圖所示:
第二步:設定限流政策,如圖所示:
第三步:反複重新整理通路消費端端服務,檢測是否有限流資訊輸出,如圖所示:
Sentinel流控規則分析
門檻值類型分析
- QPS(Queries Per Second):當調用這個api的時,QPS達到單機門檻值時,就會限流。
- 線程數:當調用這個api的時,線程數達到單機門檻值時,就會限流。
設定限流模式
Sentinel的流控模式代表的流控的方式,預設【直接】,還有關聯,鍊路。
直接模式:
Sentinel預設的流控處理就是【直接->快速失敗】。
。這種關聯模式有什麼應用場景呢?我們舉個例子,訂單服務中會有2個重要的接口,一個是讀取訂單資訊接口,一個是寫入訂單資訊接口。在高并發業務場景中,兩個接口都會占用資源,如果讀取接口通路過大,就會影響寫入接口的性能。業務中如果我們希望寫入訂單比較重要,要優先考慮寫入訂單接口。那就可以利用關聯模式;在關聯資源上面設定寫入接口,資源名設定讀取接口就行了;這樣就起到了優先寫入,一旦寫入請求多,就限制讀的請求。例如:
鍊路模式
鍊路模式隻記錄指定鍊路入口的流量。也就是當多個服務對指定資源調用時,假如流量超出了指定門檻值,則進行限流。被調用的方法用@SentinelResource進行注解,然後分别用不同業務方法對此業務進行調用,假如A業務設定了鍊路模式的限流,在B業務中是不受影響的。例如現在設計一個業務對象,代碼如下(為了簡單,可以直接寫在啟動類内部):
@Service
public class ConsumerService{
@SentinelResource("doGetResource")
public String doGetResource(){
return "doGetResource";
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
接下來我們在/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調用服務響應資料類型
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
其路由規則配置如下:
說明,流控模式為鍊路模式時,假如是sentinel 1.7.2以後版本,Sentinel Web過濾器預設收斂所有URL的入口上下文(sentinel_spring_web_context),是以互連限流不生效,需要在application.yml添加如下語句來關閉URL PATH聚合(了解,可以自己嘗試):
sentinel:
web-context-unify: false
- 1
- 2
- 1
- 2
修改配置以後,重新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調用服務響應資料類型
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
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();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
小節面試分析
- 何為降級熔斷?(讓外部應用停止對服務的通路,生活中跳閘,路障設定-此路不通)
- 為什麼要進行熔斷呢?(平均響應速度越來越慢或經常出現異常,這樣可能會導緻調用鍊堆積,最終系統崩潰)
- 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;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
第二步:服務啟動後,選擇要限流的熱點鍊路,如圖所示:
。參數索引為@SentinelResource注解的方法參數下标,0代表第一個參數,1代表第二個參數。單機門檻值以及統計視窗時長表示在此視窗時間超過門檻值就限流。
第四步:多次通路熱點參數方法,前端會出現如下界面,如圖所示:
然後,在背景出現如下異常表示限流成功。
com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException: 2
- 1
- 1
其中,熱點參數其實說白了就是特殊的流控,流控設定是針對整個請求的;但是熱點參數他可以設定到具體哪個參數,甚至參數針對的值,這樣更靈活的進行流控管理。
一般應用在某些特殊資源的特殊處理,如:某些商品流量大,其他商品流量很正常,就可以利用熱點參數限流的方案。
特定參數設計
配置參數例外項,如圖所示:
這裡表示參數值為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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
第二步:定義流控規則,如圖所示:
第三步:執行資源通路,檢測授權規則應用,當我們配置的流控應用值為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-本地庫,網絡,鏡像倉庫)
- 單詞錯誤(拼寫錯誤)
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
- 1
- 1
第二步:下載下傳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
- 1
- 1
檢測啟動過程,如圖所示:
通路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>
- 1
- 2
- 3
- 4