![1.png](https://ucc.alicdn.com/pic/developer-ecology/57490d6dc82f4af1bae15ad5a1901a16.png)

作者 | 趙奕豪

# 背景
 
微服務的穩定性一直是開發者非常關注的話題。隨著業務從單體架構向分散式架構演進以及部署方式的變化，服務之間的依賴關係變得越來越複雜，業務系統也面臨著巨大的高可用挑戰。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/5404f38febfa4cc49b291f8f5898067f.png)

在生產環境中大家可能遇到過以下不穩定的情況：

- 大促時瞬間洪峰流量導致系統超出最大負載，load 飆高，系統崩潰導致使用者無法下單；

- “黑馬”熱點商品擊穿快取，DB 被打垮，擠佔正常流量；

- 呼叫端被不穩定第三方服務拖垮，執行緒池被佔滿，呼叫堆積，導致整個呼叫鏈路卡死。

這些不穩定的場景可能會導致嚴重後果，但很多時候我們又容易忽視這些與流量/依賴相關的高可用防護。大家可能想問：如何預防這些不穩定因素帶來的影響？如何針對流量進行高可用的防護？如何保障服務“穩如磐石”？這時候我們就要請出服務高可用保障的利器 —— Sentinel。

# Sentinel 介紹

Sentinel 是阿里巴巴開源的，面向分散式服務架構的流量控制元件，主要以流量為切入點，從限流、流量整形、熔斷降級、系統自適應保護等多個維度來幫助開發者保障微服務的穩定性。Sentinel 承接了阿里巴巴近 10 年的雙十一大促流量的核心場景，例如秒殺、冷啟動、訊息削峰填谷、叢集流量控制、實時熔斷下游不可用服務等，是保障微服務高可用的利器，原生支援 Java/Go/C++ 等多種語言，並且提供 Istio/Envoy 全域性流控支援來為 Service Mesh 提供高可用防護的能力。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/9a73c1f73ae248839167b55143bcd324.png)

在今年年初，社群宣佈了 Sentinel Go 版本的釋出，為 Go 語言的微服務提供流控降級、系統自適應保護等特性的原生支援，標誌著 Sentinel 朝著多元化與雲原生邁出了重要的一步。在這半年的時間內，社群推出了近 10 個版本，逐步對齊了限流、熔斷降級、系統自適應流控、熱點防護等核心能力；同時社群也在不斷擴充開源生態，目前已提供 go-micro、gRPC、Dubbo、Gin 等框架的適配模組，使用這些框架的開發者可以非常簡單快速地接入 Sentinel。

Sentinel 裡面有兩個核心的抽象概念：資源和規則：

- **資源 (resource) **是 Sentinel 的關鍵概念，它代表某個邏輯塊、函式或介面的呼叫。它可以是某個 Web API，或者是某個 RPC 服務，甚至是任意的程式碼塊。使用 Sentinel 的 API 將業務邏輯封裝起來（或引入 Sentinel 提供的外掛），這一步稱為“埋點”。每個埋點都有一個資源名稱，代表觸發了這個資源的呼叫或訪問；

- **規則 (rule) **即定義到達怎樣的條件後進行怎樣的控制，針對某個資源或某些資源生效。所有規則都可以動態實時調整，社群提供了 etcd、Consul、Nacos 等動態資料來源適配，可以方便地透過這些配置元件來管理規則。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/341575bffe764753ba233177bbaa5d92.png)

Sentinel 底層透過高效能的滑動視窗進行秒級呼叫指標統計，結合 token bucket, leaky bucket 和自適應流控演算法來透出核心的高可用防護能力。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/9e0b46bd7970400ca6cff93bfd7416ac.png)

那麼我們如何利用 Sentinel Go 來保證我們微服務的穩定性？下面我們來看幾個典型的場景。

# 高可用防護的核心場景

## 1. 流量控制

流量是非常隨機性的、不可預測的。前一秒可能還風平浪靜，後一秒可能就出現流量洪峰了（例如雙十一零點的場景）。然而我們系統的容量總是有限的，如果突然而來的流量超過了系統的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最後導致系統崩潰。

因此，我們需要針對這種突發的流量來進行限制，在儘可能處理請求的同時來保障服務不被打垮，這就是流量控制。流量控制的場景是非常通用的，像脈衝流量類的場景都是適用的。

通常在 Web 入口或服務提供方（Service Provider）的場景下，我們需要保護服務提供方自身不被流量洪峰打垮。這時候通常根據服務提供方的服務能力進行流量控制，或針對特定的服務呼叫方進行限制。我們可以結合前期壓測評估核心介面的承受能力，配置 QPS 模式的流控規則，當每秒的請求量超過設定的閾值時，會自動拒絕多餘的請求。

下面是最簡單的一個 Sentinel 限流規則的配置示例：

```
_, err = flow.LoadRules([]*flow.FlowRule{
    {
        Resource:          "some-service", // 埋點資源名
        MetricType:        flow.QPS, // QPS 模式
        Count:             10, // QPS 閾值為 10，即該請求單機每秒不超過 10 次
        ControlBehavior:   flow.Reject, // 控制效果為直接拒絕，不排隊
    },
})
```

## 2. Warm-Up 預熱流控

近期釋出的 Sentinel Go 0.6.0 版本帶來了一種新的流控場景：Warm-Up 預熱流控。當系統長期處於低水位的情況下，流量突然增加時，直接把系統拉昇到高水位可能瞬間把系統壓垮。比如剛啟動的服務，資料庫連線池可能還未初始化，快取也處於空的狀態，這時候激增的流量非常容易導致服務崩潰。如果採用傳統的限流模式，不加以平滑/削峰限制，其實也是有被打掛的風險的（比如一瞬間併發很高）。

針對這種場景，我們就可以利用 Sentinel 的 Warm-Up 流控模式，控制透過的流量緩慢增加，在一定時間內逐漸增加到閾值上限，而不是在一瞬間全部放行，同時結合請求間隔控制+排隊的控制效果 來防止大量請求都在同一時刻被處理。這樣可以給冷系統一個預熱的時間，避免冷系統被壓垮。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/fd3df75aac4b4867a606545e842528fc.png)

## 3. 併發控制與熔斷降級

一個服務常常會呼叫別的模組，可能是另外的一個遠端服務、資料庫，或者第三方 API 等。例如，支付的時候，可能需要遠端呼叫銀聯提供的 API；查詢某個商品的價格，可能需要進行資料庫查詢。然而，這個被依賴服務的穩定性是不能保證的。如果依賴的服務出現了不穩定的情況，請求的響應時間變長，那麼呼叫服務的方法的響應時間也會變長，執行緒會產生堆積，最終可能耗盡業務自身的執行緒池，服務本身也變得不可用。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/4c4fef9deb1543cb8c9dcbfa20b55996.png)

現代微服務架構都是分散式的，由非常多的服務組成。不同服務之間相互呼叫，組成複雜的呼叫鏈路。以上的問題在鏈路呼叫中會產生放大的效果。複雜鏈路上的某一環不穩定，就可能會層層級聯，最終導致整個鏈路都不可用。

Sentinel Go 提供以下的能力避免慢呼叫等不穩定因素造成不可用:

- **併發控制**：作為一種輕量級隔離的手段，控制某些呼叫的併發數（即正在進行的數目），防止過多的慢呼叫擠佔正常的呼叫；

- **熔斷降級**：對不穩定的弱依賴呼叫進行自動熔斷降級，暫時切斷不穩定呼叫，避免區域性不穩定因素導致整體的雪崩。

Sentinel Go 熔斷降級特性基於熔斷器模式的思想，在服務出現不穩定因素（如響應時間變長，錯誤率上升）的時候暫時切斷服務的呼叫，等待一段時間再進行嘗試。一方面防止給不穩定服務“雪上加霜”，另一方面保護服務的呼叫方不被拖垮。Sentinel 支援兩種熔斷策略：基於響應時間（慢呼叫比例）和基於錯誤（錯誤比例/錯誤數），可以有效地針對各種不穩定的場景進行防護。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/9a7ef17fc1bb49b393ca03eb3b746378.png)

注意熔斷器模式一般適用於弱依賴呼叫，即降級後不影響業務主流程，開發者需要設計好降級後的 fallback 邏輯和返回值。另外需要注意的是，即使服務呼叫方引入了熔斷降級機制，我們還是需要在 HTTP 或 RPC 客戶端配置請求超時時間，來做一個兜底的防護。

## 4. 熱點防護

流量是隨機的，不可預測的。為了防止被大流量打垮，我們通常會對核心介面配置限流規則，但有的場景下配置普通的流控規則是不夠的。

我們來看這樣一種場景——大促峰值的時候，總是會有不少“熱點”商品，這些熱點商品的瞬時訪問量非常高。一般情況下，我們可以事先預測一波熱點商品，並對這些商品資訊進行快取“預熱”，以便在出現大量訪問時可以快速返回而不會都打到 DB 上。但每次大促都會湧現出一些“黑馬”商品，這些“黑馬”商品是我們無法事先預測的，沒有被預熱。

當這些“黑馬”商品訪問量激增時，大量的請求會擊穿快取，直接打到 DB 層，導致 DB 訪問緩慢，擠佔正常商品請求的資源池，最後可能會導致系統掛掉。這時候，利用 Sentinel 的熱點引數流量控制能力，自動識別熱點引數並控制每個熱點值的訪問 QPS 或併發量，可以有效地防止過“熱”的引數訪問擠佔正常的呼叫資源。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/f7ad7b5e15ee4731bfef2108b01c7c02.png)

再比如有的場景下我們希望限制每個使用者呼叫某個 API 的頻率，將 API 名稱+userId 作為埋點資源名顯然是不合適的。這時候我們可以在給 API 埋點的時候透過 WithArgs(xxx) 將 userId 作為引數傳入到 API 埋點中，然後配置熱點規則即可針對每個使用者分別限制呼叫頻率；同時，Sentinel 也支援針對某些具體值單獨配置限流值，進行精細化流控。像其他規則一樣，熱點流控規則同樣支援透過動態資料來源進行動態配置。

Sentinel Go 提供的 RPC 框架整合模組（如 Dubbo、gRPC）均會自動將 RPC 呼叫的引數列表附帶在埋點中，使用者可以直接針對相應的引數位置配置熱點流控規則。注意如果需要配置具體值限流，受型別系統限制，目前僅支援基本型別和 string 型別。

Sentinel Go 的熱點流量控制基於快取淘汰機制+令牌桶機制實現。Sentinel 透過淘汰機制（如 LRU、LFU、ARC 策略等）來識別熱點引數，透過令牌桶機制來控制每個熱點引數的訪問量。目前的 Sentinel Go 版本採用 LRU 策略統計熱點引數，在後續的版本中社群會引入更多的快取淘汰機制來適配不同的場景。

## 5. 系統自適應保護

有了以上的流量防護場景，是不是就萬事無憂了呢？其實不是的，很多時候我們無法事先就準確評估某個介面的準確容量，甚至無法預知核心介面的流量特徵（如是否有脈衝情況），這時候靠事先配置的規則可能無法有效地保護當前服務節點；一些情況下我們可能突然發現機器的 Load 和 CPU usage 等開始飈高，但卻沒有辦法很快的確認到是什麼原因造成的，也來不及處理異常。

這個時候我們其實需要做的是快速止損，先透過一些**自動化的兜底防護手段**，將瀕臨崩潰的微服務“拉”回來。針對這些情況，Sentinel Go 提供了一種獨有的系統自適應保護規則，結合系統指標和服務容量，自適應動態調整流量。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e76a0d28bc7640d492a22201140ede0d.png)

Sentinel 系統自適應保護策略借鑑了 TCP BBR 演算法的思想，結合系統的 Load、CPU 使用率以及服務的入口 QPS、響應時間和併發量等幾個維度的監控指標，透過自適應的流控策略，讓系統的入口流量和系統的負載達到一個平衡，讓系統儘可能跑在最大吞吐量的同時保證系統整體的穩定性。系統規則可以作為整個服務的一個兜底防護策略，保障服務不掛，對 CPU 密集型的場景會有比較好的效果。同時，社群也在結合自動化控制理論和強化學習等手段，來更好地完善自適應流控的效果和適用場景。

# Let's start hacking!

瞭解了以上的高可用防護的場景，相信大家對微服務容錯與穩定性保障的手段有了新的體會。大家可以動手玩起來，接入 Sentinel Go 來體驗這些能力，讓微服務“穩如磐石”。

同時 Sentinel 的演進也離不開社群的貢獻。Sentinel Go 1.0 GA 版本即將在近期釋出，帶來更多雲原生相關的特性。我們非常歡迎感興趣的開發者參與貢獻，一起來主導未來版本的演進。我們鼓勵任何形式的貢獻，包括但不限於：

- bug fix
- new features/improvements
- dashboard
- document/website
- test cases

開發者可以在 GitHub 上面的 good first issue 列表上挑選感興趣的 issue 來參與討論和貢獻。我們會重點關注積極參與貢獻的開發者，核心貢獻者會提名為 Committer，一起主導社群的發展。我們也歡迎大家有任何問題和建議，都可以透過 GitHub issue、Gitter 或釘釘群（群號：30150716）等渠道進行交流。Now start hacking!

- **Sentinel Go repo:** [https://github.com/alibaba/sentinel-golang](https://github.com/alibaba/sentinel-golang)

- **企業使用者歡迎進行登記**：[https://github.com/alibaba/Sentinel/issues/18](https://github.com/alibaba/Sentinel/issues/18)

- **Sentinel 阿里雲企業版**：[https://ahas.console.aliyun.com/](https://ahas.console.aliyun.com/)

### 作者簡介

**趙奕豪（GitHub: sczyh30）**，阿里 Sentinel 開源專案負責人，高可用技術佈道師。

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/DBm-nTOlBP6kWzfv1suLFg)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

還在擔心服務掛掉？Sentinel Go 讓服務穩如磐石

相關文章