sentinel限流的基本使用

sentinel概念

 Sentinel 以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

sentinel控制台的概念

Sentinel控制台(sentinel-dashboard)是流量控制、熔斷降級規則統一配置和管理的入口，它為用戶提供了機器自發現、簇點鏈路自發現、監控、規則配置等功能。在 Sentinel 控制台上，我們可以配置規則並實時查看流量控制效果。

sentinel-dashboard控制台的下載和安裝

注意點

• sentinel-dashboard控制台只能進行單機部署。但是阿里巴巴同時提供了AHAS Sentinel企業級的控制台實現高可用，同時提供更加詳細的數據展示和告警措施，這里不再詳述，有意者自己去學習。
• 啟動 Sentinel 控制台需要 JDK 版本為 1.8 及以上版本
• 若您的應用為 Spring Boot 或 Spring Cloud 應用，您可以通過 Spring 配置文件來指定配置

依賴引用

注意：依賴引入事一定要注意和自己使用的springboot版本的對應，否者很可能無法正常使用

在父級模塊進行管理alibaba的依賴
<dependencyManagement>
   <dependencies>
     <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2.1.0.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
      </dependencies>
</dependencyManagement>
在相應的業務模塊引入sentinel模塊的依賴
<dependency>
   <groupId>com.alibaba.cloud</groupId>
   <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
      <exclusions>
         <exclusion>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-xml</artifactId>
         </exclusion>
      </exclusions>
</dependency>

 

與springboot整合配置

　　我使用的springboott項目版本為2.2.6.RELEASE，但我的項目只是一個簡單的springboot項目並非springcloud和dubbo項目，如果想在springcloud或者dubbo集群項目中使用，還需要因為引入相應的適配器模塊，具體的可以參看GitHub中相關文檔，文章最后會附上鏈接。

　　其實sentinel和springboot的整合非常簡單，只需要幾個基本的配置即可，更多的配置github文檔中有詳細的介紹。

 

 

注解解讀

@SentinelResource 注解

　　Sentinel 提供了 @SentinelResource 注解用於定義資源，並提供了 AspectJ 的擴展用於自動定義資源、處理 BlockException等。使用 Sentinel Annotation AspectJ Extension 的時候需要引入以下依賴：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-annotation-aspectj</artifactId>
    <version>x.y.z</version>
</dependency>

注解中的配置項解讀：

• value：資源名稱，必需項（不能為空）
• entryType：entry 類型，可選項（默認為 EntryType.OUT）
• blockHandler / blockHandlerClass: blockHandler 對應處理 BlockException 的函數名稱，可選項。blockHandler 函數訪問范圍需要是 public，返回類型需要與原方法相匹配，參數類型需要和原方法相匹配並且最后加一個額外的參數，類型為 BlockException。blockHandler 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 blockHandlerClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。
• fallback / fallbackClass：fallback 函數名稱，可選項，用於在拋出異常的時候提供 fallback 處理邏輯。fallback 函數可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進行處理。fallback 函數簽名和位置要求：
  • 返回值類型必須與原函數返回值類型一致；
  • 方法參數列表需要和原函數一致，或者可以額外多一個 Throwable 類型的參數用於接收對應的異常。
  • fallback 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 fallbackClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。
• defaultFallback（since 1.6.0）：默認的 fallback 函數名稱，可選項，通常用於通用的 fallback 邏輯（即可以用於很多服務或方法）。默認 fallback 函數可以針對所有類型的異常（除了 exceptionsToIgnore 里面排除掉的異常類型）進行處理。若同時配置了 fallback 和 defaultFallback，則只有 fallback 會生效。defaultFallback 函數簽名要求：exceptionsToIgnore（since 1.6.0）：用於指定哪些異常被排除掉，不會計入異常統計中，也不會進入 fallback 邏輯中，而是會原樣拋出。
• 返回值類型必須與原函數返回值類型一致；
• 方法參數列表需要為空，或者可以額外多一個 Throwable 類型的參數用於接收對應的異常。
• defaultFallback 函數默認需要和原方法在同一個類中。若希望使用其他類的函數，則可以指定 fallbackClass 為對應的類的 Class 對象，注意對應的函數必需為 static 函數，否則無法解析。

　　特別地，若 blockHandler 和 fallback 都進行了配置，則被限流降級而拋出 BlockException 時只會進入 blockHandler 處理邏輯。若未配置 blockHandler、fallback 和 defaultFallback，則被限流降級時會將 BlockException 直接拋出（若方法本身未定義 throws BlockException 則會被 JVM 包裝一層 UndeclaredThrowableException）。

　　從 1.4.0 版本開始，注解方式定義資源支持自動統計業務異常，無需手動調用 Tracer.trace(ex) 來記錄業務異常。Sentinel 1.4.0 以前的版本需要自行調用 Tracer.trace(ex) 來記錄業務異常。

注意點：

• 注解方式埋點不支持 private 方法
• 1.6.0 之前的版本 fallback 函數只針對降級異常（DegradeException）進行處理，不能針對業務異常進行處理
• 一般推薦將 @SentinelResource 注解加到服務實現上，而在 Web 層直接使用 Spring Cloud Alibaba 自帶的 Web 埋點適配。

 

@SentinelRestTemplate注解

 

持久化

 sentinel本身支持多種規則配置方式：

• sentinel-dashboard控制台直接配置

　　這種方式配置的規則只保存在內存中，在控制台重啟的時候就會丟失所有配置的規則，這在生產環境肯定是不可取的，所以我們要把配置的規則持久化下來，這樣可以保證重啟服務后我們的配置規則不丟失，這也是我們會着重講的方式。

• 通過Sentinel提供的SPI可擴展機制（這里不在詳述）

　　這種方式可以保證我們每次啟動客戶端時或者控制台時都可以展示出來我們的配置規則，但是這種方式有個很大額弊端就是每次修改規則都要重新部署客戶端代碼。這在實際生產中肯定不行，於是有了動態配置的方式。

• 通過動態的配置

　　這種方式能夠根據我們的需要動態的調整規則。但是這種方式同樣有弊端，就是sentinel-dashboard本身無法單獨完成需要外部的配置中心來配合管理規則的創建和修改，同時需要外部數據庫來保證規則的持久化。具體分為兩種模式：pull模式和push模式。

　　推送模式分為下面三種：

推送模式	說明	優點	缺點
原始模式	API 將規則推送至客戶端並直接更新到內存中，擴展寫數據源（WritableDataSource）	簡單，無任何依賴	不保證一致性；規則保存在內存中，重啟即消失。嚴重不建議用於生產環境
Pull 模式	擴展寫數據源（WritableDataSource）， 客戶端主動向某個規則管理中心定期輪詢拉取規則，這個規則中心可以是 RDBMS、文件 等	簡單，無任何依賴；規則持久化	不保證一致性；實時性不保證，拉取過於頻繁也可能會有性能問題。
Push 模式	擴展讀數據源（ReadableDataSource），規則中心統一推送，客戶端通過注冊監聽器的方式時刻監聽變化，比如使用 Nacos、Zookeeper 等配置中心。這種方式有更好的實時性和一致性保證。生產環境下一般采用 push 模式的數據源。	規則持久化；一致性；快速	引入第三方依賴

　　我們這里只講解Push模式的實現。由於Nacos優秀的通信協議性能以及本身既可當規則配置中心又可作為服務注冊發現中心的優勢，就連springcloud目前都開放棄本身的服務注冊發現中心（erruke和consule）和配置中心（springcloud config），我們有什么理由不使用它呢！並且Nacos的另個優勢在於在部署集群時要比另一個著名的配置中心Appolo（攜程開源的配置中心）簡單的多。當然，如果各位有興趣完全可以使用其他的配置中心，畢竟每個技術都有自己獨特的優勢。

 

sentinel和Nacos配合實現配置規則的持久化

學習鏈接

sentinel問題排查

sentinel的github文檔