文章目錄

• Sentinel 流量防衛兵
• • 一、安裝與部署
  • • 🔆1.1 服務端 JAR 包
    • 🔆1.2 客戶端掛載
    • 🔆1.3 Sentinel Dashboard 監控
  • 二、流量控制
  • • 🎀2.1 流量控制算法
    • 🎀2.2 流控規則
    • 🎀2.3 @SentinelResource 對方法流控
    • 🎀2.4 示例：對接口流控
    • 🎀2.5 系統規則
  • 三、熱點參數限流
  • 四、服務熔斷和降級
  • • 💎4.1 熔斷規則：慢調用比例
    • 💎4.2 熔斷規則：異常比例
    • 💎4.3 熔斷規則：異常數
    • 💎4.4 精準服務降級
    • 💎4.5 遠程調用中的服務熔斷
  • 五、限流 / 熔斷后的異常處理
  • • 🔑5.1 接口異常處理
    • 🔑5.2 方法中 sentinel 異常的處理
    • 🔑5.3 方法中其它異常的處理

---

提示：以下是本篇文章正文內容，SpringCloud Alibaba 系列學習將會持續更新

Spring Cloud Alibaba 官方學習文檔

Sentinel 流量防衛兵

See the 中文文檔 for document in Chinese.

經過之前的學習，我們了解了微服務存在的雪崩問題，也就是說一個微服務出現問題，有可能導致整個鏈路直接不可用，這種時候我們就需要進行及時的熔斷和降級，這些策略，我們之前通過使用 Hystrix 來實現。

SpringCloud Alibaba 也有自己的微服務容錯組件，但是它相比 Hystrix 更加的強大。

隨著微服務的流行，服務和服務之間的穩定性變得越來越重要。Sentinel 是面向分布式、多語言異構化服務架構的流量治理組件，主要以流量為切入點，從流量路由、流量控制、流量整形、熔斷降級、系統自適應過載保護、熱點流量防護等多個維度來幫助開發者保障微服務的穩定性。

Sentinel 具有以下特征:

• 豐富的應用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺（即突發流量控制在系統容量可以承受的范圍）、消息削峰填谷、集群流量控制、實時熔斷下游不可用應用等。
• 完備的實時監控：Sentinel 同時提供實時的監控功能。您可以在控制臺中看到接入應用的單臺機器秒級數據，甚至 500 臺以下規模的集群的匯總運行情況。
• 廣泛的開源生態：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相應的依賴并進行簡單的配置即可快速地接入 Sentinel。同時 Sentinel 提供 Java/Go/C++ 等多語言的原生實現。
• 完善的 SPI 擴展機制：Sentinel 提供簡單易用、完善的 SPI 擴展接口。您可以通過實現擴展接口來快速地定制邏輯。例如定制規則管理、適配動態數據源等。

一、安裝與部署

🔆1.1 服務端 JAR 包

它和 Nacos一樣，它是獨立安裝和部署的，下載地址：https://github.com/alibaba/Sentinel/releases

注意下載下來之后是一個 jar 文件（其實就是個SpringBoot項目），我們需要在 IDEA 中部署：

啟動之后，就可以訪問到 Sentinel 的監控頁面了，用戶名和密碼都是 sentinel，地址：http://localhost:8858

🔆1.2 客戶端掛載

這樣就成功開啟監控頁面了，接著我們需要讓我們的服務連接到 Sentinel 控制臺，老規矩，導入依賴：

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

然后在配置文件中添加 Sentinel 相關信息（實際上 Sentinel 是本地在進行管理，但是我們可以連接到監控頁面，這樣就可以圖形化操作了）：

spring:application:name: userservicecloud:nacos:discovery:server-addr: localhost:8848sentinel:transport:# 添加監控頁面地址即可dashboard: localhost:8858

🔆1.3 Sentinel Dashboard 監控

現在啟動我們的服務，然后訪問一次服務，這樣 Sentinel 中就會存在信息了（懶加載機制，不會一上來就加載）：


現在我們就可以在 Sentinel 控制臺中對我們的服務運行情況進行實時監控了，可以看到監控的內容非常的多，包括時間點、QPS(每秒查詢率)、響應時間等數據。

按照上面的方式，我們將所有的服務全部連接到 Sentinel 管理面板中。

回到目錄…

二、流量控制

前面我們完成了對 Sentinel 的搭建與連接，接著我們來看看Sentinel的第一個功能，流量控制。

我們的機器不可能無限制的接受和處理客戶端的請求，如果不加以限制，當發生高并發情況時，系統資源將很快被耗盡。為了避免這種情況，我們就可以添加流量控制（也可以說是限流）。當一段時間內的流量到達一定的閾值的時候，新的請求將不再進行處理，這樣不僅可以合理地應對高并發請求，同時也能在一定程度上保護服務器不受到外界的惡意攻擊。

那么要實現限流，正常情況下，我們該采取什么樣的策略呢？

• 方案一：快速拒絕，既然不再接受新的請求，那么我們可以直接返回一個拒絕信息，告訴用戶訪問頻率過高。
• 方案二：預熱，依然基于方案一，但是由于某些情況下高并發請求是在某一時刻突然到來，我們可以緩慢地將閾值提高到指定閾值，形成一個緩沖保護。
• 方案三：排隊等待，不接受新的請求，但是也不直接拒絕，而是進隊列先等一下，如果規定時間內能夠執行，那么就執行，要是超時就算了。

🎀2.1 流量控制算法

漏桶算法
顧名思義，就像一個桶開了一個小孔，水流進桶中的速度肯定是遠大于水流出桶的速度的，這也是最簡單的一種限流思路：

我們知道，桶是有容量的，所以當桶的容量已滿時，就裝不下水了，這時就只有丟棄請求了。
利用這種思想，我們就可以寫出一個簡單的限流算法。

令牌桶算法
只能說有點像信號量機制。現在有一個令牌桶，這個桶是專門存放令牌的，每隔一段時間就向桶中丟入一個令牌（速度由我們指定）當新的請求到達時，將從桶中刪除令牌，接著請求就可以通過并給到服務，但是如果桶中的令牌數量不足，那么不會刪除令牌，而是讓此數據包等待。

可以試想一下，當流量下降時，令牌桶中的令牌會逐漸積累，這樣如果突然出現高并發，那么就能在短時間內拿到大量的令牌。

固定時間窗口算法
我們可以對某一個時間段內的請求進行統計和計數，比如在14:15~14:16這一分鐘內，請求量不能超過100，也就是一分鐘之內不能超過 100次請求，那么就可以像下面這樣進行劃分：

雖然這種模式看似比較合理，但是試想一下這種情況：14:15:59的時候來了100個請求、14:16:01的時候又來了100個請求
出現上面這種情況，符合固定時間窗口算法的規則，所以這 200個請求都能正常接受，但是，你應該發現了，我們其實希望的是 60秒內只有100個請求，但是這種情況卻是在 3秒內出現了200個請求，很明顯已經違背了我們的初衷。
因此，當遇到臨界點時，固定時間窗口算法存在安全隱患。

滑動時間窗口算法
相對于固定窗口算法，滑動時間窗口算法更加靈活，它會動態移動窗口，重新進行計算：

雖然這樣能夠避免固定時間窗口的臨界問題，但是這樣顯然是比固定窗口更加耗時的。

回到目錄…

🎀2.2 流控規則

了解完了我們的限流策略和判定方法之后，我們在 Sentinel 中進行實際測試一下，打開管理頁面的簇點鏈路模塊 -> 流控：

這里演示對我們的圖書接口進行限流，點擊流控，會看到讓我們添加流控規則：

• 閾值類型：QPS就是每秒鐘的請求數量，并發線程數是按服務當前使用的線程數據進行統計的。
  

• 流控模式：當達到閾值時，流控的對象，這里暫時只用直接。
  直接：只針對于當前接口。
  關聯：當其他接口超過閾值時，會導致當前接口被限流。
  鏈路：更細粒度的限流，能精確到具體的方法。
  

• 流控效果：就是我們上面所說的三種方案。
  

回到目錄…

🎀2.3 @SentinelResource 對方法流控

上面我們學過的流控規則都是對某個接口進行的限流，這里我們講解一下@SentinelResource 的使用，對某個方法進行限流。

①我們先在控制層新增一個接口，但實際上和之前的接口內容一樣，調用同樣的方法。

②@SentinelResource 監控此方法，無論被誰執行都在監控范圍內，這里給的 value 是自定義名稱，這個注解可以加在任何方法上，包括 Controller 中的請求映射方法，跟 @HystrixCommand 賊像

③我們這里創建兩個請求映射，都來調用 Service 的被監控方法，需要配置它們單獨控制：

spring:application:name: bookservicecloud:sentinel:transport:dashboard: localhost:8858# 關閉 Context 收斂，這樣被監控方法可以進行不同鏈路的單獨控制web-context-unify: false

④然后我們在 Sentinel 控制臺中對該方法添加流控規則：

最后我們在瀏覽器中對 /book/{bid} 和 /book2/{bid} 這兩個接口都進行測試，會發現無論請求哪個接口，只要調用了 Service 中的getBookById(int bid) 這個方法，都會被限流。

回到目錄…

🎀2.4 示例：對接口流控

①QPS 閾值為1，流控模式: 直接，流控效果: 快速失敗。

當我們快速地進行請求時 (每秒超過1次)，會直接返回失敗信息：

②QPS 閾值為3，流控模式: 直接，流控效果: Warm up 緩存預熱。

這樣的緩存預熱可以在10秒內，將單機閾值提升到每秒3次。

③QPS 閾值為1，流控模式: 關聯 /error，流控效果: 快速失敗。

當我們快速地請求自帶的/error接口時 (每秒超過1次)，會關聯的影響到我們的/book接口。

我們使用 PostMan 的 Runner 連續對關聯資源發起請求：

開啟Postman，然后我們會發現圖書服務已經涼涼。當我們關閉掉 Postman 的任務后，恢復正常。

④QPS 閾值為1，流控模式: 鏈路，流控效果: 快速失敗。

最后我們來講解一下鏈路模式，它能夠更加精準的進行流量控制。鏈路流控模式指的是當從指定接口過來的資源請求達到限流條件時，開啟限流。

我們在上面學習了@SentinelResource 對方法流控，這種方案會對調用該方法的 /book/{uid} 和 /book2/{uid} 都進行限流。
而這個鏈路選項實際上就是決定只限流從哪個方向來的調用，比如我們只對/book2這個接口對getBook(int uid) 方法的調用進行限流，那么我們就可以為其指定鏈路：

此時我們會發現，限流效果只對我們配置的鏈路接口有效，而其他鏈路是不會被限流的。

回到目錄…

🎀2.5 系統規則

除了直接對接口進行限流規則控制之外，我們也可以根據當前系統的資源使用情況，決定是否進行限流：

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

• 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 達到閾值即觸發系統保護。

回到目錄…

三、熱點參數限流

我們還可以對某一熱點數據進行精準限流，比如在某一時刻，不同參數被攜帶訪問的頻率是不一樣的：

• http://localhost:8081/param?a=10 訪問100次
• http://localhost:8081/param?b=10 訪問0次
• http://localhost:8081/param?c=10 訪問3次

由于攜帶參數a的請求比較多，我們就可以只對攜帶參數a的請求進行限流。

①這里我們創建一個新的測試請求映射：

@RestController public class ParamController {@GetMapping("/param")@SentinelResource("getParam") // 必須添加該注解，才能設置參數精準限流public String getParamABC(@RequestParam(value = "a", required = false) String a,@RequestParam(value = "b", required = false) String b,@RequestParam(value = "c", required = false) String c) {return "{a = " + a + ", b = " + b + ", c = " + c + "}";} }

②啟動之后，我們在 Sentinel 的熱點規則模塊進行熱點配置：

③然后開始訪問我們的測試接口，分別攜帶3個參數進行超閾值請求：

④除了直接對某個參數精準限流外，我們還可以對參數攜帶的指定值單獨設定閾值。
?比如我們可以對參數b限流閾值放寬到 20，但當參數b=8時，QPS 達到1就限流：

這樣，將按照我們指定的特例進行限流

回到目錄…

四、服務熔斷和降級

還記得我們前所說的服務降級嗎，也就是說我們需要在整個微服務調用鏈路出現問題的時候，及時對服務進行降級，以防止問題進一步惡化。

那么，各位是否有思考過，如果在某一時刻，服務B 出現故障（可能就卡在那里了），而這時服務A 依然有大量的請求，在調用服務B，那么，由于服務A 沒辦法再短時間內完成處理，新來的請求就會導致線程數不斷地增加，這樣，CPU 的資源很快就會被耗盡。

那么要防止這種情況，就只能進行隔離了，這里我們提兩種隔離方案：

線程池隔離
線程池隔離實際上就是對每個服務的遠程調用單獨開放線程池，比如服務A 要調用服務B，那么只基于固定數量的線程池，這樣即使在短時間內出現大量請求，由于沒有線程可以分配，所以就不會導致資源耗盡了。相當于讓不同的服務調用，去各自的線程池中獲取資源去請求，從而不會消耗其它服務調用的資源 和 CPU的資源。

信號量隔離
信號量隔離是使用 Semaphore 類實現的（如果不了解，可以觀看本系列 并發編程篇 視頻教程），思想基本上與上面是相同的，也是限定指定的線程數量能夠同時進行服務調用，但是它相對于線程池隔離，開銷會更小一些，使用效果同樣優秀，也支持超時等。

Sentinel 也正是采用的這種方案實現隔離的。

好了，說回我們的熔斷和降級，當下游服務因為某種原因變得不可用或響應過慢時，上游服務為了保證自己整體服務的可用性，不再繼續調用目標服務而是快速返回或是執行自己的替代方案，這便是服務降級。

整個過程分為三個狀態：

• 關閉：熔斷器不工作，所有請求全部該干嘛干嘛。
• 打開：熔斷器工作，所有請求一律降級處理。
• 半開：嘗試進行一下下正常流程，要是還不行繼續保持打開狀態，否則關閉。

那么我們來看看 Sentinel 中如何進行熔斷和降級操作，打開管理頁面，我們可以自由新增熔斷規則，其中熔斷策略有三種模式：

回到目錄…

💎4.1 熔斷規則：慢調用比例

慢調用比例：如果出現那種半天都處理不完的調用，有可能就是服務出現故障，導致卡頓，這個選項是按照最大響應時間（RT）進行判定。如果一次請求的處理時間超過了指定的 RT，那么就被判定為慢調用。在一個統計時長內，如果請求數目大于最小請求數目，并且被判定為慢調用的請求比例已經超過閾值，將觸發熔斷。經過熔斷時長之后，將會進入到半開狀態進行試探（這里和Hystrix一致）

然后創建一個接口，來模擬一下慢調用：

@GetMapping("/slow") public String slow() throws InterruptedException {Thread.sleep(500);return "這是一個慢比例調用！"; }

重啟，然后我們創建一個新的熔斷規則：

可以看到，熔斷規則內是可以正常訪問的：

但是突破熔斷規則時，就會服務熔斷：

回到目錄…

💎4.2 熔斷規則：異常比例

異常比例：這個與慢調用比例類似，不過這里判斷的是出現異常的次數，與上面一樣，我們也來進行一些小測試：

@GetMapping("/ecpPCT") public String EcpPCT() {int n = (int) (Math.random() * 10);if(n % 2 == 0) {throw new RuntimeException("運行時異常: " + n);}return "異常比例測試"; }

啟動服務器，接著添加我們的熔斷規則：

現在我們進行訪問，會發現后臺瘋狂報錯，然后就熔斷了：

回到目錄…

💎4.3 熔斷規則：異常數

異常數：這個和上面的唯一區別就是，只要達到指定的異常數量，就熔斷，這里我們修改一下熔斷規則：

現在我們再次不斷訪問此接口，可以發現，效果跟之前其實是差不多的，只是判斷的策略稍微不同罷了：

回到目錄…

💎4.4 精準服務降級

同樣，Sentinel 也支持我們進行方法級別細粒度的熔斷降級。
我們在需要控制的方法上添加 @SentinelResource 注解，可以配置 blockHandler 參數返回熔斷后的代替方案。

@GetMapping("/test2") @SentinelResource(value = "testMethod", blockHandler = "block") public String testMethod() {throw new RuntimeException(); }public String block(BlockException e) {return "發生服務降級/熔斷了"; }

接著我們對進行熔斷配置，注意是對我們添加的@SentinelResource中指定名稱的testMethod進行配置：

OK，可以看到熔斷降級之后的效果：

回到目錄…

💎4.5 遠程調用中的服務熔斷

我們上面學的都是在一個微服務中，對接口或方法訪問時，進行了降級和熔斷。那此時，我們還需要知道在微服務之間的遠程調用過程中，某個微服務出現問題導致無法訪問時，我們該如何做熔斷和降級呢？

我們以 borrowservice 的 /borrow/{uid} 接口中的遠程調用為例進行講解吧！

方案一：OpenFeign 實現降級熔斷：

• Feign 集成了 Spring Cloud CircuitBreaker斷路器，實現了熔斷降級的功能。
• 但是，之前我們在使用時發現，Feign 的降級需要依靠 Hystrix 組件來實現，所以那時我們的啟動類依然需要用 @EnableHystrix 注解來修飾。
  參考往期文章：SpringCloud之 Hystrix服務熔斷 的 OpenFeign 實現降級 模塊
• 其實，我們今天學習的 sentinel 也支持 feign 的使用，這樣我們就不再需要廢棄的 Hystrix 組件了。

①首先我們需要在配置文件中開啟 sentinel 對 feign 的支持：

feign:sentinel:enabled: true

②我們給 borrowservice 中的 BookClient 接口創建替代實現類：

@Component public class BookClientFallback implements BookClient {@Overridepublic Book findBookById(int bid) {return new Book(-1, "代替方案", "");} }

③為 BookClient 接口指定替代方案，使用 @FeignClient 注解的 fallback 屬性

@FeignClient(value = "bookservice", fallback = BookClientFallback.class) public interface BookClient {@GetMapping("/book/{bid}")Book findBookById(@PathVariable("bid") int bid); }

④然后直接啟動就可以了，中途的時候我們把圖書服務全部下掉，可以看到正常使用替代方案：

這樣 Feign 的配置就OK了，

方案二：@SentinelRestTemplate 實現降級熔斷：

原本傳統的 RestTemplate 需要借助 @SentinelRestTemplate注解實現：

@Bean @LoadBalanced @SentinelRestTemplate(blockHandler = "handleException", blockHandlerClass = ExceptionUtil.class,fallback = "fallback", fallbackClass = ExceptionUtil.class) // 這里同樣可以設定 fallback 等參數 public RestTemplate restTemplate() {return new RestTemplate(); }

這里就不多做贅述了。

回到目錄…

五、限流 / 熔斷后的異常處理

現在我們已經了解了如何進行限流、服務熔斷降級操作，那么這些狀態下的返回結果該怎么修改呢，我們看到返回的是 Sentinel 默認的數據，現在我們希望自定義改如何操作？不僅僅是限流、服務降級熔斷，只要是 Sentinel 包括的異常都可以處理。

🔑5.1 接口異常處理

這里我們先創建好被限流狀態下需要返回的內容，定義一個請求映射：

@Controller public class BlockedController {@RequestMapping("/blocked")public JSONObject blocked(){JSONObject object = new JSONObject();object.put("code", 403);object.put("success", false);object.put("massage", "您的請求頻率過快，請稍后再試！");return object;} }

接著我們在配置文件中將此頁面設定為限流頁面：

spring:cloud:sentinel:transport:dashboard: localhost:8858# 將剛剛編寫的請求映射設定為限流頁面block-page: /blocked

默認的返回結果：

修改后，當被限流時，就會被重定向到指定頁面：

回到目錄…

🔑5.2 方法中 sentinel 異常的處理

那么，對于方法級別的限流呢？經過前面的學習我們知道，當某個方法被限流時，會直接在后臺拋出異常，那么這種情況我們該怎么處理呢？

比如我們之前在 Hystrix 中可以直接添加一個替代方案，@HystrixCommand(fallbackMethod = "onError")，這樣當出現異常時會直接執行我們的替代方法并返回，Sentinel 也可以。

比如我們還是在 getBookById(int bid) 方法上進行配置：注意blockHandler只能處理限流情況下拋出的異常

@Override @SentinelResource(value = "getBook", blockHandler = "blocked") //監控此方法，無論被誰執行都在監控范圍內，這里給的value是自定義名稱，這個注解可以加在任何方法上，包括Controller中的請求映射方法，跟HystrixCommand賊像 public Book getBookById(int bid) {return bookMapper.getBookById(bid); }// 替代方案，注意參數和返回值需要保持一致，并且參數最后還需要額外添加一個 BlockException public Book blocked(int bid, BlockException e) {return new Book(-1, "", ""); }

可以看到，一旦被限流將執行替代方案，最后返回的結果就是：

回到目錄…

🔑5.3 方法中其它異常的處理

如果是方法本身拋出的其他類型異常，不在blockHandler管控范圍內，但是可以通過@SentinelResource的其它參數進行處理：

@RestController public class FallbackController {@GetMapping("/test")@SentinelResource(value = "testFallback",fallback = "except", // 指定異常時的替代方案blockHandler = "block", // 出現限流時的替代方案exceptionsToIgnore = IOException.class) // 可以忽視的異常，出現該異常時不使用替代方案public String testFallback() {throw new RuntimeException("出現了運行時異常");}// 替代方法必須和原方法返回值和參數一致，最后可以添加一個Throwable作為參數接受異常public String except(Throwable t) {return t.getMessage();} }

我們給剛剛作了異常處理的方法，設置了流控：

這樣，其它的異常也可以有替代方案了：

同樣的，當超閾值訪問時，Sentinel 的限流異常也可以處理：

特別注意：

• 如果在沒有配置 blockHandler 的情況下，fallback 會將 Sentinel 機制內（限流、熔斷）的異常也一并處理了。
• 如果配置了 blockHandler，那么在出現限流/熔斷時，依然只會執行 blockHandler指定的替代方案（因為限流是在方法執行之前進行的）。

回到目錄…

---

總結:
提示：這里對文章進行總結：
本文是對Sentinel 流量防衛兵的學習，學習了 Sentinel 的安裝與部署，還使用了它提供的功能：流量控制、服務降級熔斷，并且還可以自定義sentinel異常的處理方案。之后的學習內容將持續更新！！！

總結

以上是生活随笔為你收集整理的SpringCloud Alibaba之 Sentinel流量防卫兵的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。