Sentinel流控規則的介紹

這篇文章主要講解了“Sentinel流控規則的介紹”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Sentinel流控規則的介紹”吧！

在正文開始之前，我先說一下我的基本環境信息

• 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  提供一個輕量級的開源控制臺，它提供機器發現以及健康情況管理、監控(單機和集群)，規則管理和推送的功能。這里，我們將會詳細講述如何通過簡單的步驟就可以使用這些功能。

Sentinel 控制臺包含如下功能:

• 查看機器列表以及健康情況：收集 Sentinel 客戶端發送的心跳包，用于判斷機器是否在線。

• 監控 (單機和集群聚合)：通過 Sentinel 客戶端暴露的監控 API，定期拉取并且聚合應用監控信息，最終可以實現秒級的實時監控。

• 規則管理和推送：統一管理推送規則。

• 鑒權：生產環境中鑒權非常重要。這里每個開發者需要根據自己的實際情況進行定制。

注意：Sentinel 控制臺目前僅支持單機部署。Sentinel 控制臺項目提供 Sentinel  功能全集示例，不作為開箱即用的生產環境控制臺，若希望在生產環境使用需要自行定制和改造。

Alibaba 提供了企業版本的 Sentinel 我們可以在 aliyun.com 上面購買 AHAS Sentinel

查看機器列表以及健康情況

如果我們正確的接入 Sentinel 之后我們可以在 Sentinel 控制臺的 機器列表 菜單中來查看我們服務節點的健康情況

如果 Sentinel 接入不成功，可以查閱 Sentinel 官方文檔或者 FAQ 來對應排查

服務監控

1. 實時監控

同時，同一個服務下的所有機器的簇點信息會被匯總，并且秒級地展示在"實時監控"下。

注意: 實時監控僅存儲 5 分鐘以內的數據，如果需要持久化，需要通過調用實時監控接口來定制。

注意：請確保 Sentinel 控制臺所在的機器時間與自己應用的機器時間保持一致，否則會導致拉不到實時的監控數據。

2. 簇點鏈路

簇點鏈路(單機調用鏈路)頁面實時的去拉取指定客戶端資源的運行情況。它一共提供兩種展示模式：一種用樹狀結構展示資源的調用鏈路，另外一種則不區分調用鏈路展示資源的實時情況。

注意: 簇點鏈路監控是內存態的信息，它僅展示啟動后調用過的資源。

注意：請確保 Sentinel 控制臺所在的機器時間與自己應用的機器時間保持一致，否則會導致拉不到實時的監控數據。

3 流控規則

流量控制(flow control)，其原理是監控應用流量的 QPS  或并發線程數等指標，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應用的高可用性。

FlowSlot 會根據預設的規則，結合 NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot  統計出來的實時信息進行流量控制。

限流的直接表現是在執行 Entry nodeA = SphU.entry(resourceName) 的時候拋出 FlowException  異常。FlowException 是 BlockException 的子類，您可以捕捉 BlockException 來自定義被限流之后的處理邏輯。

Sentinel  在觸發規則保護時，返回的異常頁面是一樣的。不好區分是因為哪種規則導致的異常。所以需要自定義異常返回信息，明確是觸發了哪種類型的規則。

@Component public class SentinelBlockHandler implements BlockExceptionHandler {     @Override     public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse,                        BlockException e) throws Exception {         CommonResult<Void> result = new CommonResult<>();         if (e instanceof FlowException) {             result = CommonResult.error(101, "接口限流了");         } else if (e instanceof DegradeException) {             result = CommonResult.error(102, "服務降級了");         } else if (e instanceof ParamFlowException) {             result = CommonResult.error(103, "熱點參數限流了");         } else if (e instanceof SystemBlockException) {             result = CommonResult.error(104, "系統規則（負載/...不滿足要求）");         } else if (e instanceof AuthorityException) {             result = CommonResult.error(105, "授權規則不通過");         }         // http狀態碼         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}%

閾值類型

線程數

并發數控制用于保護業務線程池不被慢調用耗盡。例如，當應用所依賴的下游應用由于某種原因導致服務不穩定、響應延遲增加，對于調用者來說，意味著吞吐量下降和更多的線程數占用，極端情況下甚至導致線程池耗盡。為應對太多線程占用的情況，業內有使用隔離的方案，比如通過不同業務邏輯使用不同線程池來隔離業務自身之間的資源爭搶(線程池隔離)。這種隔離方案雖然隔離性比較好，但是代價就是線程數目太多，線程上下文切換的  overhead 比較大，特別是對低延時的調用有比較大的影響。Sentinel  并發控制不負責創建和管理線程池，而是簡單統計當前請求上下文的線程數目(正在執行的調用數目)，如果超出閾值，新的請求會被立即拒絕，效果類似于信號量隔離。并發數控制通常在調用端進行配置。

可以通過線程池模擬客戶端調用， 也可以通過 Jmeter 模擬，觸發流控的結果如下：

?  ~ curl http://127.0.0.1:8088/getStockDetail {"code":101,"message":"接口限流了","data":null}%

流控模式

調用關系包括調用方、被調用方;一個方法又可能會調用其它方法，形成一個調用鏈路的層次關系。

直接

當資源觸發流控規則過后直接，拋出異常信息

?  ~ curl http://127.0.0.1:8088/getStockDetail {"code":101,"message":"接口限流了","data":null}%

關聯

當兩個資源之間具有資源爭搶或者依賴關系的時候，這兩個資源便具有了關聯。比如對數據庫同一個字段的讀操作和寫操作存在爭搶，讀的速度過高會影響寫的速度，寫的速度過高會影響讀的速度。如果放任讀寫操作爭搶資源，則爭搶本身帶來的開銷會降低整體的吞吐量。可使用關聯限流來避免具有關聯關系的資源之間過度的爭搶，舉例來說，read_db  和 write_db 這兩個資源分別代表數據庫讀寫，我們可以給 read_db 設置限流規則來達到寫優先的目的：設置 strategy 為  RuleConstant.STRATEGY_RELATE 同時設置 refResource 為  write_db。這樣當寫庫操作過于頻繁時，讀數據的請求會被限流。

如果配置流控規則為關聯模式，那么當 /hello 接口超過閾值過后，就會對 /getStockDetail 接口觸發流控規則。

鏈路

NodeSelectorSlot 中記錄了資源之間的調用鏈路，這些資源通過調用關系，相互之間構成一棵調用樹。這棵樹的根節點是一個名字為  machine-root 的虛擬節點，調用鏈的入口都是這個虛節點的子節點。

一棵典型的調用樹如下圖所示：

machine-root                    /       \                   /         \             Entrance1     Entrance2                /             \               /               \      DefaultNode(nodeA)   DefaultNode(nodeA)

上圖中來自入口 Entrance1 和 Entrance2 的請求都調用到了資源 NodeA，Sentinel  允許只根據某個入口的統計信息對資源限流。比如我們可以設置 strategy 為 RuleConstant.STRATEGY_CHAIN，同時設置  refResource 為 Entrance1 來表示只有從入口 Entrance1 的調用才會記錄到 NodeA 的限流統計當中，而不關心經  Entrance2 到來的調用。

調用鏈的入口(上下文)是通過 API 方法 ContextUtil.enter(contextName) 定義的，其中 contextName  即對應調用鏈路入口名稱。詳情可以參考 ContextUtil 文檔。]

測試會發現 鏈路 不會生效

從1.6.3版本開始，Sentinel Web filter默認收斂所有URL的入口context，因此鏈路限流不生效。1.7.0版本開始(對應SCA  2.1.1.RELEASE)，我們在CommonFilter引入了WEB_CONTEXT_UNIFY這個init  parameter，用于控制是否收斂context。將其配置為false即可根據不同的URL進行鏈路限流。參考：https://github.com/alibaba/sentinel/issues/1213

解決方案：

1.7.0 版本開始(對應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("/*");                  // 入口資源關閉聚合         registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");         registration.setName("sentinelFilter");         registration.setOrder(1);         return registration;     } }

然后我們再嘗試觸發流控規則， 對 /getStockDetail 進行訪問，這里返回了FlowException

默認情況會返回

如果我們使用 OpenFeign 不添加 fallbackFactory 就會返回500 , 如果我們添加了就可以避免這個問題。

// Controller @Autowired private StockFeign stockFeign; @GetMapping("/getStockDetail") public CommonResult<StockModel> getStockDetail() {   CommonResult<StockModel> 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<StockModel> getStockDetail(); }

Sentinel 部分源碼：

所以，我們在設置鏈路流控規則的時候一定要設置 fallbackFactory。不然無法處理 FlowExecption  異常信息，造成系統出錯。對于個人而言，Sentinel 的鏈路規則比不是特別的好用，無特殊要求，不建議使用，或者選擇Sentinel 的收費版本  AHAS

流控效果

當 QPS、線程數超過某個閾值的時候，則采取措施進行流量控制。流量控制的效果包括以下幾種：直接拒絕、Warm Up、勻速排隊。

直接拒絕

直接拒絕(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)方式是默認的流量控制方式，當QPS超過任意規則的閾值后，新的請求就會被立即拒絕，拒絕方式為拋出FlowException。  這種方式適用于對系統處理能力確切已知的情況下，比如通過壓測確定了系統的準確水位時。

Warm up

Warm  Up(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)方式，即預熱/冷啟動方式。當系統長期處于低水位的情況下，當流量突然增加時，直接把系統拉升到高水位可能瞬間把系統壓垮。通過"冷啟動"，讓通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，給冷系統一個預熱的時間，避免冷系統被壓垮。

通常冷啟動的過程系統允許通過的 QPS 曲線如下圖所示：

默認 coldFactor 為 3，即請求 QPS 從 threshold / 3 開始，經預熱時長逐漸升至設定的 QPS 閾值。

規則設置如下圖所示：

通過 Jmeter 請求過后，可以看到如下效果，完成流控

勻速排隊

勻速排隊(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式會嚴格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應的是漏桶算法。

這種方式主要用于處理間隔性突發的流量，例如消息隊列。想象一下這樣的場景，在某一秒有大量的請求到來，而接下來的幾秒則處于空閑狀態，我們希望系統能夠在接下來的空閑期間逐漸處理這些請求，而不是在第一秒直接拒絕多余的請求。

注意：勻速排隊模式暫時不支持 QPS > 1000 的場景。

規則設置如下圖所示：

然后我們通過 jmeter 請求過后可以看到如下效果：

4. 降級規則

流量控制以外，對調用鏈路中不穩定的資源進行熔斷降級也是保障高可用的重要措施之一。一個服務常常會調用別的模塊，可能是另外的一個遠程服務、數據庫，或者第三方  API 等。例如，支付的時候，可能需要遠程調用銀聯提供的  API;查詢某個商品的價格，可能需要進行數據庫查詢。然而，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變長，那么調用服務的方法的響應時間也會變長，線程會產生堆積，最終可能耗盡業務自身的線程池，服務本身也變得不可用。

熔斷降級策略

Sentinel 提供以下幾種熔斷策略：

• 慢調用比例 (SLOW_REQUEST_RATIO)：選擇以慢調用比例作為閾值，需要設置允許的慢調用  RT(即最大的響應時間)，請求的響應時間大于該值則統計為慢調用。當單位統計時長(statIntervalMs)內請求數目大于設置的最小請求數目，并且慢調用的比例大于閾值，則接下來的熔斷時長內請求會自動被熔斷。經過熔斷時長后熔斷器會進入探測恢復狀態(HALF-OPEN  狀態)，若接下來的一個請求響應時間小于設置的慢調用 RT 則結束熔斷，若大于設置的慢調用 RT 則會再次被熔斷。

我們可以在控制臺配置：

jmeter 模擬請求

異常比例  (ERROR_RATIO)：當單位統計時長(statIntervalMs)內請求數目大于設置的最小請求數目，并且異常的比例大于閾值，則接下來的熔斷時長內請求會自動被熔斷。經過熔斷時長后熔斷器會進入探測恢復狀態(HALF-OPEN  狀態)，若接下來的一個請求成功完成(沒有錯誤)則結束熔斷，否則會再次被熔斷。異常比率的閾值范圍是 [0.0, 1.0]，代表 0% - 100%。

我們可以在控制臺配置：

• 異常數 (ERROR_COUNT)：當單位統計時長內的異常數目超過閾值之后會自動進行熔斷。經過熔斷時長后熔斷器會進入探測恢復狀態(HALF-OPEN  狀態)，若接下來的一個請求成功完成(沒有錯誤)則結束熔斷，否則會再次被熔斷。

我們可以在控制臺配置：

熔斷降級說明

熔斷降級規則(DegradeRule)包含下面幾個重要的屬性：

5. 熱點規則

何為熱點?熱點即經常訪問的數據。很多時候我們希望統計某個熱點數據中訪問頻次最高的 Top K 數據，并對其訪問進行限制。比如：

• 商品 ID 為參數，統計一段時間內最常購買的商品 ID 并進行限制

• 用戶 ID 為參數，針對一段時間內頻繁訪問的用戶 ID 進行限制

熱點參數限流會統計傳入參數中的熱點參數，并根據配置的限流閾值與模式，對包含熱點參數的資源調用進行限流。熱點參數限流可以看做是一種特殊的流量控制，僅對包含熱點參數的資源調用生效。

Sentinel 利用 LRU 策略統計最近最常訪問的熱點參數，結合令牌桶算法來進行參數級別的流控。熱點參數限流支持集群模式。

熱點規則配置需要注意：

1. 首先資源必須是通過 @SentinelResource 申明

2. 參數類型必須是基礎數據類型， 否則配置無效

熱點規則配置如下圖所示：

注意：資源名稱要和 @SentinelResource 中的資源名稱對應才能生效

控制器類的代碼如下所示：

@SentinelResource(value = "ResOrderGet",                   fallback = "fallback",                   fallbackClass = SentinelExceptionHandler.class,                   blockHandler = "blockHandler",                   blockHandlerClass = SentinelExceptionHandler.class                  ) @GetMapping("/order/get/{id}") public CommonResult<StockModel> getStockDetails(@PathVariable Integer id) {   StockModel stockModel = new StockModel();   stockModel.setCode("STOCK==>1000");   stockModel.setId(id);   return CommonResult.success(stockModel); } // 異常處理類 public class SentinelResourceExceptionHandler {     //限流熔斷業務邏輯     public static CommonResult<StockModel> blockHandler(@PathVariable Integer id) {         return CommonResult.error(null, -100, "系統錯誤 (限流熔斷業務邏輯)");     }     //異常降級業務邏輯     public static CommonResult<StockModel> fallback(@PathVariable Integer id) {         return CommonResult.error(null, -100, "系統錯誤 (異常降級業務邏輯)");     } }

返回異常信息：

6 授權規則

很多時候，我們需要根據調用來源來判斷該次請求是否允許放行，這時候可以使用 Sentinel  的來源訪問控制(黑白名單控制)的功能。來源訪問控制根據資源的請求來源(origin)限制資源是否通過，若配置白名單則只有請求來源位于白名單內時才可通過;若配置黑名單則請求來源位于黑名單時不通過，其余的請求通過。

調用方信息通過 ContextUtil.enter(resourceName, origin) 方法中的 origin 參數傳入。

Sentinel提供了 RequestOriginParser 接口來處理訪問來源，Sentinel保護的資源如果被訪問，就會調用  RequestOriginParser解析訪問來源。

// 注意導包 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("/*");         // 入口資源關閉聚合         registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false");         registration.setName("sentinelFilter");         registration.setOrder(1);         // CommonFilter 的 BlockException 自定義處理邏輯         WebCallbackManager.setUrlBlockHandler(new SentinelFlowHandler());         //解決授權規則不生效的問題         //com.alibaba.csp.sentinel.adapter.servlet.callback.RequestOriginParser         WebCallbackManager.setRequestOriginParser(new SentinelRequestOriginParser());         return registration;     } }

規則配置

執行請求

正常通過

異常不通過

7 系統規則

系統保護規則是從應用級別的入口流量進行控制，從單臺機器的 load、CPU 使用率、平均 RT、入口 QPS  和并發線程數等幾個維度監控應用指標，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。

系統保護規則是應用整體維度的，而不是資源維度的，并且僅對入口流量生效。入口流量指的是進入應用的流量(EntryType.IN)，比如 Web 服務或  Dubbo 服務端接收的請求，都屬于入口流量。

系統規則支持以下的模式：

• Load 自適應(僅對 Linux/Unix-like 機器生效)：系統的 load1 作為啟發指標，進行自適應系統保護。當系統 load1  超過設定的啟發值，且系統當前的并發線程數超過估算的系統容量時才會觸發系統保護(BBR 階段)。系統容量由系統的 maxQps * minRt  估算得出。設定參考值一般是 CPU cores * 2.5。

• CPU usage(1.5.0+ 版本)：當系統 CPU 使用率超過閾值即觸發系統保護(取值范圍 0.0-1.0)，比較靈敏。

• 平均 RT：當單臺機器上所有入口流量的平均 RT 達到閾值即觸發系統保護，單位是毫秒。

• 并發線程數：當單臺機器上所有入口流量的并發線程數達到閾值即觸發系統保護。

• 入口 QPS：當單臺機器上所有入口流量的 QPS 達到閾值即觸發系統保護。

原理

如下圖所示

我們把系統處理請求的過程想象為一個水管，到來的請求是往這個水管灌水，當系統處理順暢的時候，請求不需要排隊，直接從水管中穿過，這個請求的RT是最短的;反之，當請求堆積的時候，那么處理請求的時間則會變為：排隊時間  + 最短處理時間。

• 推論一: 如果我們能夠保證水管里的水量，能夠讓水順暢的流動，則不會增加排隊的請求;也就是說，這個時候的系統負載不會進一步惡化。

我們用 T 來表示(水管內部的水量)，用RT來表示請求的處理時間，用P來表示進來的請求數，那么一個請求從進入水管道到從水管出來，這個水管會存在 P *  RT　個請求。換一句話來說，當 T ≈ QPS * Avg(RT)  的時候，我們可以認為系統的處理能力和允許進入的請求個數達到了平衡，系統的負載不會進一步惡化。

接下來的問題是，水管的水位是可以達到了一個平衡點，但是這個平衡點只能保證水管的水位不再繼續增高，但是還面臨一個問題，就是在達到平衡點之前，這個水管里已經堆積了多少水。如果之前水管的水已經在一個量級了，那么這個時候系統允許通過的水量可能只能緩慢通過，RT會大，之前堆積在水管里的水會滯留;反之，如果之前的水管水位偏低，那么又會浪費了系統的處理能力。

• 推論二:　當保持入口的流量是水管出來的流量的最大的值的時候，可以最大利用水管的處理能力。

然而，和 TCP BBR 的不一樣的地方在于，還需要用一個系統負載的值(load1)來激發這套機制啟動。

注：這種系統自適應算法對于低 load 的請求，它的效果是一個“兜底”的角色。對于不是應用本身造成的 load  高的情況(如其它進程導致的不穩定的情況)，效果不明顯。

配置頁面

觸發流控規則

8 集群流控

為什么要使用集群流控呢?假設我們希望給某個用戶限制調用某個 API 的總 QPS 為 50，但機器數可能很多(比如有 100  臺)。這時候我們很自然地就想到，找一個 server 來專門來統計總的調用量，其它的實例都與這臺 server  通信來判斷是否可以調用。這就是最基礎的集群流控的方式。

另外集群流控還可以解決流量不均勻導致總體限流效果不佳的問題。假設集群中有 10 臺機器，我們給每臺機器設置單機限流閾值為 10  QPS，理想情況下整個集群的限流閾值就為 100  QPS。不過實際情況下流量到每臺機器可能會不均勻，會導致總量沒有到的情況下某些機器就開始限流。因此僅靠單機維度去限制的話會無法精確地限制總體流量。而集群流控可以精確地控制整個集群的調用總量，結合單機限流兜底，可以更好地發揮流量控制的效果。

集群流控中共有兩種身份：

• Token Client：集群流控客戶端，用于向所屬 Token Server 通信請求  token。集群限流服務端會返回給客戶端結果，決定是否限流。

• Token Server：即集群流控服務端，處理來自 Token Client 的請求，根據配置的集群規則判斷是否應該發放  token(是否允許通過)。

規則推送

Sentinel 控制臺同時提供簡單的規則管理以及推送的功能。規則推送分為 3 種模式，包括 "原始模式"、"Pull 模式" 和"Push  模式"。

這里先簡單的介紹"原始模式"。

規則管理

您可以在控制臺通過接入端暴露的 HTTP API 來查詢規則。

規則推送

目前控制臺的規則推送也是通過 規則查詢更改 HTTP API 來更改規則。這也意味著這些規則僅在內存態生效，應用重啟之后，該規則會丟失。

注：若通過控制臺推送規則時出現 invalid type 或 empty type 的錯誤，請確保 transport 模塊版本與 core  模塊版本保持一致;若控制臺版本 >= 1.7.1，請將接入端的相關依賴也升級至 1.7.1 及以上版本。

以上是原始模式。當了解了原始模式之后，我們非常鼓勵您通過 動態規則  并結合各種外部存儲來定制自己的規則源。我們推薦通過動態配置源的控制臺來進行規則寫入和推送，而不是通過 Sentinel  客戶端直接寫入到動態配置源中。在生產環境中，我們推薦 push 模式，具體可以參考：在生產環境使用 Sentinel。

注：若要使用集群流控功能，則必須對接動態規則源，否則無法正常使用。您也可以接入 AHAS Sentinel  快速接入全自動托管、高可用的集群流控能力。

Sentinel 同時還提供應用維度規則推送的示例頁面(流控規則頁面，前端路由為 /v2/flow)，用戶改造控制臺對接配置中心后可直接通過 v2  頁面推送規則至配置中心。Sentinel 抽取了通用接口用于向遠程配置中心推送規則以及拉取規則：

DynamicRuleProvider: 拉取規則(應用維度)

DynamicRulePublisher: 推送規則(應用維度)

用戶只需實現 DynamicRuleProvider 和 DynamicRulePublisher 接口，并在 v2 的 controller 中通過  @Qualifier 注解替換相應的 bean 即可實現應用維度推送。我們提供了 Nacos 和 Apollo 的示例，改造詳情可參考  應用維度規則推送示例。

鑒權

從 Sentinel 1.5.0 開始，控制臺提供通用的鑒權接口 AuthService，用戶可根據需求自行實現。

從 Sentinel 1.6.0 起，Sentinel 控制臺引入基本的登錄功能，默認用戶名和密碼都是  sentinel。該鑒權能力非常基礎，生產環境使用建議根據安全需要自行改造。

用戶可以通過如下參數進行配置：

• -Dsentinel.dashboard.auth.username=sentinel 用于指定控制臺的登錄用戶名為 sentinel;

• -Dsentinel.dashboard.auth.password=123456 用于指定控制臺的登錄密碼為  123456;如果省略這兩個參數，默認用戶和密碼均為 sentinel;

• -Dserver.servlet.session.timeout=7200 用于指定 Spring Boot 服務端 session 的過期時間，如  7200 表示 7200 秒;60m 表示 60 分鐘，默認為 30 分鐘;

同樣也可以直接在 Spring properties 文件中進行配置。

注意：部署多臺控制臺時，session 默認不會在各實例之間共享，這一塊需要自行改造。

感謝各位的閱讀，以上就是“Sentinel流控規則的介紹”的內容了，經過本文的學習后，相信大家對Sentinel流控規則的介紹這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！