av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

詳解Go可用性(六)熔斷

在前面的幾篇文章當(dāng)中，無論是令牌桶、漏桶還是自適應(yīng)限流的方法，總的來說都是服務(wù)端的單機(jī)限流方式。雖然服務(wù)端限流雖然可以幫助我們抗住一定的壓力，但是拒絕請求畢竟還是有成本的。如果我們的本來流量可以支撐 1w rps，加了限流可以支撐在 10w rps 的情況下仍然可以提供 1w rps 的有效請求，但是流量突然再翻了 10 倍，來到 100w rps 那么服務(wù)該掛還是得掛。

創(chuàng)新互聯(lián)建站主要從事網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)河源,10余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):13518219792

所以我們的可用性建設(shè)不僅僅是服務(wù)端做建設(shè)就可以萬事大吉了，得在整個(gè)鏈路上的每個(gè)組件都做好自己的事情才行，今天我們就來一起看一下客戶端上的限流措施：熔斷。

熔斷器

熔斷器[^2]

如上圖[^2]所示，熔斷器存在三個(gè)狀態(tài):

關(guān)閉(closed): 關(guān)閉狀態(tài)下沒有觸發(fā)斷路保護(hù)，所有的請求都正常通行

打開(open): 當(dāng)錯(cuò)誤閾值觸發(fā)之后，就進(jìn)入開啟狀態(tài)，這個(gè)時(shí)候所有的流量都會被節(jié)流，不運(yùn)行通行

半打開(half-open): 處于打開狀態(tài)一段時(shí)間之后，會嘗試嘗試放行一個(gè)流量來探測當(dāng)前 server 端是否可以接收新流量，如果這個(gè)沒有問題就會進(jìn)入關(guān)閉狀態(tài)，如果有問題又會回到打開狀態(tài)

hystrix-go

熔斷器中比較典型的實(shí)現(xiàn)就是 hystrix，Golang 也有對應(yīng)的版本，我們先來看一下 hystrix-go 是怎么實(shí)現(xiàn)的

案例

先看一個(gè)使用案例，首先我們使用 gin 啟動一個(gè)服務(wù)端，這個(gè)服務(wù)端主要是前 200ms 的請求都會返回 500，之后的請求都會返回 200

 
 
 
 
    
  
  
  
  
  1. func server() { 
    2.   
  
  
  
  2.  e := gin.Default() 
    3.   
  
  
  
  3.  e.GET("/ping", func(ctx *gin.Context) { 
    4.   
  
  
  
  4.   if time.Since(start) < 201*time.Millisecond { 
    5.   
  
  
  
  5.    ctx.String(http.StatusInternalServerError, "pong") 
    6.   
  
  
  
  6.    return 
    7.   
  
  
  
  7.   } 
    8.   
  
  
  
  8.   ctx.String(http.StatusOK, "pong") 
    9.   
  
  
  
  9.  }) 
    10.   
  
  
  
  10.  e.Run(":8080") 
    11.   
  
  
  
  11. } 
    12.

然后配置 hystrix，hystrix.ConfigureCommand(command name, config) hystrix 的配置是按照每個(gè) command 進(jìn)行配置，使用的時(shí)候我們也需要傳遞一個(gè) command，下面的配置就是我們的請求數(shù)量大于等于 10 個(gè)并且錯(cuò)誤率大于等于 20% 的時(shí)候就會觸發(fā)熔斷器開關(guān)，熔斷器打開 500ms 之后會進(jìn)入半打開的狀態(tài)，嘗試放一部分請求去訪問

 
 
 
 
    
  
  
  
  
  1. func main(){ 
    2.   
  
  
  
  2.  hystrix.ConfigureCommand("test", hystrix.CommandConfig{ 
    3.   
  
  
  
  3.   // 執(zhí)行 command 的超時(shí)時(shí)間 
    4.   
  
  
  
  4.   Timeout: 10, 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.   // 最大并發(fā)量 
    7.   
  
  
  
  7.   MaxConcurrentRequests: 100, 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.   // 一個(gè)統(tǒng)計(jì)窗口 10 秒內(nèi)請求數(shù)量 
    10.   
  
  
  
  10.   // 達(dá)到這個(gè)請求數(shù)量后才去判斷是否要開啟熔斷 
    11.   
  
  
  
  11.   RequestVolumeThreshold: 10, 
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13.   // 熔斷器被打開后 
    14.   
  
  
  
  14.   // SleepWindow 的時(shí)間就是控制過多久后去嘗試服務(wù)是否可用了 
    15.   
  
  
  
  15.     // 單位為毫秒 
    16.   
  
  
  
  16.   SleepWindow: 500, 
    17.   
  
  
  
  17.  
    18.   
  
  
  
  18.   // 錯(cuò)誤百分比 
    19.   
  
  
  
  19.   // 請求數(shù)量大于等于 RequestVolumeThreshold 并且錯(cuò)誤率到達(dá)這個(gè)百分比后就會啟動熔斷 
    20.   
  
  
  
  20.   ErrorPercentThreshold: 20, 
    21.   
  
  
  
  21.  }) 
    22.   
  
  
  
  22. } 
    23.

然后我們使用一個(gè)循環(huán)當(dāng)做客戶端代碼，會請求 20 次，每一個(gè)請求消耗 100ms

 
 
 
 
    
  
  
  
  
  1. func main() { 
    2.   
  
  
  
  2.  go server() 
    3.   
  
  
  
  3.   
    4.   
  
  
  
  4.   // 這里是 config 代碼 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.  for i := 0; i < 20; i++ { 
    7.   
  
  
  
  7.   _ = hystrix.Do("test", func() error { 
    8.   
  
  
  
  8.    resp, _ := resty.New().R().Get("http://localhost:8080/ping") 
    9.   
  
  
  
  9.    if resp.IsError() { 
    10.   
  
  
  
  10.     return fmt.Errorf("err code: %s", resp.Status()) 
    11.   
  
  
  
  11.    } 
    12.   
  
  
  
  12.    return nil 
    13.   
  
  
  
  13.   }, func(err error) error { 
    14.   
  
  
  
  14.    fmt.Println("fallback err: ", err) 
    15.   
  
  
  
  15.    return err 
    16.   
  
  
  
  16.   }) 
    17.   
  
  
  
  17.   time.Sleep(100 * time.Millisecond) 
    18.   
  
  
  
  18.  } 
    19.   
  
  
  
  19.  
    20.   
  
  
  
  20. } 
    21.

所以我們執(zhí)行的結(jié)果就是，前面 2 個(gè)請求報(bào) 500，等到發(fā)起了 10 個(gè)請求之后就會進(jìn)入熔斷， 500ms 也就是發(fā)出 5 個(gè)請求之后就會重新去請求服務(wù)端

image-20210504164650024

hystrix-go 核心實(shí)現(xiàn)

核心實(shí)現(xiàn)的方法是 AllowRequest，IsOpen判斷當(dāng)前是否處于熔斷狀態(tài)，allowSingleTest就是去看是否過了一段時(shí)間需要重新進(jìn)行嘗試

 
 
 
 
    
  
  
  
  
  1. func (circuit *CircuitBreaker) AllowRequest() bool { 
    2.   
  
  
  
  2.  return !circuit.IsOpen() || circuit.allowSingleTest() 
    3.   
  
  
  
  3. } 
    4.

IsOpen先看當(dāng)前是否已經(jīng)打開了，如果已經(jīng)打開了就直接返回就行了，如果還沒打開就去判斷

請求數(shù)量是否滿足要求

請求的錯(cuò)誤率是否過高，如果兩個(gè)都滿足就會打開熔斷器

 
 
 
 
    
  
  
  
  
  1. func (circuit *CircuitBreaker) IsOpen() bool { 
    2.   
  
  
  
  2.  circuit.mutex.RLock() 
    3.   
  
  
  
  3.  o := circuit.forceOpen || circuit.open 
    4.   
  
  
  
  4.  circuit.mutex.RUnlock() 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.  if o { 
    7.   
  
  
  
  7.   return true 
    8.   
  
  
  
  8.  } 
    9.   
  
  
  
  9.  
    10.   
  
  
  
  10.  if uint64(circuit.metrics.Requests().Sum(time.Now())) < getSettings(circuit.Name).RequestVolumeThreshold { 
    11.   
  
  
  
  11.   return false 
    12.   
  
  
  
  12.  } 
    13.   
  
  
  
  13.  
    14.   
  
  
  
  14.  if !circuit.metrics.IsHealthy(time.Now()) { 
    15.   
  
  
  
  15.   // too many failures, open the circuit 
    16.   
  
  
  
  16.   circuit.setOpen() 
    17.   
  
  
  
  17.   return true 
    18.   
  
  
  
  18.  } 
    19.   
  
  
  
  19.  
    20.   
  
  
  
  20.  return false 
    21.   
  
  
  
  21. } 
    22.

hystrix-go已經(jīng)可以比較好的滿足我們的需求，但是存在一個(gè)問題就是一旦觸發(fā)了熔斷，在一段時(shí)間之類就會被一刀切的攔截請求，所以我們來看看 google sre 的一個(gè)實(shí)現(xiàn)

Google SRE 過載保護(hù)算法

算法如上所示，這個(gè)公式計(jì)算的是請求被丟棄的概率[^3]

  • requests: 一段時(shí)間的請求數(shù)量
  • accepts: 成功的請求數(shù)量
  • K: 倍率，K 越小表示越激進(jìn)，越小表示越容易被丟棄請求

這個(gè)算法的好處是不會直接一刀切的丟棄所有請求，而是計(jì)算出一個(gè)概率來進(jìn)行判斷，當(dāng)成功的請求數(shù)量越少，K越小的時(shí)候的值就越大，計(jì)算出的概率也就越大，表示這個(gè)請求被丟棄的概率越大

Kratos 實(shí)現(xiàn)分析

 
 
 
 
    
  
  
  
  
  1. func (b *sreBreaker) Allow() error { 
    2.   
  
  
  
  2.  // 統(tǒng)計(jì)成功的請求，和總的請求 
    3.   
  
  
  
  3.  success, total := b.summary() 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.  // 計(jì)算當(dāng)前的成功率 
    6.   
  
  
  
  6.  k := b.k * float64(success) 
    7.   
  
  
  
  7.  if log.V(5) { 
    8.   
  
  
  
  8.   log.Info("breaker: request: %d, succee: %d, fail: %d", total, success, total-success) 
    9.   
  
  
  
  9.  } 
    10.   
  
  
  
  10.  // 統(tǒng)計(jì)請求量和成功率 
    11.   
  
  
  
  11.  // 如果 rps 比較小，不觸發(fā)熔斷 
    12.   
  
  
  
  12.  // 如果成功率比較高，不觸發(fā)熔斷，如果 k = 2，那么就是成功率 >= 50% 的時(shí)候就不熔斷 
    13.   
  
  
  
  13.  if total < b.request || float64(total) < k { 
    14.   
  
  
  
  14.   if atomic.LoadInt32(&b.state) == StateOpen { 
    15.   
  
  
  
  15.    atomic.CompareAndSwapInt32(&b.state, StateOpen, StateClosed) 
    16.   
  
  
  
  16.   } 
    17.   
  
  
  
  17.   return nil 
    18.   
  
  
  
  18.  } 
    19.   
  
  
  
  19.  if atomic.LoadInt32(&b.state) == StateClosed { 
    20.   
  
  
  
  20.   atomic.CompareAndSwapInt32(&b.state, StateClosed, StateOpen) 
    21.   
  
  
  
  21.  } 
    22.   
  
  
  
  22.  
    23.   
  
  
  
  23.  // 計(jì)算一個(gè)概率，當(dāng) dr 值越大，那么被丟棄的概率也就越大 
    24.   
  
  
  
  24.  // dr 值是，如果失敗率越高或者是 k 值越小，那么它越大 
    25.   
  
  
  
  25.  dr := math.Max(0, (float64(total)-k)/float64(total+1)) 
    26.   
  
  
  
  26.  drop := b.trueOnProba(dr) 
    27.   
  
  
  
  27.  if log.V(5) { 
    28.   
  
  
  
  28.   log.Info("breaker: drop ratio: %f, drop: %t", dr, drop) 
    29.   
  
  
  
  29.  } 
    30.   
  
  
  
  30.  if drop { 
    31.   
  
  
  
  31.   return ecode.ServiceUnavailable 
    32.   
  
  
  
  32.  } 
    33.   
  
  
  
  33.  return nil 
    34.   
  
  
  
  34. } 
    35.   
  
  
  
  35.  
    36.   
  
  
  
  36. // 通過隨機(jī)來判斷是否需要進(jìn)行熔斷 
    37.   
  
  
  
  37. func (b *sreBreaker) trueOnProba(proba float64) (truth bool) { 
    38.   
  
  
  
  38.  b.randLock.Lock() 
    39.   
  
  
  
  39.  truth = b.r.Float64() < proba 
    40.   
  
  
  
  40.  b.randLock.Unlock() 
    41.   
  
  
  
  41.  return 
    42.   
  
  
  
  42. } 
    43.

總結(jié)

可用性僅靠服務(wù)端來保證是不靠譜的，只有整條鏈路上的所有服務(wù)都做好了自己可用性相關(guān)的建設(shè)我們的服務(wù) SLA 最后才能夠有保證。今天我們講了 hystrix-go 和 kratos 兩種熔斷的實(shí)現(xiàn)方式，kratos采用 Google SRE 的實(shí)現(xiàn)的好處就是沒有半開的狀態(tài)，也沒有完全開啟的狀態(tài)，而是通過一個(gè)概率來進(jìn)行判斷我們的流量是否應(yīng)該通過，這樣沒有那么死板，也可以保證我們錯(cuò)誤率比較高的時(shí)候不會大量請求服務(wù)端，給服務(wù)端喘息恢復(fù)的時(shí)間。

參考文獻(xiàn)

[^1]: 極客時(shí)間: Go 進(jìn)階訓(xùn)練營 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)載自微信公眾號「mohuishou」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系mohuishou公眾號。


文章標(biāo)題：詳解Go可用性(六)熔斷
當(dāng)前網(wǎng)址：http://uogjgqi.cn/article/ccspsgp.html
掃二維碼與項(xiàng)目經(jīng)理溝通

我們在微信上24小時(shí)期待你的聲音

解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流