個人中心
退出
什么？Sentinel流控規(guī)則可以這樣玩？
前言
上一篇文章中，我們講解了關(guān)于sentinel基本介紹以及流控規(guī)則中直接和快速失敗的效果，有興趣的可以去看上一篇文章，今天，我們給大家?guī)砀釉敿毜年P(guān)于sentinel流控規(guī)則的介紹。今天的內(nèi)容我們主要圍繞四個點進行展開介紹。
- 流控模式 ：關(guān)聯(lián)、鏈路
- 流控效果 ：Warm Up、排隊等待
這四點具體是什么意思呢？別急我們一個一個來做詳細的介紹，首先我們從關(guān)聯(lián)開始。
首先啟動項目：cloud-alibaba-sentinel-8006
關(guān)聯(lián)
在官方的介紹中是這樣說的：關(guān)聯(lián)的資源達到閾值時，就限流自己。
這句話是什么意思呢？用比較直白一點的話來講，假設(shè)我們有A和B兩個接口，當A關(guān)聯(lián)B接口，同時B接口的資源達到設(shè)定的閾值時，限流A。我們也可以理解成，當我們下游的服務(wù)出現(xiàn)訪問壓力過大時，對上游的服務(wù)進行攔截和限流操作，例如：電商系統(tǒng)，當我們訂單系統(tǒng)超出承受閾值時，對我們支付模塊進行限流。
例如：當我們關(guān)聯(lián)order接口達到我們設(shè)定的閾值時，限流pay的接口訪問。
@Slf4j
@RestController
public class TestController {
@GetMapping("/pay")
public String pay() {
return "hello my name is pay ,wo shi boy";
}
@GetMapping("/order")
public String order(){
return "hi my name is order, me is girl";
}
}
給pay接口添加流控規(guī)則
在這里我們需要使用到postMan工具，來模擬并發(fā)訪問，用它來測試我們的order接口的并發(fā)訪問。
在這里的意思是25個線程0.25秒跑一次，當我們跑起來之后，再去訪問pay接口就可以看到以下信息
當我們對order接口進行并發(fā)訪問的時候，這個時候我們?nèi)ピL問pay接口，就可以看到pay接口返回限流信息
鏈路
接下來我們就來看一下流控模式中的鏈路，鏈路的意思是值當某個接口過來的資源達到閾值時，開啟限流，主要是針對于請求來源的微服務(wù)，具有更細顆粒度。
比如在一個服務(wù)應(yīng)用中，多個(pay和order)接口都調(diào)用了同一個服務(wù)中的方法（該方法必須使用注解 SentinelResource進行修飾），如果頻繁的去請求pay接口，并且達到設(shè)定的閾值，這么時候我們再去請求order接口，那么調(diào)用了同一服務(wù)的order接口就會被限流
test類
@Service
public class TestService {
// 定義限流資源
@SentinelResource("end")
public String end(){
return "end method";
}
}
controller類
@Slf4j
@RestController
public class TestController {
@Autowired
private TestService testService;
@GetMapping("/pay")
public String pay() {
return testService.end();
}
@GetMapping("/order")
public String order(){
return testService.end();
}
}
配置項web-context-unify，這個配置的意思是說根據(jù)不同的URL進行鏈路限流，否則沒有效果
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
sentinel:
transport:
#配置Sentinel地址，就是我們的WEB界面
dashboard: localhost:8080
#Sentinel配置默認8719端口，被占用端口會自動從+1，直到找到未被占用的端口
port: 8719
# 配置為false
web-context-unify: false
我們訪問pay接口和order接口后，需要對end進行流控規(guī)則的配置，也就是使用了SentinelResource注解標注的方法進行流控設(shè)置。
那么這個時候如果我們頻繁的去訪問order接口的時候，就會出現(xiàn)異常的情況，直接拋出錯誤提示，這個也是因為快速失敗在鏈路上的直接體現(xiàn)
Warm Up
參考文檔：https://sentinelguard.io/zh-cn/docs/flow-control.html
Warm Up 流量控制，也叫預熱或者冷啟動方式，會根據(jù)我們設(shè)定的規(guī)則，進行緩慢的流量放開，逐漸增加閾值上限，給系統(tǒng)一個反應(yīng)時間，避免流量的突然增加，將系統(tǒng)壓垮的情況發(fā)生，主要用于預防我們系統(tǒng)長期處于穩(wěn)定的流量訪問下，突然流量的增加，將系統(tǒng)資源直接拉滿的情況.
在這里我們主要弄明白兩個參數(shù)
單機閾值：12，這個表示我們訪問最大閾值為12，但是第一次最大訪問量為4，為什么是4呢，看下面公式
預熱公式：閾值/coldFactor（默認值為3），經(jīng)過預熱時間后才會達到閾值。
預熱時長：5 ，也就是說我們的請求會在五秒內(nèi)單機閾值達到12的訪問，比如第一次為4，后續(xù)在五秒內(nèi)依次5/6/8/10，最后達到12的閾值
一般這種在秒殺或者電商節(jié)中會設(shè)置這樣的流控規(guī)則，就是為了防止突然流量的增加導致系統(tǒng)的奔潰。
當我們設(shè)置完流控規(guī)則以后，我們就來看一下效果，我們剛才設(shè)置的order的接口，如果當我們在頻繁的去訪問order接口的時候，如果超過當前時間設(shè)定的閾值時，直接返回限流信息。
在這里我們直接用瀏覽器瘋狂的去刷新，是時候體驗單身二十幾年的手速了，當然也可以使用postman接口去試，我們這邊手速比較快，直接用瀏覽器刷新，我們可以看到下面的曲線圖：
藍色表示你拒絕的QPS，綠色表示通過的QPS，我們可以看到藍色成明顯的下降趨勢，而綠色成上升趨勢，也可以通過右邊的表格中看到，剛開始通過的只有四個，具體的有三個，后面通過慢慢增加，拒絕慢慢變少，這個就是我們Warm Up（預熱）的作用了
排隊等待
我們現(xiàn)在來介紹最后一個流控規(guī)則的使用，排隊等待會嚴格控制請求通過的間隔時間，讓請求穩(wěn)定且勻速的通過，可以用來處理間隔性突發(fā)的高流量，例如搶票軟件，在某一秒或者一分鐘內(nèi)有大量的請求到來，而接下來的一段時間里處于空閑狀態(tài)，我們希望系統(tǒng)能夠在接下來的空余時間里也能出去這些請求，而不是直接拒絕。
以固定的間隔時間讓請求通過，當請求過來的時候，如果當前請求距離上一個請求通過的時間大于 規(guī)則預設(shè)值 ，則請求通過，如果當前請求預期通過時間小于 規(guī)則預設(shè)值 ，則進行排隊等待，如果預期通過時間超過最大排隊時間，直接拒絕請求。
Sentinel排隊等待是 漏銅算法+虛擬隊列機制實現(xiàn)的，目前排隊等待中不支持QPS>1000的場景
我們對pay接口進行設(shè)置，一秒鐘只處理一個QPS請求，其他的排隊，如果超過15秒則直接拒絕
pay接口調(diào)整，這里我們給pay接口加上打印日志，方便我們看到具體效果
@GetMapping("/pay")
public String pay() {
// return "hello my name is pay ,wo shi boy";
log.info("pay接口，請求線程為："+Thread.currentThread().getName());
return testService.end();
}
我們借助postman來進行調(diào)用，說明手速始終更不上工具，還是工具香，這里我們設(shè)置10個請求，沒有間隔時間
從下圖中我們可以看到，對于我們的請求，是一個QPS請求。
總結(jié)
到這里呢，我們的流控規(guī)則就講完了，主要是針對不同的規(guī)則進行不同的設(shè)定，來滿足我們不用業(yè)務(wù)場景，可能會有一點點的小饒，但是如果親自操作之后，會感覺原來是這樣，感興趣的小伙伴可以自己動手試一試，源碼都已經(jīng)上傳了，只有動手了才能感受到其中的快樂，趕緊去試一試吧。
文章轉(zhuǎn)載自： https://muxiaonong.blog.csdn.net
公眾號:牧小農(nóng),微信掃碼關(guān)注或搜索公眾號名稱
分類導航