分布式系統之Sentinel介紹與使用
前言
在家休息的的時候，突然小勇打電話過來，問 農哥，你知道Sentinel嗎?
我(清了清嗓子)： 知道啊，怎么了?
小勇(帶著低落的聲音)： 最近面試了一個，問我Sentinel是什么，具體的用法和項目中使用的。沒有復習，記得不太清楚，dan疼。
我(是時候開始裝杯了)： 沒事，先揉揉，(Sentinel)不就是阿里開源的項目嗎，主要提供了流量控制、熔斷降級、系統負載保護等多個維度來保障服務之間的穩定性
小勇： 。。。。。你有沒有這方面可以復習的資料或者文章啥的?
我：還別說，剛好寫了一篇關于Sentinel 介紹和使用的文章，要不要瞅瞅?
小勇：可以，內容如何?算的上是教科書級別的內容吧?
我：恩.... 怎么不算呢!
小勇：。。。。。我真服了你這個老六!!!
學習技術第一步，先知道官網地址在哪里，官網永遠是第一手資料：https://github.com/alibaba/Sentinel/wiki。
接下來我們先來了解一下什么是Sentinel。
Sentinel 開篇
分布式系統的流量防衛兵： 隨著微服務的普及，服務調用的穩定性也變的越來越重要，Sentinel 以“流量”為切入點，在流量控制、斷路、負載保護等多個方面進行續航，保證服務的可靠性。
Sentinel 具有以下特征:
- 豐富的應用場景：Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺(即突發流量控制在系統容量可以承受的范圍)、消息削峰填谷、集群流量控制、實時熔斷下游不可用應用等。
- 完備的實時監控：Sentinel 同時提供實時的監控功能。您可以在控制臺中看到接入應用的單臺機器秒級數據，甚至 500 臺以下規模的集群的匯總運行情況。
- 廣泛的開源生態：Sentinel 提供開箱即用的與其它開源框架/庫的整合模塊，例如與 Spring Cloud、Apache Dubbo、gRPC、Quarkus 的整合。您只需要引入相應的依賴并進行簡單的配置即可快速地接入 Sentinel。同時 Sentinel 提供 Java/Go/C++ 等多語言的原生實現。
- 完善的 SPI 擴展機制：Sentinel 提供簡單易用、完善的 SPI 擴展接口。您可以通過實現擴展接口來快速地定制邏輯。例如定制規則管理、適配動態數據源等。
Sentinel 的主要特性：
Sentinel的妙用
當我們的分布式系統，面臨復雜的體系結構中應用程序可能有數十個依賴關系，每個依賴關系在某些時候將不可避免的失敗，比如我們調用 D\F\K 這幾個服務，如果這些服務中某一個出現問題了，那么有可能會出現整體系統效率的下降，嚴重的甚至出現服務雪崩。
多個微服務之間互相調用的時候，如果D調用K和F，而K和F又調用其他的微服務，那么就會形成扇出，如果扇出某個鏈路上的微服務調用超時或者響應很慢，那么微服務D就會占用越來越多的系統資源，從而導致系統崩潰，也就是服務雪崩。
對于高流量的應用來說，單一的后端依賴可能會導致服務器上的資源在極短的時間內被耗光，同時還有可能導致這些應用程序服務之間的響應時間增加，隊列、線程和其他系統資源變的緊缺，導致整個系統之間發生更多的次生故障，如果我們單個應用服務故障處理和延遲進行隔離管控，當單個依賴關系失敗時，不能對這個系統和資源產生影響，當某個模塊實例失敗以后，如果這個時候服務還能接收請求和流量訪問，同時這個服務還去調用其他模塊時，這樣的級聯故障，就會導致雪崩的發生。
對比與其他的斷流產品(Hystrix)而言，他不需要我們自己手動搭建監控平臺，而且它有一套屬于自己的Web界面，可對多種指標進行流控、熔斷，且提供了實時監控和控制面板，功能更為強大。
Sentinel 使用
下載地址：https://github.com/alibaba/Sentinel/releases。
Sentinel 分為兩個部分：
- 核心庫：不依賴任何框架/庫，只需要Java運行時環境，同時對Dubbo\SpringCloud等框架也有很好的支持。
- 控制臺：基于SpringBoot開發，打包后可以直接運行，不需要額外的應用容器。
注意：jdk1.8環境/8080端口不能被占用。
啟動命令：java -jar sentinel-dashboard-1.8.4.jar。
訪問地址：http://localhost:8080/。
賬號密碼：sentinel/sentinel。
到這里呢，我們的Sentinel就安裝成功了，可能有點同學在界面上沒有看到任何東西，并沒有發現監控的服務，這是因為我們還沒有啟動項目，而Sentinel 本身采用的是懶加載模式，所以我們需要先去訪問服務對應的接口，Sentinel才會進行工作，接下來我們就來搭建我們的測試項目。
搭建項目
Sentinel 官方參考文檔：https://sentinelguard.io/zh-cn/docs/quick-start.html。
注意： 這里我們使用到了Nacos，不會Nacos的小伙伴，可以看我之前的文章，里面有詳細的介紹,其實只需要你啟動一個端口為8848的Nacos就行。
導入依賴：
<!-- Nacos客戶端依賴 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
<!-- sentinel依賴 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
配置屬性：
server:
port: 8006
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
sentinel:
transport:
#配置Sentinel地址，就是我們的WEB界面
dashboard: localhost:8080
#Sentinel配置默認8719端口，被占用端口會自動從+1，直到找到未被占用的端口
port: 8719
management:
endpoints:
web:
exposure:
include: '*'
測試類：
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.concurrent.TimeUnit;
@RestController
public class TestController {
@GetMapping("/playA")
public String playA() {
return "hello my name is playA ,wo shi boy";
}
@GetMapping("/playB")
public String playB(){
return "hi my name is playB， me girl";
}
}
最后在我們的啟動類上加上 ：@EnableDiscoveryClient，點擊啟動，然后我們來訪問我們的測試地址：
http://localhost:8006/playA。
http://localhost:8006/playB。
訪問之后，我們就能在Sentinel上看到我們的監控信息了，如下所示：
好了，你們以為到這里Sentinel就講解完了嗎?哎~怎么可能，我還要繼續卷，寧愿累死自己，也要卷死你們!雖然基本操作已經完成，但是不講一下他的 流控規則 ，我們怎么能印象深刻呢?是吧，各位大漂亮和大聰明們。
Sentinel 流控規則
首先我們先來看一張圖：
上面這張圖，就包含了，我們要講解的全部內容，主要分為以下幾點：
資源名：流控規則中唯一的名稱，默認為我們的請求路徑。
針對來源：Sentinel 對調用者進行限流，填寫我們的微服務名，默認為default，對來源不進行區分。
閾值類型/單機閾值：
- QPS(每秒請求數量)，使用該類型時，QPS達到我們設置的單機閾值，進行限流。
- 線程數：當使用該類型時，線程數量達到我們設置的單機閾值，進行限流。
是否集群：默認否，如果是集群勾選。
流控模式：
- 直接：API達到限流條件時，直接限流，如果我們設置QPS為1，如果大于這個數量，直接返回錯誤。
- 關聯：當關聯的資源達到閾值時，限流自己，比如A調用B，B達到了閾值，A進行限流。
- 鏈路：只記錄鏈路上的流量，指定對應的鏈路路徑，從入口開始，如果達到閾值，則進行限流。
流控效果：
我們先來新增一個流控規則看一下，操作方式有兩種。
因為方便，我們一般會選擇在簇點鏈路中添加，我們先來試一下QPS的操作：
- 快速失敗：直接拋異常。
- Warm Up：根據冷加載因子codeFactor 經過預熱時長，才達到設置的QPS閾值。
- 排隊等待：勻速排隊，讓請求以勻速速度進行請求，閾值類型，需要設置為QPS，否則無效。
- 在流控規則中添加。
- 在簇點鏈路中添加。
這里我們設置單機閾值為1，所以playA 這個接口一秒中只能被訪問一次，如果超過，則進行限流操作進行一個阻塞操作，這個效果我們是可以直接看到的，當我們不停的刷新playA時，就會現在如下信息，而沒有設置的playB,則不會。
在這里我們如果設置為線程數會怎么樣呢?我們來看一下。
在這里我們要注意：如果項目重新啟動，需要將修改后的playA,重新訪問后重新，添加流控規則。
同時我們需要在代碼中設置延時執行，如果處理太快，我們是看不到實際效果的，如果有興趣的小伙伴可以自己啟動線程去跑，在這里我們設置playA，進行一秒鐘的延時操作。
@GetMapping("/playA")
public String playA() {
try {
//阻塞1 秒
TimeUnit.MILLISECONDS.sleep(1000);
}catch (Exception e){
e.printStackTrace();
}
return "hello my name is playA ,wo shi boy";
}
這里要使用兩個不同瀏覽器去跑，同一個瀏覽器使用的是同一線程，先請求的某歌后請求的某火效果如下所示：
QPS和并發線程數的規則如下所示：
總結
雖然最終效果是一樣的，但是規則是不同的，每種應對不用的業務場景，大家可以合理化的去使用，到這里我們的Sentinel就講完了，后面還有更多有關于Sentinel的原理和介紹。
