是阿裡巴巴開源的，面向分布式服務架構的流量控制元件，主要以流量為切入點，從限流、流量整形、熔斷降級、系統自适應保護等多個次元來幫助開發者保障微服務的穩定性。Sentinel 承接了阿裡巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺、冷啟動、消息削峰填谷、叢集流量控制、實時熔斷下遊不可用服務等，是保障微服務高可用的利器，原生支援 Java/Go/C++ 等多種語言，并且提供 Istio/Envoy/SOFA MOSN 全局流控支援來為 Service Mesh 提供高可用防護的能力。
近期，
Sentinel Go 0.4.0正式釋出，帶來了
熱點參數流控特性，可以自動識别統計傳入參數中的“熱點”參數值并分别進行流控，對于防刷、熱點商品通路頻次控制等場景非常有用，是高可用流量防護中重要的一環。下面我們來了解一下熱點參數流控的場景和原理。
熱點流量防護介紹
流量是随機的，不可預測的。為了防止被大流量打垮，我們通常會對核心接口配置限流規則，但有的場景下配置普通的流控規則是不夠的。我們來看這樣一種場景——大促峰值的時候，總是會有不少“熱點”商品，這些熱點商品的瞬時通路量非常高。一般情況下，我們可以事先預測一波熱點商品，并對這些商品資訊進行緩存“預熱”，以便在出現大量通路時可以快速傳回而不會都打到 DB 上。但每次大促都會湧現出一些“黑馬”商品，這些“黑馬”商品是我們無法事先預測的，沒有被預熱。當這些“黑馬”商品通路量激增時，大量的請求會擊穿緩存，直接打到 DB 層，導緻 DB 通路緩慢，擠占正常商品請求的資源池，最後可能會導緻系統挂掉。這時候，利用 Sentinel 的熱點參數流量控制能力，自動識别熱點參數并控制每個熱點值的通路 QPS 或并發量，可以有效地防止過“熱”的參數通路擠占正常的調用資源。
再比如有的場景下我們希望限制每個使用者調用某個 API 的頻率，将 API 名稱+userId 作為埋點資源名顯然是不合适的。這時候我們可以在給 API 埋點的時候通過
WithArgs(xxx)
将 userId 作為參數傳入到 API 埋點中，然後配置熱點規則即可針對每個使用者分别限制調用頻率；同時，Sentinel 也支援針對某些具體值單獨配置限流值，進行精細化流控。
熱點參數埋點/規則示例：
// 埋點示例
e, b := sentinel.Entry("my-api", sentinel.WithArgs(rand.Uint32()%3000, "sentinel", uuid.New().String()))
// 規則示例
_, err = hotspot.LoadRules([]*hotspot.Rule{
{
Resource: "my-api",
MetricType: hotspot.QPS, // 請求量模式
ControlBehavior: hotspot.Reject,
ParamIndex: 0, // 參數索引，0 即為第一個參數
Threshold: 50, // 針對每個熱點參數值的門檻值
BurstCount: 0,
DurationInSec: 1, // 統計視窗時長，這裡為 1s
SpecificItems: map[hotspot.SpecificValue]int64{
// 支援針對某個具體值單獨配置限流值，比如這裡針對數值 9 限制請求量=0（不允許通過）
{ValKind: hotspot.KindInt, ValStr: "9"}: 0,
},
},
}) 像其他規則一樣，熱點流控規則同樣支援通過動态資料源進行動态配置。
Sentinel Go 提供的 RPC 架構整合子產品（如 Dubbo、gRPC）均會自動将 RPC 調用的參數清單附帶在埋點中，使用者可以直接針對相應的參數位置配置熱點流控規則。目前熱點規則僅支援基本類型和字元串類型，後續社群會進一步進行完善，支援更多的類型。
Sentinel Go 的熱點流量控制基于緩存淘汰機制+令牌桶機制實作。Sentinel 通過淘汰機制（如 LRU、LFU、ARC 政策等）來識别熱點參數，通過令牌桶機制來控制每個熱點參數的通路量。目前 0.4.0 版本采用 LRU 政策統計熱點參數，在後續的版本中社群會引入更多的緩存淘汰機制來适配不同的場景。
高可用流量防護最佳實踐
在服務提供方（Service Provider）的場景下，我們需要保護服務提供方不被流量洪峰打垮。我們通常根據服務提供方的服務能力進行流量控制，或針對特定的服務調用方進行限制。為了保護服務提供方不被激增的流量拖垮影響穩定性，我們可以結合前期的容量評估，通過 Sentinel 配置 QPS 模式的流控規則，當每秒的請求量超過設定的門檻值時，會自動拒絕多餘的請求。同時可以結合熱點參數流控進行細粒度的流量防護。
在服務調用端（Service Consumer）的場景下，我們需要保護服務調用方不被不穩定的依賴服務拖垮。借助 Sentinel 的信号量隔離政策（并發數流控規則），限制某個服務調用的并發量，防止大量慢調用擠占正常請求的資源；同時，借助熔斷降級規則，當異常比率或業務慢調用比例超過某個門檻值後将調用自動熔斷，直到一段時間過後再嘗試恢複。熔斷期間我們可以提供預設的處理邏輯（fallback），熔斷期間的調用都會傳回 fallback 的結果，而不會再去嘗試本已非常不穩定的服務。需要注意的是，即使服務調用方引入了熔斷降級機制，我們還是需要在 HTTP 或 RPC 用戶端配置請求逾時時間，來做一個兜底的保護。
在一些請求突刺的場景中，比如 MQ 用戶端消費消息的場景，我們可能不希望将多餘的消息直接拒絕（重投），而是讓這些過量的消息排隊逐漸處理。這就是“削峰填谷”的場景。我們可以利用 Sentinel 流控規則中的“勻速+排隊等待”控制效果來處理這種場景，以固定的間隔時間讓請求通過，超出預設量的請求排隊等待。這種方式适合用于請求以突刺狀來到，這個時候我們不希望一下子把所有的請求都通過，這樣可能會把系統壓垮；同時我們也期待系統以穩定的速度，逐漸處理這些請求，以起到“削峰填谷”的效果，而不是直接拒絕所有多餘的請求。
同時 Sentinel Go 還提供
全局次元的系統自适應保護能力，結合系統的 Load、CPU 使用率以及服務的入口 QPS、響應時間和并發量等幾個次元的監控名額，通過自适應的流控政策，讓系統的入口流量和系統的負載達到一個平衡，讓系統盡可能跑在最大吞吐量的同時保證系統整體的穩定性。系統規則可以作為整個服務的一個兜底防護政策，保障服務不挂。
Let's start hacking!
Sentinel Go 版本正在快速演進中，我們非常歡迎感興趣的開發者參與貢獻，一起來主導未來版本的演進。Sentinel Go 版本的演進離不開社群的貢獻。若您有意願參與貢獻，歡迎聯系我們加入 Sentinel 貢獻小組一起成長（Sentinel 開源讨論釘釘群：30150716）。我們會定期給活躍貢獻者寄送小禮品，核心貢獻者可以提名為 committer，一起主導社群的演進。同時，也歡迎大家通過
AHAS Sentinel 控制台來快速體驗 Sentinel 的能力。Now let's start hacking!