sentinel的四種流控規則介紹
今天的內容我們主要圍繞四個點進行展開介紹。
- 流控模式 ：關聯、鏈路
- 流控效果 ：Warm Up、排隊等待
這四點具體是什麼意思呢？
首先啓動項目：cloud-alibaba-sentinel-8006
一：關聯
在官方的介紹中是這樣說的：關聯的資源達到閾值時，就限流自己。
這句話是什麼意思呢？用比較直白一點的話來講，假設我們有A和B兩個接口，當A關聯B接口，同時B接口的資源達到設定的閾值時，限流A。我們也可以理解成，當我們下游的服務出現訪問壓力過大時，對上游的服務進行攔截和限流操作，例如：電商系統，當我們訂單系統超出承受閾值時，對我們支付模塊進行限流。
例如：當我們關聯order接口達到我們設定的閾值時，限流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接口添加流控規則
在這裏我們需要使用到postMan工具，來模擬併發訪問，用它來測試我們的order接口的併發訪問。
在這裏的意思是25個線程0.25秒跑一次，當我們跑起來之後，再去訪問pay接口就可以看到以下信息
當我們對order接口進行併發訪問的時候，這個時候我們去訪問pay接口，就可以看到pay接口返回限流信息
二：鏈路
鏈路的意思是值當某個接口過來的資源達到閾值時，開啓限流，主要是針對於請求來源的微服務，具有更細顆粒度。
比如在一個服務應用中，多個(pay和order)接口都調用了同一個服務中的方法（該方法必須使用註解 SentinelResource進行修飾），如果頻繁的去請求pay接口，並且達到設定的閾值，這麼時候我們再去請求order接口，那麼調用了同一服務的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，這個配置的意思是說根據不同的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進行流控規則的配置，也就是使用了SentinelResource註解標註的方法進行流控設置。
那麼這個時候如果我們頻繁的去訪問order接口的時候，就會出現異常的情況，直接拋出錯誤提示，這個也是因爲快速失敗在鏈路上的直接體現
三：Warm Up
參考文檔：https://sentinelguard.io/zh-cn/docs/flow-control.html
Warm Up 流量控制，也叫預熱或者冷啓動方式，會根據我們設定的規則，進行緩慢的流量放開，逐漸增加閾值上限，給系統一個反應時間，避免流量的突然增加，將系統壓垮的情況發生，主要用於預防我們系統長期處於穩定的流量訪問下，突然流量的增加，將系統資源直接拉滿的情況.
在這裏我們主要弄明白兩個參數
單機閾值：12，這個表示我們訪問最大閾值爲12，但是第一次最大訪問量爲4，爲什麼是4呢，看下面公式
預熱公式：閾值/coldFactor（默認值爲3），經過預熱時間後纔會達到閾值。
預熱時長：5 ，也就是說我們的請求會在五秒內單機閾值達到12的訪問，比如第一次爲4，後續在五秒內依次5/6/8/10，最後達到12的閾值
一般這種在秒殺或者電商節中會設置這樣的流控規則，就是爲了防止突然流量的增加導致系統的奔潰。
當我們設置完流控規則以後，我們就來看一下效果，我們剛纔設置的order的接口，如果當我們在頻繁的去訪問order接口的時候，如果超過當前時間設定的閾值時，直接返回限流信息。
在這裏我們直接用瀏覽器瘋狂的去刷新，是時候體驗單身二十幾年的手速了，當然也可以使用postman接口去試，我們這邊手速比較快，直接用瀏覽器刷新，我們可以看到下面的曲線圖：
藍色表示你拒絕的QPS，綠色表示通過的QPS，我們可以看到藍色成明顯的下降趨勢，而綠色成上升趨勢，也可以通過右邊的表格中看到，剛開始通過的只有四個，具體的有三個，後面通過慢慢增加，拒絕慢慢變少，這個就是我們Warm Up（預熱）的作用了
四：排隊等待
我們現在來介紹最後一個流控規則的使用，排隊等待會嚴格控制請求通過的間隔時間，讓請求穩定且勻速的通過，可以用來處理間隔性突發的高流量，例如搶票軟件，在某一秒或者一分鐘內有大量的請求到來，而接下來的一段時間裏處於空閒狀態，我們希望系統能夠在接下來的空餘時間裏也能出去這些請求，而不是直接拒絕。
以固定的間隔時間讓請求通過，當請求過來的時候，如果當前請求距離上一個請求通過的時間大於 規則預設值 ，則請求通過，如果當前請求預期通過時間小於 規則預設值 ，則進行排隊等待，如果預期通過時間超過最大排隊時間，直接拒絕請求。
Sentinel排隊等待是 漏銅算法+虛擬隊列機制實現的，目前排隊等待中不支持QPS>1000的場景
我們對pay接口進行設置，一秒鐘只處理一個QPS請求，其他的排隊，如果超過15秒則直接拒絕
pay接口調整，這裏我們給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來進行調用，說明手速始終更不上工具，還是工具香，這裏我們設置10個請求，沒有間隔時間
從下圖中我們可以看到，對於我們的請求，是一個QPS請求。
小結：流控規則就是針對不同的規則進行不同的設定，來滿足我們不用業務場景。