建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「運維開發(fā)故事」，作者老鄭。轉(zhuǎn)載本文請聯(lián)系運維開發(fā)故事公眾號。
10余年的坡頭網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整坡頭建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“坡頭網(wǎng)站設(shè)計”,“坡頭網(wǎng)站推廣”以來，每個客戶項目都認(rèn)真落實執(zhí)行。
在前面兩篇文章給大家介紹了 Sentinel 的功能和基本使用。現(xiàn)在我們繼續(xù)來學(xué)習(xí) Sentinel 控制臺的基本使用，以及一些規(guī)則配置的說明。讓大家能夠在工作中使用 Sentinel 得心應(yīng)手 (大部分理論和描述來源于官方文檔和網(wǎng)絡(luò))。
在正文開始之前，我先說一下我的基本環(huán)境信息
- jdk 1.8
- sentinel 1.8.0
- spring-boot 2.3.5.RELEASE
- spring-cloud Hoxton.SR8
- spring-cloud-alibaba 2.2.5.RELEASE
控制臺簡介
Sentinel 提供一個輕量級的開源控制臺，它提供機器發(fā)現(xiàn)以及健康情況管理、監(jiān)控(單機和集群)，規(guī)則管理和推送的功能。這里，我們將會詳細(xì)講述如何通過簡單的步驟就可以使用這些功能。
Sentinel 控制臺包含如下功能:
- 查看機器列表以及健康情況：收集 Sentinel 客戶端發(fā)送的心跳包，用于判斷機器是否在線。
- 監(jiān)控 (單機和集群聚合)：通過 Sentinel 客戶端暴露的監(jiān)控 API，定期拉取并且聚合應(yīng)用監(jiān)控信息，最終可以實現(xiàn)秒級的實時監(jiān)控。
- 規(guī)則管理和推送：統(tǒng)一管理推送規(guī)則。
- 鑒權(quán)：生產(chǎn)環(huán)境中鑒權(quán)非常重要。這里每個開發(fā)者需要根據(jù)自己的實際情況進行定制。
注意：Sentinel 控制臺目前僅支持單機部署。Sentinel 控制臺項目提供 Sentinel 功能全集示例，不作為開箱即用的生產(chǎn)環(huán)境控制臺，若希望在生產(chǎn)環(huán)境使用需要自行定制和改造。
Alibaba 提供了企業(yè)版本的 Sentinel 我們可以在 aliyun.com 上面購買 AHAS Sentinel
查看機器列表以及健康情況
如果我們正確的接入 Sentinel 之后我們可以在 Sentinel 控制臺的 機器列表 菜單中來查看我們服務(wù)節(jié)點的健康情況
如果 Sentinel 接入不成功，可以查閱 Sentinel 官方文檔或者 FAQ 來對應(yīng)排查
服務(wù)監(jiān)控
1. 實時監(jiān)控
同時，同一個服務(wù)下的所有機器的簇點信息會被匯總，并且秒級地展示在"實時監(jiān)控"下。
注意: 實時監(jiān)控僅存儲 5 分鐘以內(nèi)的數(shù)據(jù)，如果需要持久化，需要通過調(diào)用實時監(jiān)控接口來定制。
注意：請確保 Sentinel 控制臺所在的機器時間與自己應(yīng)用的機器時間保持一致，否則會導(dǎo)致拉不到實時的監(jiān)控數(shù)據(jù)。
2. 簇點鏈路
簇點鏈路(單機調(diào)用鏈路)頁面實時的去拉取指定客戶端資源的運行情況。它一共提供兩種展示模式：一種用樹狀結(jié)構(gòu)展示資源的調(diào)用鏈路，另外一種則不區(qū)分調(diào)用鏈路展示資源的實時情況。
注意: 簇點鏈路監(jiān)控是內(nèi)存態(tài)的信息，它僅展示啟動后調(diào)用過的資源。
注意：請確保 Sentinel 控制臺所在的機器時間與自己應(yīng)用的機器時間保持一致，否則會導(dǎo)致拉不到實時的監(jiān)控數(shù)據(jù)。
3 流控規(guī)則
流量控制(flow control)，其原理是監(jiān)控應(yīng)用流量的 QPS 或并發(fā)線程數(shù)等指標(biāo)，當(dāng)達(dá)到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應(yīng)用的高可用性。
FlowSlot 會根據(jù)預(yù)設(shè)的規(guī)則，結(jié)合 NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot 統(tǒng)計出來的實時信息進行流量控制。
限流的直接表現(xiàn)是在執(zhí)行 Entry nodeA = SphU.entry(resourceName) 的時候拋出 FlowException 異常。FlowException 是 BlockException 的子類，您可以捕捉 BlockException 來自定義被限流之后的處理邏輯。
Sentinel 在觸發(fā)規(guī)則保護時，返回的異常頁面是一樣的。不好區(qū)分是因為哪種規(guī)則導(dǎo)致的異常。所以需要自定義異常返回信息，明確是觸發(fā)了哪種類型的規(guī)則。
- @Component
- public class SentinelBlockHandler implements BlockExceptionHandler {
- @Override
- public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse,
- BlockException e) throws Exception {
- CommonResult
result = new CommonResult<>(); - if (e instanceof FlowException) {
- result = CommonResult.error(101, "接口限流了");
- } else if (e instanceof DegradeException) {
- result = CommonResult.error(102, "服務(wù)降級了");
- } else if (e instanceof ParamFlowException) {
- result = CommonResult.error(103, "熱點參數(shù)限流了");
- } else if (e instanceof SystemBlockException) {
- result = CommonResult.error(104, "系統(tǒng)規(guī)則（負(fù)載/...不滿足要求）");
- } else if (e instanceof AuthorityException) {
- result = CommonResult.error(105, "授權(quán)規(guī)則不通過");
- }
- // http狀態(tài)碼
- httpServletResponse.setStatus(500);
- httpServletResponse.setCharacterEncoding("utf-8");
- httpServletResponse.setHeader("Content-Type", "application/json;charset=utf-8");
- httpServletResponse.setContentType("application/json;charset=utf-8");
- // spring mvc自帶的json操作工具，叫jackson
- new ObjectMapper().writeValue(httpServletResponse.getWriter(), result);
- }
- }
效果如下：
- curl http://127.0.0.1:8088/getStockDetail
- {"code":1,"message":"this is a success message","data":{"id":1,"code":"STOCK==>1000"}}% curl http://127.0.0.1:8088/getStockDetail
- {"code":1,"message":"this is a success message","data":{"id":1,"code":"STOCK==>1000"}}% curl http://127.0.0.1:8088/getStockDetail
- {"code":101,"message":"接口限流了","data":null}%
閾值類型
線程數(shù)
并發(fā)數(shù)控制用于保護業(yè)務(wù)線程池不被慢調(diào)用耗盡。例如，當(dāng)應(yīng)用所依賴的下游應(yīng)用由于某種原因?qū)е路?wù)不穩(wěn)定、響應(yīng)延遲增加，對于調(diào)用者來說，意味著吞吐量下降和更多的線程數(shù)占用，極端情況下甚至導(dǎo)致線程池耗盡。為應(yīng)對太多線程占用的情況，業(yè)內(nèi)有使用隔離的方案，比如通過不同業(yè)務(wù)邏輯使用不同線程池來隔離業(yè)務(wù)自身之間的資源爭搶(線程池隔離)。這種隔離方案雖然隔離性比較好，但是代價就是線程數(shù)目太多，線程上下文切換的 overhead 比較大，特別是對低延時的調(diào)用有比較大的影響。Sentinel 并發(fā)控制不負(fù)責(zé)創(chuàng)建和管理線程池，而是簡單統(tǒng)計當(dāng)前請求上下文的線程數(shù)目(正在執(zhí)行的調(diào)用數(shù)目)，如果超出閾值，新的請求會被立即拒絕，效果類似于信號量隔離。并發(fā)數(shù)控制通常在調(diào)用端進行配置。
可以通過線程池模擬客戶端調(diào)用， 也可以通過 Jmeter 模擬，觸發(fā)流控的結(jié)果如下：
- ~ curl http://127.0.0.1:8088/getStockDetail
- {"code":101,"message":"接口限流了","data":null}%
流控模式
調(diào)用關(guān)系包括調(diào)用方、被調(diào)用方;一個方法又可能會調(diào)用其它方法，形成一個調(diào)用鏈路的層次關(guān)系。
直接
當(dāng)資源觸發(fā)流控規(guī)則過后直接，拋出異常信息
- ~ curl http://127.0.0.1:8088/getStockDetail
- {"code":101,"message":"接口限流了","data":null}%
關(guān)聯(lián)
當(dāng)兩個資源之間具有資源爭搶或者依賴關(guān)系的時候，這兩個資源便具有了關(guān)聯(lián)。比如對數(shù)據(jù)庫同一個字段的讀操作和寫操作存在爭搶，讀的速度過高會影響寫的速度，寫的速度過高會影響讀的速度。如果放任讀寫操作爭搶資源，則爭搶本身帶來的開銷會降低整體的吞吐量?？墒褂藐P(guān)聯(lián)限流來避免具有關(guān)聯(lián)關(guān)系的資源之間過度的爭搶，舉例來說，read_db 和 write_db 這兩個資源分別代表數(shù)據(jù)庫讀寫，我們可以給 read_db 設(shè)置限流規(guī)則來達(dá)到寫優(yōu)先的目的：設(shè)置 strategy 為 RuleConstant.STRATEGY_RELATE 同時設(shè)置 refResource 為 write_db。這樣當(dāng)寫庫操作過于頻繁時，讀數(shù)據(jù)的請求會被限流。
如果配置流控規(guī)則為關(guān)聯(lián)模式，那么當(dāng) /hello 接口超過閾值過后，就會對 /getStockDetail 接口觸發(fā)流控規(guī)則。
鏈路
NodeSelectorSlot 中記錄了資源之間的調(diào)用鏈路，這些資源通過調(diào)用關(guān)系，相互之間構(gòu)成一棵調(diào)用樹。這棵樹的根節(jié)點是一個名字為 machine-root 的虛擬節(jié)點，調(diào)用鏈的入口都是這個虛節(jié)點的子節(jié)點。
一棵典型的調(diào)用樹如下圖所示：
- machine-root
- / \
- / \
- Entrance1 Entrance2
- / \
- / \
- DefaultNode(nodeA) DefaultNode(nodeA)
上圖中來自入口 Entrance1 和 Entrance2 的請求都調(diào)用到了資源 NodeA，Sentinel 允許只根據(jù)某個入口的統(tǒng)計信息對資源限流。比如我們可以設(shè)置 strategy 為 RuleConstant.STRATEGY_CHAIN，同時設(shè)置 refResource 為 Entrance1 來表示只有從入口 Entrance1 的調(diào)用才會記錄到 NodeA 的限流統(tǒng)計當(dāng)中，而不關(guān)心經(jīng) Entrance2 到來的調(diào)用。
調(diào)用鏈的入口(上下文)是通過 API 方法 ContextUtil.enter(contextName) 定義的，其中 contextName 即對應(yīng)調(diào)用鏈路入口名稱。詳情可以參考 ContextUtil 文檔。]
測試會發(fā)現(xiàn) 鏈路 不會生效
從1.6.3版本開始，Sentinel Web filter默認(rèn)收斂所有URL的入口context，因此鏈路限流不生效。1.7.0版本開始(對應(yīng)SCA 2.1.1.RELEASE)，我們在CommonFilter引入了WEB_CONTEXT_UNIFY這個init parameter，用于控制是否收斂context。將其配置為false即可根據(jù)不同的URL進行鏈路限流。參考：https://github.com/alibaba/sentinel/issues/1213
解決方案：
1.7.0 版本開始(對應(yīng)Spring Cloud Alibaba的2.1.1.RELEASE) 需要新增依賴
- @Configuration
- public class FilterContextConfig {
- @Bean
- public FilterRegistrationBean sentinelFilterRegistration() {
- FilterRegistrationBean registration = new FilterRegistrationBean();
- registration.setFilter(new CommonFilter());
- registration.addUrlPatterns("/*");
- // 入口資源關(guān)閉聚合
- registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");
- registration.setName("sentinelFilter");
- registration.setOrder(1);
- return registration;
- }
- }
然后我們再嘗試觸發(fā)流控規(guī)則， 對 /getStockDetail 進行訪問，這里返回了FlowException
默認(rèn)情況會返回
如果我們使用 OpenFeign 不添加 fallbackFactory 就會返回500 , 如果我們添加了就可以避免這個問題。
- // Controller
- @Autowired
- private StockFeign stockFeign;
- @GetMapping("/getStockDetail")
- public CommonResult
getStockDetail() { - CommonResult
result = stockFeign.getStockDetail(); - if (result.getCode() != 1) {
- return CommonResult.error(null, result.getCode(), result.getMessage());
- }
- return result;
- }
- // FeignClient
- @FeignClient(name = "stock-service")
- //, fallbackFactory = StockFeignFallbackFactory.class)
- public interface StockFeign {
- @GetMapping("/getStockDetail")
- CommonResult
getStockDetail(); - }
Sentinel 部分源碼：
所以，我們在設(shè)置鏈路流控規(guī)則的時候一定要設(shè)置 fallbackFactory。不然無法處理 FlowExecption 異常信息，造成系統(tǒng)出錯。對于個人而言，Sentinel 的鏈路規(guī)則比不是特別的好用，無特殊要求，不建議使用，或者選擇Sentinel 的收費版本 AHAS
流控效果
當(dāng) QPS、線程數(shù)超過某個閾值的時候，則采取措施進行流量控制。流量控制的效果包括以下幾種：直接拒絕、Warm Up、勻速排隊。
直接拒絕
直接拒絕(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)方式是默認(rèn)的流量控制方式，當(dāng)QPS超過任意規(guī)則的閾值后，新的請求就會被立即拒絕，拒絕方式為拋出FlowException。 這種方式適用于對系統(tǒng)處理能力確切已知的情況下，比如通過壓測確定了系統(tǒng)的準(zhǔn)確水位時。
Warm up
Warm Up(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)方式，即預(yù)熱/冷啟動方式。當(dāng)系統(tǒng)長期處于低水位的情況下，當(dāng)流量突然增加時，直接把系統(tǒng)拉升到高水位可能瞬間把系統(tǒng)壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內(nèi)逐漸增加到閾值上限，給冷系統(tǒng)一個預(yù)熱的時間，避免冷系統(tǒng)被壓垮。
通常冷啟動的過程系統(tǒng)允許通過的 QPS 曲線如下圖所示：
默認(rèn) coldFactor 為 3，即請求 QPS 從 threshold / 3 開始，經(jīng)預(yù)熱時長逐漸升至設(shè)定的 QPS 閾值。
規(guī)則設(shè)置如下圖所示：
通過 Jmeter 請求過后，可以看到如下效果，完成流控
勻速排隊
勻速排隊(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式會嚴(yán)格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應(yīng)的是漏桶算法。
這種方式主要用于處理間隔性突發(fā)的流量，例如消息隊列。想象一下這樣的場景，在某一秒有大量的請求到來，而接下來的幾秒則處于空閑狀態(tài)，我們希望系統(tǒng)能夠在接下來的空閑期間逐漸處理這些請求，而不是在第一秒直接拒絕多余的請求。
注意：勻速排隊模式暫時不支持 QPS > 1000 的場景。
規(guī)則設(shè)置如下圖所示：
然后我們通過 jmeter 請求過后可以看到如下效果：
4. 降級規(guī)則
流量控制以外，對調(diào)用鏈路中不穩(wěn)定的資源進行熔斷降級也是保障高可用的重要措施之一。一個服務(wù)常常會調(diào)用別的模塊，可能是另外的一個遠(yuǎn)程服務(wù)、數(shù)據(jù)庫，或者第三方 API 等。例如，支付的時候，可能需要遠(yuǎn)程調(diào)用銀聯(lián)提供的 API;查詢某個商品的價格，可能需要進行數(shù)據(jù)庫查詢。然而，這個被依賴服務(wù)的穩(wěn)定性是不能保證的。如果依賴的服務(wù)出現(xiàn)了不穩(wěn)定的情況，請求的響應(yīng)時間變長，那么調(diào)用服務(wù)的方法的響應(yīng)時間也會變長，線程會產(chǎn)生堆積，最終可能耗盡業(yè)務(wù)自身的線程池，服務(wù)本身也變得不可用。
熔斷降級策略
Sentinel 提供以下幾種熔斷策略：
- 慢調(diào)用比例 (SLOW_REQUEST_RATIO)：選擇以慢調(diào)用比例作為閾值，需要設(shè)置允許的慢調(diào)用 RT(即最大的響應(yīng)時間)，請求的響應(yīng)時間大于該值則統(tǒng)計為慢調(diào)用。當(dāng)單位統(tǒng)計時長(statIntervalMs)內(nèi)請求數(shù)目大于設(shè)置的最小請求數(shù)目，并且慢調(diào)用的比例大于閾值，則接下來的熔斷時長內(nèi)請求會自動被熔斷。經(jīng)過熔斷時長后熔斷器會進入探測恢復(fù)狀態(tài)(HALF-OPEN 狀態(tài))，若接下來的一個請求響應(yīng)時間小于設(shè)置的慢調(diào)用 RT 則結(jié)束熔斷，若大于設(shè)置的慢調(diào)用 RT 則會再次被熔斷。
我們可以在控制臺配置：
jmeter 模擬請求
異常比例 (ERROR_RATIO)：當(dāng)單位統(tǒng)計時長(statIntervalMs)內(nèi)請求數(shù)目大于設(shè)置的最小請求數(shù)目，并且異常的比例大于閾值，則接下來的熔斷時長內(nèi)請求會自動被熔斷。經(jīng)過熔斷時長后熔斷器會進入探測恢復(fù)狀態(tài)(HALF-OPEN 狀態(tài))，若接下來的一個請求成功完成(沒有錯誤)則結(jié)束熔斷，否則會再次被熔斷。異常比率的閾值范圍是 [0.0, 1.0]，代表 0% - 100%。
我們可以在控制臺配置：
- 異常數(shù) (ERROR_COUNT)：當(dāng)單位統(tǒng)計時長內(nèi)的異常數(shù)目超過閾值之后會自動進行熔斷。經(jīng)過熔斷時長后熔斷器會進入探測恢復(fù)狀態(tài)(HALF-OPEN 狀態(tài))，若接下來的一個請求成功完成(沒有錯誤)則結(jié)束熔斷，否則會再次被熔斷。
我們可以在控制臺配置：
熔斷降級說明
熔斷降級規(guī)則(DegradeRule)包含下面幾個重要的屬性：
|
Field |
說明 |
默認(rèn)值 |
|
resource |
資源名，即規(guī)則的作用對象 |
|
|
grade |
熔斷策略，支持慢調(diào)用比例/異常比例/異常數(shù)策略 |
慢調(diào)用比例 |
|
count |
慢調(diào)用比例模式下為慢調(diào)用臨界 RT（超出該值計為慢調(diào)用）；異常比例/異常數(shù)模式下為對應(yīng)的閾值 |
|
|
timeWindow |
熔斷時長，單位為 s |
|
|
minRequestAmount |
熔斷觸發(fā)的最小請求數(shù)，請求數(shù)小于該值時即使異常比率超出閾值也不會熔斷（1.7.0 引入） |
5 |
|
statIntervalMs |
統(tǒng)計時長（單位為 ms），如 60*1000 代表分鐘級（1.8.0 引入） |
1000 ms |
|
slowRatioThreshold |
慢調(diào)用比例閾值，僅慢調(diào)用比例模式有效（1.8.0 引入） |
5. 熱點規(guī)則
何為熱點?熱點即經(jīng)常訪問的數(shù)據(jù)。很多時候我們希望統(tǒng)計某個熱點數(shù)據(jù)中訪問頻次最高的 Top K 數(shù)據(jù)，并對其訪問進行限制。比如：
- 商品 ID 為參數(shù)，統(tǒng)計一段時間內(nèi)最常購買的商品 ID 并進行限制
- 用戶 ID 為參數(shù)，針對一段時間內(nèi)頻繁訪問的用戶 ID 進行限制
熱點參數(shù)限流會統(tǒng)計傳入?yún)?shù)中的熱點參數(shù)，并根據(jù)配置的限流閾值與模式，對包含熱點參數(shù)的資源調(diào)用進行限流。熱點參數(shù)限流可以看做是一種特殊的流量控制，僅對包含熱點參數(shù)的資源調(diào)用生效。
Sentinel 利用 LRU 策略統(tǒng)計最近最常訪問的熱點參數(shù)，結(jié)合令牌桶算法來進行參數(shù)級別的流控。熱點參數(shù)限流支持集群模式。
熱點規(guī)則配置需要注意：
1. 首先資源必須是通過 @SentinelResource 申明
2. 參數(shù)類型必須是基礎(chǔ)數(shù)據(jù)類型， 否則配置無效
熱點規(guī)則配置如下圖所示：
注意：資源名稱要和 @SentinelResource 中的資源名稱對應(yīng)才能生效
控制器類的代碼如下所示：
- @SentinelResource(value = "ResOrderGet",
- fallback = "fallback",
- fallbackClass = SentinelExceptionHandler.class,
- blockHandler = "blockHandler",
- blockHandlerClass = SentinelExceptionHandler.class
- )
- @GetMapping("/order/get/{id}")
- public CommonResult
getStockDetails(@PathVariable Integer id) { - StockModel stockModel = new StockModel();
- stockModel.setCode("STOCK==>1000");
- stockModel.setId(id);
- return CommonResult.success(stockModel);
- }
- // 異常處理類
- public class SentinelResourceExceptionHandler {
- //限流熔斷業(yè)務(wù)邏輯
- public static CommonResult
blockHandler(@PathVariable Integer id) { - return CommonResult.error(null, -100, "系統(tǒng)錯誤 (限流熔斷業(yè)務(wù)邏輯)");
- }
- //異常降級業(yè)務(wù)邏輯
- public static CommonResult
fallback(@PathVariable Integer id) { - return CommonResult.error(null, -100, "系統(tǒng)錯誤 (異常降級業(yè)務(wù)邏輯)");
- }
- }
返回異常信息：
6 授權(quán)規(guī)則
很多時候，我們需要根據(jù)調(diào)用來源來判斷該次請求是否允許放行，這時候可以使用 Sentinel 的來源訪問控制(黑白名單控制)的功能。來源訪問控制根據(jù)資源的請求來源(origin)限制資源是否通過，若配置白名單則只有請求來源位于白名單內(nèi)時才可通過;若配置黑名單則請求來源位于黑名單時不通過，其余的請求通過。
調(diào)用方信息通過 ContextUtil.enter(resourceName, origin) 方法中的 origin 參數(shù)傳入。
Sentinel提供了 RequestOriginParser 接口來處理訪問來源，Sentinel保護的資源如果被訪問，就會調(diào)用 RequestOriginParser解析訪問來源。
- // 注意導(dǎo)包
- import com.alibaba.csp.sentinel.adapter.servlet.callback.RequestOriginParser;
- import javax.servlet.http.HttpServletRequest;
- public class SentinelRequestOriginParser implements RequestOriginParser {
- @Override
- public String parseOrigin(HttpServletRequest request) {
- return request.getParameter("origin");
- }
- }
修改 Config 配置信息
- @Configuration
- public class FilterContextConfig {
- @Bean
- public FilterRegistrationBean sentinelFilterRegistration() {
- FilterRegistrationBean registration = new FilterRegistrationBean();
- registration.setFilter(new CommonFilter());
- registration.addUrlPatterns("/*");
- // 入口資源關(guān)閉聚合
- registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");
- registration.setName("sentinelFilter");
- registration.setOrder(1);
- // CommonFilter 的 BlockException 自定義處理邏輯
- WebCallbackManager.setUrlBlockHandler(new SentinelFlowHandler());
- //解決授權(quán)規(guī)則不生效的問題
- //com.alibaba.csp.sentinel.adapter.servlet.callback.RequestOriginParser
- WebCallbackManager.setRequestOriginParser(new SentinelRequestOriginParser());
- return registration;
- }
- }
規(guī)則配置
執(zhí)行請求
正常通過
異常不通過
7 系統(tǒng)規(guī)則
系統(tǒng)保護規(guī)則是從應(yīng)用級別的入口流量進行控制，從單臺機器的 load、CPU 使用率、平均 RT、入口 QPS 和并發(fā)線程數(shù)等幾個維度監(jiān)控應(yīng)用指標(biāo)，讓系統(tǒng)盡可能跑在最大吞吐量的同時保證系統(tǒng)整體的穩(wěn)定性。
系統(tǒng)保護規(guī)則是應(yīng)用整體維度的，而不是資源維度的，并且僅對入口流量生效。入口流量指的是進入應(yīng)用的流量(EntryType.IN)，比如 Web 服務(wù)或 Dubbo 服務(wù)端接收的請求，都屬于入口流量。
系統(tǒng)規(guī)則支持以下的模式：
- Load 自適應(yīng)(僅對 Linux/Unix-like 機器生效)：系統(tǒng)的 load1 作為啟發(fā)指標(biāo)，進行自適應(yīng)系統(tǒng)保護。當(dāng)系統(tǒng) load1 超過設(shè)定的啟發(fā)值，且系統(tǒng)當(dāng)前的并發(fā)線程數(shù)超過估算的系統(tǒng)容量時才會觸發(fā)系統(tǒng)保護(BBR 階段)。系統(tǒng)容量由系統(tǒng)的 maxQps * minRt 估算得出。設(shè)定參考值一般是 CPU cores * 2.5。
- CPU usage(1.5.0+ 版本)：當(dāng)系統(tǒng) CPU 使用率超過閾值即觸發(fā)系統(tǒng)保護(取值范圍 0.0-1.0)，比較靈敏。
- 平均 RT：當(dāng)單臺機器上所有入口流量的平均 RT 達(dá)到閾值即觸發(fā)系統(tǒng)保護，單位是毫秒。
- 并發(fā)線程數(shù)：當(dāng)單臺機器上所有入口流量的并發(fā)線程數(shù)達(dá)到閾值即觸發(fā)系統(tǒng)保護。
- 入口 QPS：當(dāng)單臺機器上所有入口流量的 QPS 達(dá)到閾值即觸發(fā)系統(tǒng)保護。
原理
如下圖所示
我們把系統(tǒng)處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當(dāng)系統(tǒng)處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的;反之，當(dāng)請求堆積的時候，那么處理請求的時間則會變?yōu)椋号抨爼r間 + 最短處理時間。
- 推論一: 如果我們能夠保證水管里的水量，能夠讓水順暢的流動，則不會增加排隊的請求;也就是說，這個時候的系統(tǒng)負(fù)載不會進一步惡化。
我們用 T 來表示(水管內(nèi)部的水量)，用RT來表示請求的處理時間，用P來表示進來的請求數(shù)，那么一個請求從進入水管道到從水管出來，這個水管會存在 P * RT 個請求。換一句話來說，當(dāng) T ≈ QPS * Avg(RT) 的時候，我們可以認(rèn)為系統(tǒng)的處理能力和允許進入的請求個數(shù)達(dá)到了平衡，系統(tǒng)的負(fù)載不會進一步惡化。
接下來的問題是，水管的水位是可以達(dá)到了一個平衡點，但是這個平衡點只能保證水管的水位不再繼續(xù)增高，但是還面臨一個問題，就是在達(dá)到平衡點之前，這個水管里已經(jīng)堆積了多少水。如果之前水管的水已經(jīng)在一個量級了，那么這個時候系統(tǒng)允許通過的水量可能只能緩慢通過，RT會大，之前堆積在水管里的水會滯留;反之，如果之前的水管水位偏低，那么又會浪費了系統(tǒng)的處理能力。
- 推論二: 當(dāng)保持入口的流量是水管出來的流量的最大的值的時候，可以最大利用水管的處理能力。
然而，和 TCP BBR 的不一樣的地方在于，還需要用一個系統(tǒng)負(fù)載的值(load1)來激發(fā)這套機制啟動。
注：這種系統(tǒng)自適應(yīng)算法對于低 load 的請求，它的效果是一個“兜底”的角色。對于不是應(yīng)用本身造成的 load 高的情況(如其它進程導(dǎo)致的不穩(wěn)定的情況)，效果不明顯。
配置頁面
觸發(fā)流控規(guī)則
8 集群流控
為什么要使用集群流控呢?假設(shè)我們希望給某個用戶限制調(diào)用某個 API 的總 QPS 為 50，但機器數(shù)可能很多(比如有 100 臺)。這時候我們很自然地就想到，找一個 server 來專門來統(tǒng)計總的調(diào)用量，其它的實例都與這臺 server 通信來判斷是否可以調(diào)用。這就是最基礎(chǔ)的集群流控的方式。
另外集群流控還可以解決流量不均勻?qū)е驴傮w限流效果不佳的問題。假設(shè)集群中有 10 臺機器，我們給每臺機器設(shè)置單機限流閾值為 10 QPS，理想情況下整個集群的限流閾值就為 100 QPS。不過實際情況下流量到每臺機器可能會不均勻，會導(dǎo)致總量沒有到的情況下某些機器就開始限流。因此僅靠單機維度去限制的話會無法精確地限制總體流量。而集群流控可以精確地控制整個集群的調(diào)用總量，結(jié)合單機限流兜底，可以更好地發(fā)揮流量控制的效果。
集群流控中共有兩種身份：
- Token Client：集群流控客戶端，用于向所屬 Token Server 通信請求 token。集群限流服務(wù)端會返回給客戶端結(jié)果，決定是否限流。
- Token Server：即集群流控服務(wù)端，處理來自 Token Client 的請求，根據(jù)配置的集群規(guī)則判斷是否應(yīng)該發(fā)放 token(是否允許通過)。
規(guī)則推送
Sentinel 控制臺同時提供簡單的規(guī)則管理以及推送的功能。規(guī)則推送分為 3 種模式，包括 "原始模式"、"Pull 模式" 和"Push 模式"。
這里先簡單的介紹"原始模式"。
規(guī)則管理
您可以在控制臺通過接入端暴露的 HTTP API 來查詢規(guī)則。
規(guī)則推送
目前控制臺的規(guī)則推送也是通過 規(guī)則查詢更改 HTTP API 來更改規(guī)則。這也意味著這些規(guī)則僅在內(nèi)存態(tài)生效，應(yīng)用重啟之后，該規(guī)則會丟失。
注：若通過控制臺推送規(guī)則時出現(xiàn) invalid type 或 empty type 的錯誤，請確保 transport 模塊版本與 core 模塊版本保持一致;若控制臺版本 >= 1.7.1，請將接入端的相關(guān)依賴也升級至 1.7.1 及以上版本。
以上是原始模式。當(dāng)了解了原始模式之后，我們非常鼓勵您通過 動態(tài)規(guī)則 并結(jié)合各種外部存儲來定制自己的規(guī)則源。我們推薦通過動態(tài)配置源的控制臺來進行規(guī)則寫入和推送，而不是通過 Sentinel 客戶端直接寫入到動態(tài)配置源中。在生產(chǎn)環(huán)境中，我們推薦 push 模式，具體可以參考：在生產(chǎn)環(huán)境使用 Sentinel。
注：若要使用集群流控功能，則必須對接動態(tài)規(guī)則源，否則無法正常使用。您也可以接入 AHAS Sentinel 快速接入全自動托管、高可用的集群流控能力。
Sentinel 同時還提供應(yīng)用維度規(guī)則推送的示例頁面(流控規(guī)則頁面，前端路由為 /v2/flow)，用戶改造控制臺對接配置中心后可直接通過 v2 頁面推送規(guī)則至配置中心。Sentinel 抽取了通用接口用于向遠(yuǎn)程配置中心推送規(guī)則以及拉取規(guī)則：
DynamicRuleProvider : 拉取規(guī)則(應(yīng)用維度)
DynamicRulePublisher : 推送規(guī)則(應(yīng)用維度)
用戶只需實現(xiàn) DynamicRuleProvider 和 DynamicRulePublisher 接口，并在 v2 的 controller 中通過 @Qualifier 注解替換相應(yīng)的 bean 即可實現(xiàn)應(yīng)用維度推送。我們提供了 Nacos 和 Apollo 的示例，改造詳情可參考 應(yīng)用維度規(guī)則推送示例。
鑒權(quán)
從 Sentinel 1.5.0 開始，控制臺提供通用的鑒權(quán)接口 AuthService，用戶可根據(jù)需求自行實現(xiàn)。
從 Sentinel 1.6.0 起，Sentinel 控制臺引入基本的登錄功能，默認(rèn)用戶名和密碼都是 sentinel。該鑒權(quán)能力非?；A(chǔ)，生產(chǎn)環(huán)境使用建議根據(jù)安全需要自行改造。
用戶可以通過如下參數(shù)進行配置：
- -Dsentinel.dashboard.auth.username=sentinel 用于指定控制臺的登錄用戶名為 sentinel;
- -Dsentinel.dashboard.auth.password=123456 用于指定控制臺的登錄密碼為 123456;如果省略這兩個參數(shù)，默認(rèn)用戶和密碼均為 sentinel;
- -Dserver.servlet.session.timeout=7200 用于指定 Spring Boot 服務(wù)端 session 的過期時間，如 7200 表示 7200 秒;60m 表示 60 分鐘，默認(rèn)為 30 分鐘;
同樣也可以直接在 Spring properties 文件中進行配置。
注意：部署多臺控制臺時，session 默認(rèn)不會在各實例之間共享，這一塊需要自行改造。
參考文檔
https://github.com/alibaba/Sentinel/wiki/控制臺
本文名稱：Sentinel流控規(guī)則詳解
網(wǎng)址分享：http://www.fisionsoft.com.cn/article/dhojgdj.html
