詳解Go可用性(六) 熔斷
在前面的幾篇文章當(dāng)中，無(wú)論是令牌桶、漏桶還是自適應(yīng)限流的方法，總的來(lái)說(shuō)都是服務(wù)端的單機(jī)限流方式。雖然服務(wù)端限流雖然可以幫助我們抗住一定的壓力，但是拒絕請(qǐng)求畢竟還是有成本的。如果我們的本來(lái)流量可以支撐 1w rps，加了限流可以支撐在 10w rps 的情況下仍然可以提供 1w rps 的有效請(qǐng)求，但是流量突然再翻了 10 倍，來(lái)到 100w rps 那么服務(wù)該掛還是得掛。
所以我們的可用性建設(shè)不僅僅是服務(wù)端做建設(shè)就可以萬(wàn)事大吉了，得在整個(gè)鏈路上的每個(gè)組件都做好自己的事情才行，今天我們就來(lái)一起看一下客戶端上的限流措施：熔斷。
熔斷器
熔斷器[^2]
如上圖[^2]所示，熔斷器存在三個(gè)狀態(tài):
關(guān)閉(closed): 關(guān)閉狀態(tài)下沒(méi)有觸發(fā)斷路保護(hù)，所有的請(qǐng)求都正常通行
打開(kāi)(open): 當(dāng)錯(cuò)誤閾值觸發(fā)之后，就進(jìn)入開(kāi)啟狀態(tài)，這個(gè)時(shí)候所有的流量都會(huì)被節(jié)流，不運(yùn)行通行
半打開(kāi)(half-open): 處于打開(kāi)狀態(tài)一段時(shí)間之后，會(huì)嘗試嘗試放行一個(gè)流量來(lái)探測(cè)當(dāng)前 server 端是否可以接收新流量，如果這個(gè)沒(méi)有問(wèn)題就會(huì)進(jìn)入關(guān)閉狀態(tài)，如果有問(wèn)題又會(huì)回到打開(kāi)狀態(tài)
hystrix-go
熔斷器中比較典型的實(shí)現(xiàn)就是 hystrix，Golang 也有對(duì)應(yīng)的版本，我們先來(lái)看一下 hystrix-go 是怎么實(shí)現(xiàn)的
案例
先看一個(gè)使用案例，首先我們使用 gin 啟動(dòng)一個(gè)服務(wù)端，這個(gè)服務(wù)端主要是前 200ms 的請(qǐng)求都會(huì)返回 500，之后的請(qǐng)求都會(huì)返回 200
- func server() {
- e := gin.Default()
- 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 的配置是按照每個(gè) command 進(jìn)行配置，使用的時(shí)候我們也需要傳遞一個(gè) command，下面的配置就是我們的請(qǐng)求數(shù)量大于等于 10 個(gè)并且錯(cuò)誤率大于等于 20% 的時(shí)候就會(huì)觸發(fā)熔斷器開(kāi)關(guān)，熔斷器打開(kāi) 500ms 之后會(huì)進(jìn)入半打開(kāi)的狀態(tài)，嘗試放一部分請(qǐng)求去訪問(wèn)
- func main(){
- hystrix.ConfigureCommand("test", hystrix.CommandConfig{
- // 執(zhí)行 command 的超時(shí)時(shí)間
- Timeout: 10,
- // 最大并發(fā)量
- MaxConcurrentRequests: 100,
- // 一個(gè)統(tǒng)計(jì)窗口 10 秒內(nèi)請(qǐng)求數(shù)量
- // 達(dá)到這個(gè)請(qǐng)求數(shù)量后才去判斷是否要開(kāi)啟熔斷
- RequestVolumeThreshold: 10,
- // 熔斷器被打開(kāi)后
- // SleepWindow 的時(shí)間就是控制過(guò)多久后去嘗試服務(wù)是否可用了
- // 單位為毫秒
- SleepWindow: 500,
- // 錯(cuò)誤百分比
- // 請(qǐng)求數(shù)量大于等于 RequestVolumeThreshold 并且錯(cuò)誤率到達(dá)這個(gè)百分比后就會(huì)啟動(dòng)熔斷
- ErrorPercentThreshold: 20,
- })
- }
然后我們使用一個(gè)循環(huán)當(dāng)做客戶端代碼，會(huì)請(qǐng)求 20 次，每一個(gè)請(qǐng)求消耗 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
- })
- time.Sleep(100 * time.Millisecond)
- }
- }
所以我們執(zhí)行的結(jié)果就是，前面 2 個(gè)請(qǐng)求報(bào) 500，等到發(fā)起了 10 個(gè)請(qǐng)求之后就會(huì)進(jìn)入熔斷， 500ms 也就是發(fā)出 5 個(gè)請(qǐng)求之后就會(huì)重新去請(qǐng)求服務(wù)端
image-20210504164650024
hystrix-go 核心實(shí)現(xiàn)
核心實(shí)現(xiàn)的方法是 AllowRequest，IsOpen判斷當(dāng)前是否處于熔斷狀態(tài)，allowSingleTest就是去看是否過(guò)了一段時(shí)間需要重新進(jìn)行嘗試
- func (circuit *CircuitBreaker) AllowRequest() bool {
- return !circuit.IsOpen() || circuit.allowSingleTest()
- }
IsOpen先看當(dāng)前是否已經(jīng)打開(kāi)了，如果已經(jīng)打開(kāi)了就直接返回就行了，如果還沒(méi)打開(kāi)就去判斷
請(qǐng)求數(shù)量是否滿足要求
請(qǐng)求的錯(cuò)誤率是否過(guò)高，如果兩個(gè)都滿足就會(huì)打開(kāi)熔斷器
- 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已經(jīng)可以比較好的滿足我們的需求，但是存在一個(gè)問(wèn)題就是一旦觸發(fā)了熔斷，在一段時(shí)間之類(lèi)就會(huì)被一刀切的攔截請(qǐng)求，所以我們來(lái)看看 google sre 的一個(gè)實(shí)現(xiàn)
Google SRE 過(guò)載保護(hù)算法
算法如上所示，這個(gè)公式計(jì)算的是請(qǐng)求被丟棄的概率[^3]
- requests: 一段時(shí)間的請(qǐng)求數(shù)量
- accepts: 成功的請(qǐng)求數(shù)量
- K: 倍率，K 越小表示越激進(jìn)，越小表示越容易被丟棄請(qǐng)求
這個(gè)算法的好處是不會(huì)直接一刀切的丟棄所有請(qǐng)求，而是計(jì)算出一個(gè)概率來(lái)進(jìn)行判斷，當(dāng)成功的請(qǐng)求數(shù)量越少，K越小的時(shí)候
的值就越大，計(jì)算出的概率也就越大，表示這個(gè)請(qǐng)求被丟棄的概率越大
Kratos 實(shí)現(xiàn)分析
- func (b *sreBreaker) Allow() error {
- // 統(tǒng)計(jì)成功的請(qǐng)求，和總的請(qǐng)求
- success, total := b.summary()
- // 計(jì)算當(dāng)前的成功率
- k := b.k * float64(success)
- if log.V(5) {
- log.Info("breaker: request: %d, succee: %d, fail: %d", total, success, total-success)
- }
- // 統(tǒng)計(jì)請(qǐng)求量和成功率
- // 如果 rps 比較小，不觸發(fā)熔斷
- // 如果成功率比較高，不觸發(fā)熔斷，如果 k = 2，那么就是成功率 >= 50% 的時(shí)候就不熔斷
- 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)
- }
- // 計(jì)算一個(gè)概率，當(dāng) 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
- }
- // 通過(guò)隨機(jī)來(lái)判斷是否需要進(jìn)行熔斷
- func (b *sreBreaker) trueOnProba(proba float64) (truth bool) {
- b.randLock.Lock()
- truth = b.r.Float64() < proba
- b.randLock.Unlock()
- return
- }
總結(jié)
可用性僅靠服務(wù)端來(lái)保證是不靠譜的，只有整條鏈路上的所有服務(wù)都做好了自己可用性相關(guān)的建設(shè)我們的服務(wù) SLA 最后才能夠有保證。今天我們講了 hystrix-go 和 kratos 兩種熔斷的實(shí)現(xiàn)方式，kratos采用 Google SRE 的實(shí)現(xiàn)的好處就是沒(méi)有半開(kāi)的狀態(tài)，也沒(méi)有完全開(kāi)啟的狀態(tài)，而是通過(guò)一個(gè)概率來(lái)進(jìn)行判斷我們的流量是否應(yīng)該通過(guò)，這樣沒(méi)有那么死板，也可以保證我們錯(cuò)誤率比較高的時(shí)候不會(huì)大量請(qǐng)求服務(wù)端，給服務(wù)端喘息恢復(fù)的時(shí)間。
參考文獻(xiàn)
[^1]: 極客時(shí)間: Go 進(jìn)階訓(xùn)練營(yíng) https://u.geekbang.org/subject/go?utm_source=lailin.xyz&utm_medium=lailin.xyz
[^2]: 熔斷原理與實(shí)現(xiàn)Golang版 https://www.jianshu.com/p/0ee350cde543
[^3]: Google SRE https://sre.google/sre-book/handling-overload/#eq2101
[^4]: hystrix-go https://github.com/afex/hystrix-go/
[^5]: kratos 實(shí)現(xiàn) https://github.com/go-kratos/kratos/blob/v1.0.x/pkg/net/netutil/breaker/sre_breaker.go
本文轉(zhuǎn)載自微信公眾號(hào)「mohuishou」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系mohuishou公眾號(hào)。
