javascript
SpringCloud Alibaba之 Sentinel流量防卫兵
文章目錄
- 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 熔斷規則：異常比例
異常比例：這個與慢調用比例類似，不過這里判斷的是出現異常的次數，與上面一樣，我們也來進行一些小測試：
啟動服務器，接著添加我們的熔斷規則：
現在我們進行訪問，會發現后臺瘋狂報錯，然后就熔斷了：
回到目錄…
💎4.3 熔斷規則：異常數
異常數：這個和上面的唯一區別就是，只要達到指定的異常數量，就熔斷，這里我們修改一下熔斷規則：
現在我們再次不斷訪問此接口，可以發現，效果跟之前其實是差不多的，只是判斷的策略稍微不同罷了：
回到目錄…
💎4.4 精準服務降級
同樣，Sentinel 也支持我們進行方法級別細粒度的熔斷降級。
我們在需要控制的方法上添加 @SentinelResource 注解，可以配置 blockHandler 參數返回熔斷后的代替方案。
接著我們對進行熔斷配置，注意是對我們添加的@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流量防卫兵的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 锁相环(单相+陷波器)入门理解
- 下一篇： gradle idea java ssm