開發與維運

Spring Cloud Alibaba 服務熔斷和限流

2020-09-28

前言：為什麼需要流控降級

我們的生產環境經常會出現一些不穩定的情況，如：

  • 大促時瞬間洪峰流量導致系統超出最大負載，load 飆高，系統崩潰導致用戶無法下單
  • “黑馬”熱點商品擊穿緩存，DB 被打垮，擠佔正常流量
  • 調用端被不穩定服務拖垮，線程池被佔滿，導致整個調用鏈路卡死

這些不穩定的場景可能會導致嚴重後果。大家可能想問：如何做到均勻平滑的用戶訪問？如何預防流量過大或服務不穩定帶來的影響？這時候我們就要請出微服務穩定性的法寶 —— 高可用流量防護，其中重要的手段就是流量控制和熔斷降級，它們是保障微服務穩定性重要的一環。

為什麼需要流量控制？

流量是非常隨機性的、不可預測的。前一秒可能還風平浪靜，後一秒可能就出現流量洪峰了（例如雙十一零點的場景）。然而我們系統的容量總是有限的，如果突然而來的流量超過了系統的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最後導致系統崩潰。因此，我們需要針對這種突發的流量來進行限制，在儘可能處理請求的同時來保障服務不被打垮，這就是流量控制。

為什麼需要熔斷降級？

一個服務常常會調用別的模塊，可能是另外的一個遠程服務、數據庫，或者第三方 API 等。例如，支付的時候，可能需要遠程調用銀聯提供的 API；查詢某個商品的價格，可能需要進行數據庫查詢。然而，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變長，那麼調用服務的方法的響應時間也會變長，線程會產生堆積，最終可能耗盡業務自身的線程池，服務本身也變得不可用。

1.png

現代微服務架構都是分佈式的，由非常多的服務組成。不同服務之間相互調用，組成複雜的調用鏈路。以上的問題在鏈路調用中會產生放大的效果。複雜鏈路上的某一環不穩定，就可能會層層級聯，最終導致整個鏈路都不可用。因此我們需要對不穩定的弱依賴服務進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素導致整體的雪崩。

Sentinel: 高可用護航的利器

Sentinel 是阿里巴巴開源的，面向分佈式服務架構的高可用防護組件，主要以流量為切入點，從流量控制、流量整形、熔斷降級、系統自適應保護、熱點防護等多個維度來幫助開發者保障微服務的穩定性。Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺、冷啟動、消息削峰填谷、自適應流量控制、實時熔斷下游不可用服務等，是保障微服務高可用的利器，原生支持 Java/Go/C++ 等多種語言，並且提供 Istio/Envoy 全局流控支持來為 Service Mesh 提供高可用防護的能力。

Sentinel 的技術亮點：

  • 高度可擴展能力：基礎核心 + SPI 接口擴展能力，用戶可以方便地擴展流控、通信、監控等功能
  • 多樣化的流量控制策略（資源粒度、調用關係、流控指標、流控效果等多個維度），提供分佈式集群流控的能力
  • 熱點流量探測和防護
  • 對不穩定服務進行熔斷降級和隔離
  • 全局維度的系統負載自適應保護，根據系統水位實時調節流量
  • 覆蓋 API Gateway 場景，為 Spring Cloud Gateway、Zuul 提供網關流量控制的能力
  • 實時監控和規則動態配置管理能力

2.png

一些普遍的使用場景：

  • 在服務提供方（Service Provider）的場景下，我們需要保護服務提供方自身不被流量洪峰打垮。這時候通常根據服務提供方的服務能力進行流量控制，或針對特定的服務調用方進行限制。我們可以結合前期壓測評估核心接口的承受能力，配置 QPS 模式的限流，當每秒的請求量超過設定的閾值時，會自動拒絕多餘的請求。
  • 為了避免調用其他服務時被不穩定的服務拖垮自身，我們需要在服務調用端（Service Consumer）對不穩定服務依賴進行隔離和熔斷。手段包括信號量隔離、異常比例降級、RT 降級等多種手段。
  • 當系統長期處於低水位的情況下，流量突然增加時，直接把系統拉昇到高水位可能瞬間把系統壓垮。這時候我們可以藉助 Sentinel 的 WarmUp 流控模式控制通過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，而不是在一瞬間全部放行。這樣可以給冷系統一個預熱的時間，避免冷系統被壓垮。
  • 利用 Sentinel 的勻速排隊模式進行“削峰填谷”，把請求突刺均攤到一段時間內，讓系統負載保持在請求處理水位之內，同時儘可能地處理更多請求。
  • 利用 Sentinel 的網關流控特性，在網關入口處進行流量防護，或限制 API 的調用頻率。

Sentinel 有著豐富的開源生態。Sentinel 開源不久就被納入 CNCF Landscape 版圖，並且也成為 Spring Cloud 官方推薦的流控降級組件之一。社區提供 Spring Cloud、Dubbo、gRPC、Quarkus 等常用微服務框架的適配，開箱即用；同時支持 Reactive 生態，支持 Reactor、Spring WebFlux 異步響應式架構。Sentinel 也在逐漸覆蓋 API Gateway 和 Service Mesh 場景，在雲原生架構中發揮更大的作用。

3.png

在原來的 Spring Cloud Netflix 系列中，有自帶的熔斷組件 Hystrix ，是 Netflix 公司提供的一個開源的組件，提供了熔斷、隔離的這些特性，不過 Hystrix 在 2018 年 11 月份開始，就不再迭代開發，進入維護的模式。同年開源的 Spring Cloud Alibaba (SCA) 提供了一站式的解決方案，默認為 Sentinel 整合了 Spring Web、RestTemplate、FeignClient 和 Spring WebFlux。Sentinel 在 Spring Cloud 生態中，不僅補全了 Hystrix 在 Servlet、RestTemplate 和 API Gateway 這一塊的空白，而且還完全兼容了 Hystrix 在 FeignClient 中限流降級的用法，並且支持運行時靈活地配置和調整限流降級規則。同時 SCA 還集成了 Sentinel 提供的 API gateway 流控模塊，可以無縫支持 Spring Cloud Gateway 和 Zuul 網關的流控降級。

Spring Cloud Alibaba Sentinel 服務限流/熔斷實戰

下面到了動手時間了！我們結合一個實例來對 Spring Cloud 服務限流/熔斷進行實戰。我們的實例項目由四個模塊構成：

  • service-api: 服務接口定義，供 consumer/provider 引用
  • dubbo-provider: Dubbo 服務端，對外提供一些服務

  • web-api-demo: Spring Boot Web 應用，其中的一些 API 會作為 consumer 來調用 dubbo-provider 獲取結果。裡面一共定義了三個 API path：

    • /demo/hello: 接受一個 name 參數，會 RPC 調用後端的 FooService:sayHello(name) 方法。
    • /demo/time：調用後端的 FooService:getCurrentTime 方法獲取當前時間；裡面可以通過 slow 請求參數模擬慢調用。
    • /demo/bonjour/{name}: 直接調用本地 DemoService 服務。
  • demo-gateway: Spring Cloud Gateway 網關，作為整個項目的訪問入口，將流量轉發至後端服務或第三方服務。我們的入口 URL 訪問都會經過該 API gateway。demo-gateway 的路由配置如下：
spring:
  cloud:
    gateway:
      enabled: true
      discovery:
        locator:
          # route ID 轉化小寫
          lower-case-service-id: true
      routes:
        - id: foo-service-route
          uri: http://localhost:9669/
          predicates:
            - Path=/demo/**
        - id: httpbin-route
          uri: https://httpbin.org
          predicates:
            - Path=/httpbin/**
          filters:
            - RewritePath=/httpbin/(?<segment>.*), /$\{segment}

這個路由配置包含兩個路由：

  • foo-service-route: 會將 /demo/ 開頭的訪問路由到 localhost:9669 後端服務上面，即對應我們的 Web 服務。我們訪問示例中的 API 都會經過這個路由，比如 localhost:8090/demo/time。
  • httpbin-route: 這是一個示例路由，它會將 /httpbin/ 開頭的訪問路由到 https://httpbin.org 這個示例網站上，比如 localhost:8090/httpbin/json 實際會映射到 https://httpbin.org/json 上面。

同時我們的環境也包含啟動好的 Sentinel 控制檯，可以直接訪問並供各個服務接入。對應的地址：TODO

下面我們來一步一步操作接入 SCA Sentinel 並通過控制檯/Nacos 動態數據源配置流控降級規則來驗證效果。

spring-cloud-alibaba-dependencies 配置

首先第一步我們在項目的父 pom 裡面導入最新版本的 spring-cloud-alibaba-dependencies，這樣我們在實際引入 SCA 相關依賴的時候就不需要指定版本號了：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.2.2.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

服務接入 SCA Sentinel

首先我們分別為三個服務模塊引入 Spring Cloud Alibaba Sentinel 依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

starter 會自動對 Sentinel 的適配模塊進行配置，只需要簡單的配置即可快速接入 Sentinel 並連接到 Sentinel 控制檯。

對於 Dubbo 服務，我們還需要額外引入 Dubbo 的適配模塊。Sentinel 為 Apache Dubbo 提供開箱即用的整合模塊，僅需引入 sentinel-apache-dubbo-adapter 依賴即可接入 Dubbo 自動埋點統計（支持 provider 和 consumer）：

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-apache-dubbo-adapter</artifactId>
    <version>1.8.0</version>
</dependency>

我們在 web-api-demo 和 dubbo-provider 兩個應用的 pom 文件添加 adapter 依賴，這樣兩個應用的 Dubbo consumer/provider 接口就可以自動被 Sentinel 統計。

對於 Spring Cloud Gateway、Zuul 1.x 等網關，我們還需要在上面 SCA 依賴的基礎上額外引入 spring-cloud-alibaba-sentinel-gateway 依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>

這個依賴會自動為網關添加 Sentinel 相關的配置，從而可以讓 API gateway 自動接入 Sentinel。我們在 demo-gateway 應用的 pom 文件裡面添加這個依賴，這樣我們的 gateway 應用就可以接入 Sentinel 了。

引入依賴之後，我們只需要進行簡單的配置即可快速接入 Sentinel 控制檯。我們可以在 application.properties 文件裡面配置應用名和連接控制檯的地址，以 web-api-demo 為例：

spring.application.name=foo-web
spring.cloud.sentinel.transport.dashboard=localhost:8080

其中 spring.application.name 相信大家都比較熟悉了，這裡 Spring Cloud Alibaba Sentinel 會自動提取這個值作為接入應用的 appName。同時我們通過 spring.cloud.sentinel.transport.dashboard 來配置要連接的控制檯地址和端口。

完成以上的配置後，我們可以依次啟動 dubbo-provider、web-api-demo 和 demo-gateway 應用，並通過網關入口訪問 localhost:8090/demo/time 獲取當前時間。觸發服務後，我們稍後可以在 Sentinel 控制檯看到我們的三個應用，可以在監控頁面看到訪問信息，代表接入成功。

4.png

我們可以在每個應用的簇點鏈路頁面看到當前應用的一些埋點調用，比如 Web 應用可以看到 Web URL 和 Dubbo consumer 調用：

5.png

流控規則

下面我們來配一條最簡單的流控規則。在 Dubbo provider 端，我們進入簇點鏈路頁面，針對 com.alibaba.csp.sentinel.demo.dubbo.FooService:getCurrentTime(boolean) 這個服務調用配置限流規則（需要有過訪問量才能看到）。我們配一條 QPS 為 1 的流控規則，這代表針對該服務方法的調用每秒鐘不能超過 1 次，超出會直接拒絕。

6.png

點擊“新增”按鈕，成功添加規則。我們可以在瀏覽器反覆請求 localhost:8090/demo/time（頻率不要太慢），可以看到會出現限流異常信息（Dubbo provider 默認的限流處理邏輯是拋出異常，該異常信息由 Dubbo 直接返回，並由 Spring 展示為默認 error 頁面）：

13.png

同時我們也可以在“實時監控”頁面看到實時的訪問量和拒絕量：

7.png

我們同樣也可以在 Web API 處配置限流規則，觀察效果。Spring Web 默認的限流處理邏輯是返回默認的提示信息（Blocked by Sentinel），狀態碼為 429。在後面的章節我們會介紹如何自定義流控處理邏輯。

瞭解了限流的基本用法，大家可能想問：生產環境我需要針對每個接口都去配置流控規則嗎？閾值不會配怎麼辦？其實，限流降級的配置是需要結合容量規劃、依賴梳理來做的。我們可以藉助 JMeter 或 阿里雲 PTS 等壓測工具對我們的服務進行全鏈路壓測，瞭解每個服務的最大承受能力，來確定核心接口的最大容量並作為 QPS 閾值。

網關流控規則

Sentinel 對 API Gateway 流控的場景進行了定製，支持針對網關的路由（如上面 gateway 定義的 foo-service-route）或自定義的 API 分組進行流控，支持針對請求屬性（如某個 header）進行流控。用戶可以在 Sentinel 控制檯 自定義 API 分組，可以看做是一些 URL 匹配的組合。比如我們可以定義一個 API 叫 my_api，請求 path 模式為 /foo/** 和 /baz/** 的都歸到 my_api 這個 API 分組下面。限流的時候可以針對這個自定義的 API 分組維度進行限流。

8.png

下面我們在控制檯針對 gateway 配置一條網關流控規則。我們可以看到 API Gateway 的控制檯頁面與普通應用的頁面有一些差異，這些就是針對網關場景的定製。Sentinel 網關流控規則支持提取某個 route 的請求屬性，包括 remote IP、header、URL 參數、cookie 等，支持自動統計其中的熱點值並分別進行限制，也支持針對某個具體值進行限制（比如給某個 uid 限量）。

我們給 foo-service-route 這個路由配一條針對請求屬性的網關流控規則。這條規則會針對 URL 參數中提取出來的每個熱點 uid 參數分別進行限制，每分鐘的請求量最多允許 2 次。

9.png

保存規則後，我們可以構造一些向後端服務的請求，攜帶上不同的 uid 參數（即使沒有用到），比如 localhost:8090/demo/time?uid=xxx。我們可以觀察到，每個 uid 的訪問每分鐘超出兩次後會出現限流頁面。

關於 Sentinel 網關流控的詳細配置指南和實現原理請參考 網關流控文檔。

熔斷降級規則

熔斷降級通常用於自動切斷不穩定的服務，防止調用方被拖垮導致級聯故障。熔斷降級規則通常在調用端，針對弱依賴調用進行配置，在熔斷時返回預定義好的 fallback 值，這樣可以保證核心鏈路不被不穩定的旁路影響。

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

  • 慢調用比例 (SLOW_REQUEST_RATIO)：選擇以慢調用比例作為閾值，需要設置允許的慢調用 RT（即最大的響應時間），請求的響應時間大於該值則統計為慢調用。當單位統計時長（statIntervalMs，默認為 1s）內請求數目大於設置的最小請求數目，並且慢調用的比例大於閾值，則接下來的熔斷時長內請求會自動被熔斷。經過熔斷時長後熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求響應時間小於設置的慢調用 RT 則結束熔斷，若大於設置的慢調用 RT 則會再次被熔斷。
  • 異常比例 (ERROR_RATIO)：當單位統計時長內請求數目大於設置的最小請求數目，並且異常的比例大於閾值，則接下來的熔斷時長內請求會自動被熔斷。經過熔斷時長後熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。異常比率的閾值範圍是 [0.0, 1.0]，代表 0% - 100%。
  • 異常數 (ERROR_COUNT)：當單位統計時長內的異常數目超過閾值之後會自動進行熔斷。經過熔斷時長後熔斷器會進入探測恢復狀態（HALF-OPEN 狀態），若接下來的一個請求成功完成（沒有錯誤）則結束熔斷，否則會再次被熔斷。

下面我們來在 Web 應用中針對 Dubbo consumer 來配置慢調用熔斷規則，並模擬慢調用來觀察效果。我們在 web-api-demo 中針對 com.alibaba.csp.sentinel.demo.dubbo.FooService 服務調用配置熔斷降級規則。

10.png

控制檯配置的統計時長默認為 1s。在上面的這條規則中，我們設定慢調用臨界值為 50ms，響應時間超出 50ms 即記為慢調用。當統計時長內的請求數 >=5 且慢調用的比例超出我們配置的閾值（80%）就會觸發熔斷，熔斷時長為 5s，經過熔斷時長後會允許一個請求探測通過，若請求正常則恢復，否則繼續熔斷。

我們的實例中 /demo/time API 可以通過 slow 請求參數模擬慢調用，當 slow=true 時該請求耗時會超過 100ms。我們可以用 ab 等壓測工具或腳本，批量請求 localhost:8090/demo/time?slow=true，可以觀察到熔斷的返回

11.png

如果我們一直模擬慢調用，我們可以觀察到熔斷後每 5s 會允許通過一個請求，但該請求仍然是慢調用，會重新打回熔斷，無法恢復。我們可以在觸發熔斷後，等待一段時間後手動發一個不帶 slow=true 的正常請求，然後再進行請求，可以觀察到熔斷恢復。

需要注意的是，即使服務調用方引入了熔斷降級機制，我們還是需要在 HTTP 或 RPC 客戶端配置請求超時時間，來做一個兜底的防護。

註解方式自定義埋點

剛才我們看到的埋點都是 Sentinel 適配模塊提供的自動埋點。有的時候自動埋點可能沒法滿足我們的需求，我們希望在某個業務邏輯的位置進行限流，能不能做到呢？當然可以！Sentinel 提供兩種方式進行自定義埋點：SphU API 和 @SentinelResource 註解，前者最為通用但是代碼比較繁雜，耦合度較高；註解方式侵入性較低，但有使用場景的限制。這裡我們來動手在 Web 應用的 DemoService 上添加註解，來達到針對本地服務埋點的目標。

在 DemoService 中我們實現了一個簡單的打招呼的服務：

@Service
public class DemoService {

    public String bonjour(String name) {
        return "Bonjour, " + name;
    }
}

下面我們給 bonjour 這個函數添加 @SentinelResource 註解，註解的 value 代表這個埋點的名稱（resourceName），會顯示在簇點鏈路/監控頁面。

@SentinelResource(value = "DemoService#bonjour")
public String bonjour(String name)

加上該註解後，再通過網關訪問 /demo/bonjour/{name} 這個 API 的時候，我們就可以在簇點鏈路頁面看到我們自定義的 DemoService#bonjour 埋點了。

12.png

添加註解埋點只是第一步。一般在生產環境中，我們希望在這些自定義埋點發生限流的時候，有一些 fallback 邏輯，而不是直接對外拋出異常。這裡我們可以寫一個 fallback 函數：

public String bonjourFallback(Throwable t) {
    if (BlockException.isBlockException(t)) {
        return "Blocked by Sentinel: " + t.getClass().getSimpleName();
    }
    return "Oops, failed: " + t.getClass().getCanonicalName();
}

我們的 fallback 函數接受一個 Throwable 參數，可以從中獲取異常信息。Sentinel 註解的 fallback 會捕獲業務異常和流控異常（即 BlockException 及其子類），我們可以在 fallback 邏輯裡面進行相應的處理（如日誌記錄），並返回 fallback 的值。

注意：Sentinel 註解對 fallback 和 blockHandler 函數的方法簽名有要求，具體請參考此處文檔。

寫好 fallback 函數的實現後，我們在 @SentinelResource 註解裡面指定一下：

@SentinelResource(value = "DemoService#bonjour", defaultFallback = "bonjourFallback")
public String bonjour(String name)

這樣當我們自定義的 DemoService#bonjour 資源被限流或熔斷的時候，請求會走到 fallback 的邏輯中，返回 fallback 結果，而不會直接拋出異常。我們可以配一個 QPS=1 的限流規則，然後快速請求後觀察返回值：

?  ~ curl http://localhost:8090/demo/bonjour/Sentinel
Bonjour, Sentinel
?  ~ curl http://localhost:8090/demo/bonjour/Sentinel
Blocked by Sentinel: FlowException

注意：使用 @SentinelResource 註解要求對應的類必須由 Spring 託管（即為 Spring bean），並且不能是內部調用（沒法走到代理），不能是 private 方法。Sentinel 註解生效依賴 Spring AOP 動態代理機制。

配置自定義的流控處理邏輯

Sentinel 的各種適配方式均支持自定義的流控處理邏輯。以 Spring Web 適配為例，我們只需要提供自定義的 BlockExceptionHandler 實現並註冊為 bean 即可為 Web 埋點提供自定義處理邏輯。其中 BlockExceptionHandler 的定義如下：

public interface BlockExceptionHandler {

    // 在此處處理限流異常，可以跳轉到指定頁面或返回指定的內容
    void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}

我們的 Web 應用中提供了 Web 埋點自定義流控處理邏輯的示例：

@Configuration
public class SentinelWebConfig {

    @Bean
    public BlockExceptionHandler sentinelBlockExceptionHandler() {
        return (request, response, e) -> {
            // 429 Too Many Requests
            response.setStatus(429);

            PrintWriter out = response.getWriter();
            out.print("Oops, blocked by Sentinel: " + e.getClass().getSimpleName());
            out.flush();
            out.close();
        };
    }
}

該 handler 會獲取流控類型並打印返回信息，返回狀態碼為 429。我們可以根據實際的業務需求，配置跳轉或自定義的返回信息。

對於註解方式，我們上一節已經提到，可以指定 fallback 函數來處理流控異常和業務異常，這裡不再展開講解；對於 Dubbo 適配，我們可以通過 DubboAdapterGlobalConfig 註冊 provider/consumer fallback 來提供自定義的流控處理邏輯；對於 Spring Cloud Gateway 適配，我們可以註冊自定義的 BlockRequestHandler 實現類來為網關流控註冊自定義的處理邏輯。

對 Spring Cloud 其他組件的支持

Spring Cloud Alibaba Sentinel 還提供對 Spring Cloud 其它常用組件的支持，包括 RestTemplate、Feign 等。篇幅所限，我們不展開實踐。大家可以參考 Spring Cloud Alibaba 文檔 來進行接入和配置。

如何選擇流控降級組件

講到這裡，大家可能會有疑問：Sentinel 和其它同類產品（如 Hystrix）相比有什麼優缺點？是否有必要遷移到 Sentinel？如何快速遷移？以下是 Sentinel 與其它 fault-tolerance 組件的對比：

Sentinel Hystrix resilience4j
隔離策略 信號量隔離（併發控制） 線程池隔離/信號量隔離 信號量隔離
熔斷降級策略 基於慢調用比例、異常比例、異常數 基於異常比例 基於異常比例、響應時間
實時統計實現 滑動窗口（LeapArray） 滑動窗口（基於 RxJava） Ring Bit Buffer
動態規則配置 支持多種數據源 支持多種數據源 有限支持
擴展性 多個擴展點 插件的形式 接口的形式
基於註解的支持 支持 支持 支持
限流 基於 QPS，支持基於調用關係的限流 有限的支持 Rate Limiter
流量整形 支持預熱模式與勻速排隊控制效果 不支持 簡單的 Rate Limiter 模式
系統自適應保護 支持 不支持 不支持
多語言支持 Java/Go/C++ Java Java
Service Mesh 支持 支持 Envoy/Istio 不支持 不支持
控制檯 提供開箱即用的控制檯，可配置規則、實時監控、機器發現等 簡單的監控查看 不提供控制檯，可對接其它監控系統

總結

通過本教程，我們瞭解了流控降級作為高可用防護手段的重要性，瞭解了 Sentinel 的核心特性和原理，並通過動手實踐學習瞭如何快速接入 SCA Sentinel 來為微服務進行流控降級。Sentinel 還有著非常多的高級特性等著大家去發掘，如熱點防護、集群流控等，大家可以參考 Sentinel 官方文檔來了解更多的特性和場景。

那麼是不是服務的量級很小就不用進行限流防護了呢？是不是微服務的架構比較簡單就不用引入熔斷保護機制了呢？其實，這與請求的量級、架構的複雜程度無關。很多時候，可能正是一個非常邊緣的服務出現故障而導致整體業務受影響，造成巨大損失。我們需要具有面向失敗設計的意識，在平時就做好容量規劃和強弱依賴的梳理，合理地配置流控降級規則，做好事前防護，而不是在線上出現問題以後再進行補救。

同時，我們也在阿里雲上提供了 Sentinel 的企業版本 AHAS Sentinel，提供開箱即用的企業級高可用防護能力。與開源版本相比，AHAS 還提供以下的專業能力：

  • 可靠的實時監控和歷史秒級監控數據查詢，包含接口維度的 QPS、響應時間及系統 load、CPU 使用率等指標，支持按照調用類型分類，支持同比/環比展示
  • Top K 接口監控統計，快速瞭解系統的慢調用和大流量接口；熱力圖概覽，快速定位不穩定的機器
  • Java Agent 方式/K8s Java 應用零侵入快速接入，支持近 20 種主流框架和 API Gateway
  • 全自動託管、高可用的集群流量控制
  • Nginx 流量控制，支持規則動態配置、集群流控

歡迎大家體驗雲上企業版本的 Sentinel，同時也歡迎大家多多參與社區貢獻，一起幫助社區更好地進行演進。

對文檔有任何問題，請在評論區留言！

Leave a Reply

Your email address will not be published. Required fields are marked *