*作者：宿何*

## 微服務執行時穩定性的問題

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

-   演唱會搶票瞬間洪峰流量導致系統超出最大負載，load 飆高，使用者無法正常下單；
-   線上選課時同一時刻提交選課的請求過多，系統無法響應；
-   頁面服務中某一塊內容訪問很慢，一直載入不出來，導致整個頁面都卡住，無法正常操作

影響微服務可用性的因素有非常多，而這些不穩定的場景可能會導致嚴重後果。我們從微服務流量的視角來看，可以粗略分為兩類常見的執行時場景：

-   服務自身流量超過承載能力導致不可用。比如激增流量、批次任務投遞導致服務負載飆高，無法正常處理請求。
-   服務因依賴其他不可用服務，導致自身連環不可用。比如我們的服務可能依賴好幾個第三方服務，假設某個支付服務出現異常，呼叫非常慢，而呼叫端又沒有有效地進行預防與處理，則呼叫端的執行緒池會被佔滿，影響服務自身正常運轉。在分散式系統中，呼叫關係是網狀的、錯綜複雜的，某個服務出現故障可能會導致級聯反應，導致整個鏈路不可用。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bbf72fdcb2084f239d262a76eab3307e~tplv-k3u1fbpfcp-zoom-1.image "1.png")

在遇到這些微服務執行時穩定性的問題時，我們應該如何解決呢？針對這些不穩定的場景，MSE 提供全方位的流量防護能力，基於開源流量治理元件 Sentinel 的穩定性防護能力，以流量為切入點，從流量控制、併發控制、熔斷降級、熱點防護、系統自適應保護等多個維度來幫助保障服務的穩定性，覆蓋微服務框架、雲原生閘道器、Service Mesh 等幾大場景，支援 Java、Go、C++、Rust 等多種語言的異構微服務架構。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a707f8ce53ac418a83681feef155a11f~tplv-k3u1fbpfcp-zoom-1.image "2.png")

## CloudWeGo 原生支援 Sentinel 及 OpenSergo

CloudWeGo 是一套由位元組跳動開源的、可快速構建企業級雲原生微服務架構的中介軟體集合。CloudWeGo 專案共同的特點是高效能、高擴充套件性、高可靠，專注於微服務通訊與治理。其中 Kitex 是下一代高效能、強可擴充套件的 Golang RPC 框架，提供整套微服務的能力；Hertz 是高易用性、高效能、高擴充套件性的 Golang 微服務 HTTP 框架，旨在為開發人員簡化構建微服務。

近期 CloudWeGo 社群與 Sentinel 社群合作共建，提供了 CloudWeGo Kitex 及 Hertz 對接 Sentinel Go 的適配模組，只需簡單地引入適配模組並引入對應 Middleware，即可快速將 Kitex 及 Hertz 服務接入 Sentinel Go，享受全面的流量治理與防護能力。同時結合 Sentinel Go 與 OpenSergo 微服務治理標準的對接，CloudWeGo 也將支援 OpenSergo spec 中流控降級與容錯的標準配置，未來可以透過統一的 CRD 方式進行流量治理管控。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e7a4b46565f342ce8a2e6b2b0137c379~tplv-k3u1fbpfcp-zoom-1.image "3.png")

適配模組文件可以參考：

-   Kitex adapter:

<https:>

-   Hertz adapter:

<https:>

同時，基於 Sentinel 的 Kitex 和 Hertz 適配模組，我們可以結合 MSE 服務治理 Go SDK 接入方式，來方便地將 Kitex 和 Hertz 服務接入到阿里雲 MSE 微服務治理產品中，透過白屏化的觀測與治理配置手段來保障微服務的執行時流量穩定性。

## CloudWeGo + MSE 流量防護最佳實踐

MSE 微服務治理提供全方位的流量治理、流量防護及微服務視角的資料庫治理能力，其中對於 Go 微服務，開發者可以透過 Go SDK 方式接入 MSE 來享受流控降級與容錯相關的治理、白屏化配置與觀測能力，保障服務執行時的穩定性。MSE 流量治理支援 CloudWeGo, gRPC, Gin, dubbo-go, go-micro 等常用 Go 微服務框架的流控降級與容錯能力。首先我們先來看一下流量防護的典型場景。

### 流量控制保障激增流量下服務的穩定性

流量是非常隨機性的、不可預測的。前一秒可能還風平浪靜，後一秒可能就出現流量洪峰了（例如雙十一零點的場景）。然而我們系統的容量總是有限的，如果突然而來的流量超過了系統的承受能力，就可能會導致請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最後導致系統崩潰。因此，我們需要針對這種突發的流量來進行限制，在儘可能處理請求的同時來保障服務不被打垮，這就是流量控制。流量控制的場景是非常通用的，像脈衝流量類的場景都是適用的。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7ef8246c05c446d89f3aa0bcf71c3e1e~tplv-k3u1fbpfcp-zoom-1.image "4.png")

MSE Sentinel 基於毫秒級滑動視窗精確統計與令牌桶、 漏桶、WarmUp 等流量控制演算法，提供包括秒級精準流控、叢集總量流控、勻速排隊等在內的多種維度的流量控制場景。通常在 Web 入口或 RPC 服務提供方（Service Provider）的場景下，我們需要保護服務提供方自身不被流量洪峰打垮。這時候通常根據服務提供方的服務能力進行流量控制，或針對特定的服務呼叫方進行限制。我們可以結合前期壓測評估核心介面的承受能力，配置 QPS 模式的流控規則，當每秒的請求量超過設定的閾值時，會自動拒絕多餘的請求。

### 熔斷降級與隔離保障服務不被慢依賴呼叫拖垮

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

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

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

-   併發控制（隔離規則）：作為一種輕量級隔離的手段，控制某些呼叫的併發數（即正在進行的數目），防止過多的慢呼叫佔滿執行緒池造成整體不可用。併發控制規則可作為一種重要的保底手段，防止服務被大量慢呼叫拖垮。

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

-   提前降級：對於一些弱依賴的服務（非關鍵鏈路依賴），可以在活動前或資源緊張時進行動態降級，以優先保障重要服務的穩定性。被降級的服務將直接返回給定的 mock 值而不會觸發實際呼叫。

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

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

### CloudWeGo 接入 MSE 流量防護示例

接下來我們就以 CloudWeGo Kitex 服務為例，展示如何結合 MSE Sentinel 來保障 CloudWeGo 微服務的執行時穩定性。

首先，我們先在專案中引入 MSE Go SDK，並進行一些簡單初始化配置；同時我們也引入 Kitex Sentinel 適配模組，以便將我們的 Kitex 服務接入到 MSE：

```
import (
  sentinel "github.com/alibaba/sentinel-golang/api"
  sentinelPlugin "github.com/alibaba/sentinel-golang/pkg/adapters/kitex"
  api "github.com/cloudwego/kitex-examples/hello/kitex_gen/api/hello"
  mse "github.com/aliyun/aliyun-mse-go-sdk"
)

func main() {
  // 初始化 MSE Sentinel；可以透過環境變數或 sentinel.yml 檔案配置應用名
  err := mse.InitMseDefault()
  if err != nil {
    log.Fatalf("Failed to init MSE: %+v", err)
  }

// 建立 Kitex server 時新增 Sentinel 適配模組中的 middleware
  svr := api.NewServer(new(HelloImpl), server.WithMiddleware(sentinelPlugin.SentinelServerMiddleware()))

err = svr.Run()
  if err != nil {
    log.Println(err.Error())
  }
}
```

接下來我們啟動服務 provider，即可在 MSE 控制檯看到我們的 Kitex 服務。我們透過 consumer 觸發流量訪問，然後可以在 MSE 控制檯的介面詳情頁面看到我們 Kitex 服務呼叫的詳細監控資訊。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6d236461daa74ce9a5ed3fa4ce6b031d~tplv-k3u1fbpfcp-zoom-1.image "5.png")

接下來我們針對 Hello:Echo 這個介面方法配置一條單機 QPS 為 10 的流控規則：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1ee69287ef764fd3b6fa71eee793557d~tplv-k3u1fbpfcp-zoom-1.image "6.png")

配置完成後，規則會實時生效到服務中。稍等片刻我們就可以在介面詳情頁面看到 Hello:Echo 這個介面方法的單機處理量被限制到了 10 次每秒，同時 consumer 端也會接收到相應的流控 error。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a576324356da4997859f53c38392c9db~tplv-k3u1fbpfcp-zoom-1.image "7.png")

結合 OpenSergo 實現標準化的流量治理

## 結合 OpenSergo 實現標準化的流量治理

業界微服務治理存在概念不統一、配置形式不統一、能力不統一、多框架統一管控較為複雜等問題。比如我們希望給某個介面配置熔斷降級規則，在 Sentinel 中可能需要透過 Sentinel 動態規則的方式進行配置，在 Istio 中可能又是另一套配置方式，在其它元件上可能又是不同的配置。不同框架治理配置方式的不一致使得微服務統一治理管控的複雜度相當高。

基於以上背景，由阿里巴巴、bilibili、CloudWeGo 等企業與社群共同發起的 OpenSergo 專案應運而生。OpenSergo 旨在提供一套開放通用的、面向雲原生服務、覆蓋微服務及上下游關聯元件的微服務治理標準，並根據標準提供一系列的 API 與 SDK 實現。OpenSergo 的最大特點就是以統一的一套配置/DSL/協議定義服務治理規則，面向多語言異構化架構，覆蓋微服務框架及上下游關聯元件。無論微服務的語言是 Java, Go, Node.js 還是其它語言，無論是標準微服務還是 Mesh 接入，從閘道器到微服務框架，從資料庫到快取訪問，從服務註冊發現到配置，開發者都可以透過同一套 OpenSergo CRD 標準配置進行統一的治理管控，而無需關注各框架、語言的差異點，降低異構化、全鏈路微服務治理管控的複雜度。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc88912576c64d82816a904f0cb1b4c7~tplv-k3u1fbpfcp-zoom-1.image "8.png")

在 OpenSergo 中，我們結合 Sentinel 及 MSE 的場景實踐對流控降級與容錯抽出標準 CRD。一個容錯治理規則 (FaultToleranceRule) 由以下三部分組成：

-   Target: 針對什麼樣的請求
-   Strategy: 容錯或控制策略，如流控、熔斷、併發控制、自適應過載保護、離群例項摘除等
-   FallbackAction: 觸發後的 fallback 行為，如返回某個錯誤或狀態碼

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82156251d36f4a0d8408ab8cb289b5b9~tplv-k3u1fbpfcp-zoom-1.image "9.png")

以下 YAML CR 示例定義的規則針對 Hello:Echo 這個服務方法（用資源名標識）配置了一條流控策略，全域性不超過 10 QPS：

```
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: RateLimitStrategy
metadata:
  name: rate-limit-foo
spec:
  metricType: RequestAmount
  limitMode: Global
  threshold: 10
  statDuration: "1s"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-fault-tolerance-rule
spec:
  selector:
    app: foo-app # 規則配置生效的服務名
  targets:
    - targetResourceName: 'Hello:Echo'
  strategies: 
    - name: rate-limit-foo
  # 這裡還可以單獨定義 fallbackAction，比如自定義返回值或錯誤；不指定則為預設行為
```

Sentinel 2.0 將原生支援 OpenSergo 流量治理相關 CRD 配置及能力，結合 Sentinel 提供的各框架的適配模組，讓 Dubbo, Spring Cloud Alibaba, gRPC, CloudWeGo 等20+框架能夠無縫接入到 OpenSergo 生態中，用統一的 CRD 來配置流量路由、流控降級、服務容錯等治理規則。無論是 Java 還是 Go 還是 Mesh 服務，無論是 HTTP 請求還是 RPC 呼叫，還是資料庫 SQL 訪問，我們都可以用這統一的容錯治理規則 CRD 來給微服務架構中的每一環配置治理，來保障我們服務鏈路的穩定性。MSE 作為 OpenSergo 微服務治理標準的企業級產品，也將原生支援 OpenSergo spec。

## 總結與展望

流控降級與容錯是微服務流量治理中的重要的一環，同時 MSE 還提供更廣範圍、更多場景的微服務治理能力，包括全鏈路灰度、無損上下線、微服務資料庫治理、日誌治理等一系列的微服務治理能力。服務治理是微服務改造深入到一定階段之後的必經之路，是將微服務做穩做好的關鍵。同時我們也在與 CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo、ShardingSphere 等社群共同建設 OpenSergo 微服務治理標準，將企業與社群中微服務治理的場景與最佳實踐共同提取成標準規範，也歡迎更多社群與企業一起參與 OpenSergo 微服務治理標準的共建。歡迎大家加入 OpenSergo 社群交流群（釘釘群）進行討論：34826335

***參考連結：***

*MSE 微服務治理：*

*<https:>*

*Sentinel Go:*

*<https:>*

*OpenSergo:*

*<https:>*

*CloudWeGo:*

*<https:>*</https:></https:></https:></https:></https:></https:>

OpenSergo & CloudWeGo 共同保障微服務執行時流量穩定性

相關文章