1. 前言
無論是令牌桶, 漏桶
還是 自適應限流的方法，總的來說都是服務端的單機限流方式。雖然服務端限流雖然可以幫助我們抗住一定的壓力，但是拒絕請求畢竟還是有成本的。如果我們的本來流量可以支撐 1w rps，加了限流可以支撐在 10w rps 的情況下仍然可以提供 1w rps 的有效請求，但是流量突然再翻了 10 倍，來到 100w rps 那么服務該掛還是得掛。
所以我們的可用性建設不僅僅是服務端做建設就可以萬事大吉了，得在整個鏈路上的每個組件都做好自己的事情才行，今天我們就來一起看一下客戶端上的限流措施：熔斷。
2.熔斷器
如上圖所示，熔斷器存在三個狀態:
- 關閉(closed): 關閉狀態下沒有觸發斷路保護，所有的請求都正常通行
- 打開(open): 當錯誤閾值觸發之后，就進入開啟狀態，這個時候所有的流量都會被節流，不運行通行
- 半打開(half-open): 處於打開狀態一段時間之后，會嘗試嘗試放行一個流量來探測當前 server 端是否可以接收新流量，如果這個沒有問題就會進入關閉狀態，如果有問題又會回到打開狀態
2.1 hystrix-go
熔斷器中比較典型的實現就是 hystrix，Golang 也有對應的版本，我們先來看一下 hystrix-go 是怎么實現的
2.2 案例
先看一個使用案例，首先我們使用 gin 啟動一個服務端，這個服務端主要是前 200ms 的請求都會返回 500，之后的請求都會返回 200
func server() {
e := gin.Default()
start := time.Now.Unix()
e.GET("/ping", func(ctx *gin.Context) {
if time.Since(start) < 201*time.Millisecond {
ctx.String(http.StatusInternalServerError, "pong")
return
}
ctx.String(http.StatusOK, "pong")
})
e.Run(":8080")
}
然后配置 hystrix，hystrix.ConfigureCommand(command name, config)hystrix 的配置是按照每個 command 進行配置，使用的時候我們也需要傳遞一個 command，下面的配置就是我們的請求數量大於等於 10 個並且錯誤率大於等於 20% 的時候就會觸發熔斷器開關，熔斷器打開 500ms 之后會進入半打開的狀態，嘗試放一部分請求去訪問
func main(){
hystrix.ConfigureCommand("test", hystrix.CommandConfig{
// 執行 command 的超時時間
Timeout: 10,
// 最大並發量
MaxConcurrentRequests: 100,
// 一個統計窗口 10 秒內請求數量
// 達到這個請求數量后才去判斷是否要開啟熔斷
RequestVolumeThreshold: 10,
// 熔斷器被打開后
// SleepWindow 的時間就是控制過多久后去嘗試服務是否可用了
// 單位為毫秒
SleepWindow: 500,
// 錯誤百分比
// 請求數量大於等於 RequestVolumeThreshold 並且錯誤率到達這個百分比后就會啟動熔斷
ErrorPercentThreshold: 20,
})
}
然后我們使用一個循環當做客戶端代碼，會請求 20 次，每一個請求消耗 100ms
func main() {
go server()
// 這里是 config 代碼
for i := 0; i < 20; i++ {
_ = hystrix.Do("test", func() error {
resp, _ := resty.New().R().Get("http://localhost:8080/ping")
if resp.IsError() {
return fmt.Errorf("err code: %s", resp.Status())
}
return nil
}, func(err error) error {
fmt.Println("fallback err: ", err)
return err
})
// 每次請求間隔100ms
time.Sleep(100 * time.Millisecond)
}
}
完整代碼如下：
package main
import (
"fmt"
"net/http"
"time"
"github.com/afex/hystrix-go/hystrix"
"github.com/gin-gonic/gin"
"gopkg.in/resty.v1"
)
func server() {
e := gin.Default()
start := time.Now()
e.GET("/ping", func(ctx *gin.Context) {
if time.Since(start) < 201*time.Millisecond {
ctx.String(http.StatusInternalServerError, "pong")
return
}
ctx.String(http.StatusOK, "pong")
})
err := e.Run(":8080")
if err != nil {
fmt.Printf("START SERVER OCCUR ERROR, %s", err.Error())
}
}
func main() {
go server()
hystrix.ConfigureCommand("test", hystrix.CommandConfig{
// 執行 command 的超時時間
Timeout: 10,
// 最大並發量
MaxConcurrentRequests: 100,
// 一個統計窗口 10 秒內請求數量
// 達到這個請求數量后才去判斷是否要開啟熔斷
RequestVolumeThreshold: 10,
// 熔斷器被打開后
// SleepWindow 的時間就是控制過多久后去嘗試服務是否可用了
// 單位為毫秒
SleepWindow: 500,
// 錯誤百分比
// 請求數量大於等於 RequestVolumeThreshold 並且錯誤率到達這個百分比后就會啟動熔斷
ErrorPercentThreshold: 20,
})
// 模擬20個客戶端請求
for i := 0; i < 20; i++ {
_ = hystrix.Do("test", func() error {
resp, _ := resty.New().R().Get("http://localhost:8080/ping")
if resp.IsError() {
return fmt.Errorf("err code: %s", resp.Status())
}
return nil
}, func(err error) error {
fmt.Println("fallback err: ", err)
return err
})
time.Sleep(100 * time.Millisecond)
}
}
執行的結果如下，前面 2 個請求報 500，等到發起了 10 個請求之后就會進入熔斷， 500ms 也就是發出 5 個請求之后就會重新去請求服務端
2.3 hystrix-go 核心實現
核心實現的方法是 AllowRequest，IsOpen判斷當前是否處於熔斷狀態，allowSingleTest就是去看是否過了一段時間需要重新進行嘗試
func (circuit *CircuitBreaker) AllowRequest() bool {
// 判斷是否打開或者過了一段時間需要重新進行嘗試
return !circuit.IsOpen() || circuit.allowSingleTest()
}
IsOpen先看當前是否已經打開了，如果已經打開了就直接返回就行了，如果還沒打開就去判斷
- 請求數量是否滿足要求
- 請求的錯誤率是否過高，如果兩個都滿足就會打開熔斷器
func (circuit *CircuitBreaker) IsOpen() bool {
circuit.mutex.RLock()
// 查看打開狀態
o := circuit.forceOpen || circuit.open
circuit.mutex.RUnlock()
if o {
return true
}
// 獲取定期時間內請求的數量是否小於 設定的請求斷融數量，如果小於則不開啟斷融
if uint64(circuit.metrics.Requests().Sum(time.Now())) < getSettings(circuit.Name).RequestVolumeThreshold {
return false
}
// 開啟斷融前判斷服務是否健康
if !circuit.metrics.IsHealthy(time.Now()) {
// too many failures, open the circuit
circuit.setOpen()
return true
}
return false
}
hystrix-go已經可以比較好的滿足我們的需求，但是存在一個問題就是一旦觸發了熔斷，在一段時間之類就會被一刀切的攔截請求，所以我們來看看 google sre 的一個實現
2.4 GoogleSre 過載保護算法
$$
max(0, \frac{requests - K * accepts}{requests + 1})
$$
算法如上所示，這個公式計算的是請求被丟棄的概率
- requests: 一段時間的請求數量
- accepts: 成功的請求數量
- K：倍率，K越小表示越激進， 越小表示越容易被丟棄請求
這個算法的好處是不會直接一刀切的丟棄所有請求，而是計算出一個概率來進行判斷，當成功的請求數量越少，K越小的時候 $requests - K * accepts$ 的值就越大，計算出的概率也就越大，表示這個請求被丟棄的概率越大
2.5 Kratos 實現分析
- 核心代碼
func (b *sreBreaker) Allow() error { // 統計成功的請求，和總的請求 success, total := b.summary() // 計算當前的成功率 k := b.k * float64(success) if log.V(5) { log.Info("breaker: request: %d, succee: %d, fail: %d", total, success, total-success) } // 統計請求量和成功率 // 如果 rps 比較小，不觸發熔斷 // 如果成功率比較高，不觸發熔斷，如果 k = 2，那么就是成功率 >= 50% 的時候就不熔斷 if total < b.request || float64(total) < k { if atomic.LoadInt32(&b.state) == StateOpen { atomic.CompareAndSwapInt32(&b.state, StateOpen, StateClosed) } return nil } if atomic.LoadInt32(&b.state) == StateClosed { atomic.CompareAndSwapInt32(&b.state, StateClosed, StateOpen) } // 計算一個概率，當 dr 值越大，那么被丟棄的概率也就越大 // dr 值是，如果失敗率越高或者是 k 值越小，那么它越大 dr := math.Max(0, (float64(total)-k)/float64(total+1)) drop := b.trueOnProba(dr) if log.V(5) { log.Info("breaker: drop ratio: %f, drop: %t", dr, drop) } if drop { return ecode.ServiceUnavailable } return nil } // 通過隨機來判斷是否需要進行熔斷 func (b *sreBreaker) trueOnProba(proba float64) (truth bool) { b.randLock.Lock() truth = b.r.Float64() < proba b.randLock.Unlock() return }
3. 總結
可用性僅靠服務端來保證是不靠譜的，只有整條鏈路上的所有服務都做好了自己可用性相關的建設我們的服務 SLA 最后才能夠有保證。
最常見的hystrix-go 和 kratos 兩種熔斷方式，kratos采用 Google SRE 的實現的好處就是沒有半開的狀態，也沒有完全開啟的狀態，而是通過一個概率來進行判斷我們的流量是否應該通過，這樣沒有那么死板，也可以保證我們錯誤率比較高的時候不會大量請求服務端，給服務端喘息恢復的時間。