阿里的Sentinel流量防衛兵

Sentinel是什麼鬼？又要學習新的技術了。

每當看到這個圖，我又開始學習之路了。

Sentinel

隨著分佈式系統變得越來越流行，服務之間的可靠性變得比以往任何時候都更加重要。 Sentinel是強大的流控制組件，以“流”為切入點，涵蓋多個領域，包括流控制，併發限制，熔斷和自適應系統保護，以確保微服務的可靠性。

2012年，Sentinel誕生於阿里巴巴，其主要目標是流量控制。2013-2017年，Sentinel迅速發展，併成為阿里巴巴所有微服務的基本組成部分。 它已在6000多個應用程序中使用，涵蓋了幾乎所有核心電子商務場景。2018年，Sentinel演變為一個開源項目。2020年，Sentinel Golang發佈。

Sentinel的生態圈

Sentinel 主要特性

Sentinel 的使用可以分為兩個部分:

• 核心庫（Java 客戶端）：不依賴任何框架/庫，能夠運行於 Java 7 及以上的版本的運行時環境，同時對 Dubbo / Spring Cloud 等框架也有較好的支持。
• 控制檯（Dashboard）：控制檯主要負責管理推送規則、監控、集群限流分配管理、機器發現等。

在這裡我們看下控制檯的使用

控制檯安裝

下載地址：
https://github.com/alibaba/Sentinel/releases，
sentinel-dashboard-1.7.2.jar

本地需要先安裝好Java8環境，8080端口沒被佔用。

cmd安裝目錄，運行命令java -jar
sentinel-dashboard-1.7.2.jar

訪問http://localhost:8080/

默認賬號密碼都為sentinel,登陸進去，控制檯安裝完畢。

功能使用

還是以之前講解Nacos的項目，講解sentinel的使用，新建一個模塊
cloudalibaba-sentinel-8401。

引入依賴

<code>      
    
<
dependency
>

        
<
artifactId
>
springcloud-commom
artifactId
>

        
<
groupId
>
com.learn.springcloud
groupId
>

        
<
version
>
1.0-SNAPSHOT
version
>

    
 
dependency
>

     
    
<
dependency
>

        
<
groupId
>
com.alibaba.cloud
groupId
>

        
<
artifactId
>
spring-cloud-starter-alibaba-nacos-discovery
artifactId
>

    
dependency
>

     
    
<
dependency
>

        
<
groupId
>
com.alibaba.cloud
groupId
>

        
<
artifactId
>
spring-cloud-starter-alibaba-sentinel
 
artifactId
>

    
dependency
>

     
    
<
dependency
>

        
<
groupId
>
org.springframework.boot
groupId
>

        
<
artifactId
>
spring-boot-starter-web
artifactId
>

    
dependency
>

    
<
dependency
>

        
<
groupId
>
org.springframework.boot
groupId
>

        
< 
artifactId
>
spring-boot-starter-actuator
artifactId
>

    
dependency
>
/<code>

添加配置文件application.yml

<code>
server:
  
port:
 
8401

spring:
  
application:
    
name:
 
cloudalibaba-sentinel-service
  
cloud:
    
nacos:
      
discovery:
        
server-addr:
 
localhost:8848
  
    
sentinel:
      
transport:
        
dashboard:
 
localhost:8080
  
        
port:
 
8719 


management:
  
endpoints:
    
web:
      
exposure:
        
include:
 
'*'
/<code>

controller

<code> 
public
 
class
 
FlowLimitController
 
{

	 
	
public
 String testA()
	{
		
return
 
"------hello sentinel-----------"
;
	}
}/<code>

啟動類添加@EnableDiscoveryClient註解，先啟動nacos，啟動項目。

啟動成功，服務已註冊到nacos。

訪問請求，
http://localhost:8401/test。

刷新sentinel控制檯，點擊簇點鏈路。

點擊流控，或下面的流控規則。那具體這些是幹嘛用的？下面將一一介紹。

流控規則

資源名：唯一名稱，默認請求路徑

針對卡片：Sentinel可以針對調用者進行限流，填寫微服務名，默認為default(不區分來源)

閾值類型/單機閾值：

1.QPS：每秒請求數，當前調用該api的QPS到達閾值的時候進行限流

2.線程數：當調用該api的線程數到達閾值的時候，進行限流

是否集群：是否為集群

流控模式：

1.直接：當api大達到限流條件時，直接限流

2.關聯：當關聯的資源到達閾值，就限流自己

3.鏈路：只記錄指定路上的流量，指定資源從入口資源進來的流量，如果達到閾值，就進行限流，api級別的限流

舉例，先看流控模式為直接

選擇QPS，直接，快速失敗，單機閾值為1。

頻繁刷新請求，1秒訪問1次請求，正常，超過設置的閾值，將報默認的錯誤。

再次的1秒訪問1次請求，訪問正常。

流控模式為關聯

添加一個請求

<code> 
public
 String testGualian()
{
   
return
 
"------testGualian-----------"
;
}/<code>

選擇QPS，單機閾值為1，選擇關聯，關聯資源為/testGualian，這裡用Jmeter模擬高併發，請求/testGualian。

在大批量線程高併發訪問/testGualian，導致/test失效了

鏈路就不再演示了。多個請求調用同一微服務。

流控模式為Warm up（預熱）

當流量突然增大的時候，我們常常會希望系統從空閒狀態到繁忙狀態的切換的時間長一些。即如果系統在此之前長期處於空閒的狀態，我們希望處理請求的數量是緩步的增多，經過預期的時間以後，到達系統處理請求個數的最大值。Warm Up（冷啟動，預熱）模式就是為了實現這個目的的。

默認 coldFactor 為 3，即請求 QPS 從 threshold / 3 開始，經預熱時長逐漸升至設定的 QPS 閾值。

先在單機閾值10/3，3的時候，預熱5秒後，慢慢將閾值升至10。剛開始刷/test，會出現默認錯誤，預熱時間到了後，閾值增加，沒超過閾值刷新，請求正常。

通常冷啟動的過程系統允許通過的 QPS 曲線如下圖所示：

如秒殺系統在開啟瞬間，會有很多流量上來，很可能把系統打死，預熱方式就是為了保護系統，可慢慢的把流量放進來，慢慢的把閾值增長到設置的閾值。

流控模式為排隊等待

勻速排隊（
RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式會嚴格控制請求通過的間隔時間，也即是讓請求以均勻的速度通過，對應的是漏桶算法。閾值必須設置為QPS。

這種方式主要用於處理間隔性突發的流量，例如消息隊列。想象一下這樣的場景，在某一秒有大量的請求到來，而接下來的幾秒則處於空閒狀態，我們希望系統能夠在接下來的空閒期間逐漸處理這些請求，而不是在第一秒直接拒絕多餘的請求。

總結

到這已經學習Sentinel的基本的使用，在很多的特性和Hystrix有很多類似的功能。以下是Sentinel和Hystrix的對比。

後續將介紹Sentinel其他內容。