目錄前言整合Sentinel流控設定流控模式流控效果總結前言
之前介紹了Sentinel基本工作原理，以及Sentinel的監控，接下來老顧來注重介紹一下Sentinel的流控管理。
注：之前部署了Sentinel Dashboard在192.168.5.153伺服器上
nohup java -jar sentinel-dashboard-1.6.3.jar &
整合Sentinel首先我們建立一個spring boot專案，引入依賴
我們採用了最新版本boot 2.1.x 和 cloud的Greenwich.SR2，以及alibaba的2.1.0.RELEASE
我們只要在專案中引入spring-cloud-starter-alibaba-sentinel就可以了。這樣就能獲得限流熔斷功能
配置
下面我們只需要在專案應用中配置一下dashboard伺服器地址
spring.cloud.sentinel.transport.dashboard：配置Sentinel控制檯的ip和埠
請求路徑
我們再建立一個請求控制器，模擬請求介面
啟動
啟動後，請求介面http://localhost/test-b，http://localhost/test-a；檢視sentinel控制檯
表示應用整合Sentinel成功了。下面我們就介紹怎麼進行流控設定
流控設定在控制檯的“簇點鏈路”選單裡面，就能看到請求介面（也叫端點）的層次關係，看到一些指標（通過QPS，拒絕QPS，執行緒數，平均RT，分鐘通過，分鐘拒絕），操作一欄有個【流控】按鈕
資源名：預設的是請求路徑，當然不一定是路徑，只要是唯一的名稱就行。
針對來源：針對呼叫同一個資源時，Sentinel是能夠區分不同調用者，為不同的呼叫者設定不一樣的流控規則；如：app-a設定QPS型別的流控，app-b設定執行緒數型別的流控。預設default，表示不區分呼叫者。
閾值型別：
QPS：當呼叫這個api的時，QPS達到單機閾值時，就會限流
執行緒數：當呼叫這個api的時，執行緒數達到單機閾值時，就會限流
是否叢集：這個以後再介紹
流控模式直接模式接著上面的流控設定，Sentinel的流控模式代表的流控的方式，預設【直接】，還有關聯，鏈路。
Sentinel的流控效果：預設【快速失敗】，還有WarmUp，排隊等待。
Sentinel預設的流控處理就是【直接->快速失敗】，我們做個案例：
我們設定一下/test-b介面的流控，QPS單機閥值為1，代表每秒請求不能超出1，要不然就做流控處理，處理方式直接呼叫失敗。
我們呼叫/test-b，慢一點請求，正常返回；快速請求幾次，超過閥值
介面返回了Blocked by Sentinel (flow limiting)，代表被限流了。
關聯模式關聯是什麼意思？
當關聯的資源達到閥值，就限流自己
我們先來測試一下，我們現在有兩個介面/test-a，/test-b；現在我們修改一下之前的流控規格，設定一個關聯
設定了關聯資源為/test-a，上圖設定的效果就是當關聯資源/test-a的qps閥值超過1時，就限流/test-b介面（是不是感覺很霸道，關聯資源達到閥值，是本資源介面被限流了）。
我們來驗證一下，這裡老顧用了PostMan工具來呼叫/test-a，每隔300ms迴圈呼叫。這樣就保證關聯資源/test-a肯定超過了閥值。
我們再來請求/test-b，發現被限流了
這種關聯模式有什麼應用場景呢？
我們舉個例子，訂單服務中會有2個重要的介面，一個是讀取訂單資訊介面，一個是寫入訂單資訊介面。
在高併發業務場景中，兩個介面都會佔用資源，如果讀取介面訪問過大，就會影響寫入介面的效能。業務中如果我們希望寫入訂單比較重要，要優先考慮寫入訂單介面。那就可以利用關聯模式；
在關聯資源上面設定寫入介面，資源名設定讀取介面就行了；這樣就起到了優先寫入，一旦寫入請求多，就限制讀的請求。
關聯模式的核心就是保護關聯資源的。
鏈路模式只記錄鏈路入口的流量
上面是解釋，有點不是太清楚，我們來看個案例，我們改造一下程式碼
上面增加了一個服務，方法用@SentinelResource進行註解
@SentinelResource以後會解釋，大家可以理解就是一個資源名
讓/test-a和/test-b都呼叫這個服務；那我們就可以利用鏈路模式設定限制哪個入口的流量了
這樣設定就起到了，請求介面/test-a會呼叫getOrder，會進行流量控制；但/test-b則不會。
流量效果快速失敗就是流量達到閥值，直接返回報異常
WarmUp也叫預熱，根據codeFactor（預設3）的值，從（閥值/codeFactor）為初始閥值，經過預熱時長，才到達設定的QPS的閥值
上面是什麼意思呢？我們來舉個案例，閥值為100，預熱時長設定10秒。
代表的含義就是，系統初始化的閥值為 100/3 ，即閥值為33；然後過了10秒，閥值才恢復到100
這個預熱的應用場景，如：秒殺系統在開啟的瞬間，會有很多流量上來，很有可能把系統打死，預熱方式就是把為了保護系統，可慢慢的把流量放進來，慢慢的把閥值增長到設定的閥值。
排隊等待從字面上面就能夠猜到，勻速排隊，讓請求以均勻的速度通過，閥值型別必須設成QPS，否則無效。
上圖的設定含義：/test-b的每秒1此請求，超過的話就排隊等待，等待的超時時間為10000毫秒。
我們再次利用Postman工具，迴圈請求/test-b，我們看看控制檯的日誌輸出
我們可以發現test-b的每隔1秒執行一次，這麼多的請求沒有被拒絕，而且進入的排隊。
排隊的應用場景是什麼呢？
比如有時候系統在某一個時刻會出現大流量，之後流量就恢復穩定，可以採用這種排隊模式，大流量來時可以讓流量請求先排隊，等恢復了在慢慢進行處理
總結Sentinel的流控方式還是比較實用的，功能比較強大，也是阿里通過自己的實戰總結提煉的。小夥伴們要去實戰體驗一下哦，謝謝！！！
---End---
最近老顧上傳了微服務閘道器的分享課程，請大家多多支援
推薦閱讀
1、基於RocketMq的SpringCloud Stream框架實戰入門
2、如何搭建訊息中介軟體應用框架之SpringCloud Stream
3、面試必備：閘道器異常了怎麼辦？如何做全域性異常處理？
4、Gateway網關係列(二)：SpringCloud Gateway入門實戰，路由規則
5、Gateway網關係列開篇：SpringCloud的官方閘道器Gateway介紹
6、API閘道器在微服務架構中的應用，這一篇就夠了
7、學習Lambda表示式看這篇就夠了，不會讓你失望的哦（續篇）
8、Lambda用在哪裡？幾種場景？
9、為什麼會出現Lambda表示式，你知道嗎？
10、不說“分散式事務”理論，直接上大廠阿里的解決方案，絕對實用
11、女程式設計師問到這個問題，讓我思考了半天，Mysql的“三高”架構
12、大廠二面：CAP原則為什麼只能滿足其中兩項？而不能同時滿足
13、阿里P7二面：聊聊零拷貝的原理
14、秒殺系統的核心點都在這裡，快來取
15、你了解如何利用token方式實現分散式Session嗎？
16、Mysql索引結構演變，為什麼最終會是那個結構呢？讓你一看就懂
17、一場比賽涉及到的知識，用通俗易通的方式介紹併發協調
18、企業實戰Redis全方面思考，你思考了嗎？
19、面試題：Thread的start和run的區別
20、面試題：什麼是CAS？CAS的作用以及缺點
21、如何訪問redis中的海量資料？避免事故產生
22、如何解決Redis熱點問題？以及如何發現熱點？
23、如何設計API介面，實現統一格式返回？
24、你真的知道在生產環境下如何部署tomcat嗎？
25、分享一線網際網路大廠分散式唯一ID設計 之 snowflake方案
26、分享大廠分散式唯一ID設計方案，快來圍觀
27、你想了解一線大廠的分散式唯一ID生成方案嗎？
28、你知道如何處理大資料量嗎？(資料拆分篇)
29、如何永不遷移資料和避免熱點? 根據伺服器指標分配資料量(揭祕篇)
30、你知道怎麼分庫分表嗎？如何做到永不遷移資料和避免熱點嗎？
31、你了解大型網站的頁面靜態化嗎？
32、你知道如何更新快取嗎？如何保證快取和資料庫雙寫一致性？
33、你知道怎麼解決DB讀寫分離，導致資料不一致問題嗎？
34、DB讀寫分離情況下，如何解決快取和資料庫不一致性問題？
35、你真的知道怎麼使用快取嗎？
36、如何利用鎖，防止快取擊穿？重構思想的重要性
37、海量訂單產生的業務高峰期，如何避免訊息的重複消費？
38、你知道如何保障生產端100%訊息投遞成功嗎？
39、微服務下的分散式session該如何管理？
40、阿里二面：filter、interceptor、aspect應如何選擇？很多人中招
41、網際網路架構重要組員CDN，很多高階開發都沒有實操過，來看這裡
42、阿里二面：CDN快取控制原理，看看能不能難住你
43、SpringCloud Alibaba之Nacos多環境多專案管理
44、SpringCloud Alibaba系列之Nacos配置中心玩法
45、SpringCloud Alibaba之Nacos註冊中心
46、SpringCloud Plus版本之SpringCloud Alibaba
47、SpringCloud Alibaba之Nacos叢集、持久化
48、SpringCloud Alibaba之Nacos共享配置、灰度配置