前言

說(shuō)明

1. 原文中 Circuit Breakers 這里翻譯為了熔斷器，大家也可以理解叫為斷路器

2. fallback本文翻譯為兜底，大家也可以理解為容錯(cuò)補(bǔ)救。

本文翻譯自https://ioshellboy.medium.com/circuit-breakers-in-golang-1779da9b001，由于本人翻譯水平有限，翻譯不當(dāng)之處煩請(qǐng)指出。希望大家看了這篇文章能有所幫助。感謝捧場(chǎng)。

什么是熔斷器

當(dāng)你看到 “熔斷器” 這個(gè)術(shù)語(yǔ)時(shí)，你會(huì)想到什么呢?

從圖片字面意思理解是使用一個(gè)錘子破壞了一個(gè)電路。

我們一般都會(huì)在自己家里安裝熔斷器，以阻止異常的電流從電網(wǎng)流向家里。在開始“微服務(wù)的熔斷器”之前，讓我們先看看它是如何工作的。

如上圖所示，一個(gè)典型的熔斷器裝置有 2 個(gè)主要部件:

1. 用火線緊緊包裹的軟鐵芯
2. 觸體。只要接觸點(diǎn)能夠形成一個(gè)連接點(diǎn)，電流就會(huì)從外部電源流向我們的房子。相反，如果連接斷開，電流就停止流動(dòng)。

當(dāng)電流通過纏繞在軟鐵芯周圍的導(dǎo)線時(shí)，軟鐵芯就像一塊電磁鐵，當(dāng)流過它的電流高于預(yù)期的安培時(shí)，電磁鐵就會(huì)變得強(qiáng)大到足以吸引鄰近的觸點(diǎn)，從而導(dǎo)致短路。

你一定在想，這與微服務(wù)架構(gòu)有什么關(guān)系呢？在我看來(lái)，這是高度相關(guān)的，正如我們下面將要看到的！

微服務(wù)架構(gòu)中的級(jí)聯(lián)故障

微服務(wù)架構(gòu)已經(jīng)很好地取代了單體架構(gòu)，但是為了使我們的系統(tǒng)具有高度的彈性，我們還需要解決一些關(guān)鍵問題。

微服務(wù)的一個(gè)問題是級(jí)聯(lián)故障。舉一個(gè)例子來(lái)更好地理解它。

在上圖中，參與者調(diào)用我們的主服務(wù)，它依賴于上游服務(wù)——A，B，C。現(xiàn)在假定，服務(wù) A 是一個(gè)讀取量較大的系統(tǒng)，它依賴于數(shù)據(jù)庫(kù)。這個(gè)數(shù)據(jù)庫(kù)有其自身的局限性，并且在過載時(shí)，可能導(dǎo)致連接重置。這個(gè)問題不僅會(huì)影響服務(wù) A 的性能，還會(huì)影響主服務(wù)。

這就是人們所說(shuō)的“一塊臭肉壞了整鍋湯”，喝過這鍋湯的人肯定會(huì)有同感。下面讓我們用一個(gè)例子來(lái)驗(yàn)證這一點(diǎn)。

讓我們構(gòu)建一個(gè) Netflixisc 應(yīng)用程序。其中一個(gè)微服務(wù)負(fù)責(zé)提供feed頁(yè)面的電影服務(wù)。此服務(wù)還依賴于推薦服務(wù)為用戶提供適當(dāng)?shù)耐扑]。

// Recommendation Service
func main() {
 logGoroutines()
 http.HandleFunc("/recommendations", recoHandler)
 log.Fatal(http.ListenAndServe(":9090", nil))
}

func logGoroutines() {
 ticker := time.NewTicker(500 * time.Millisecond)
 done := make(chan bool)
 go func() {
  for {
   select {
   case <-done:
    return
   case t := <-ticker.C:
    fmt.Printf("\n%v - %v", t, runtime.NumGoroutine())
   }
  }
 }()
}

func recoHandler(w http.ResponseWriter, r *http.Request) {
 a := `{"movies": ["Few Angry Men", "Pride & Prejudice"]}`
 w.Write([]byte(a))
}

推薦服務(wù)暴露一個(gè)路由接口 /recommendations，它返回一個(gè)推薦電影列表，同時(shí)每 500 毫秒打印一次 goroutine 的數(shù)量。

// Movies App
type MovieResponse struct {
 Feed           []string
 Recommendation []string
}

func main() {
 http.HandleFunc("/movies", fetchMoviesFeedHandler)
 log.Fatal(http.ListenAndServe(":8080", nil))
}

func fetchMoviesFeedHandler(w http.ResponseWriter, r *http.Request) {
 mr := MovieResponse{
  Feed: []string{"Transformers", "Fault in our stars", "The Old Boy"},
 }
 rms, err := fetchRecommendations()
 if err != nil {
  w.WriteHeader(500)
 }
 mr.Recommendation = rms
 bytes, err := json.Marshal(mr)
 if err != nil {
  w.WriteHeader(500)
 }
 w.Write(bytes)
}

func fetchRecommendations() ([]string, error) {
 resp, err := http.Get("http://localhost:9090/recommendations")
 if err != nil {
  return []string{}, err
 }
 defer resp.Body.Close()
 body, err := ioutil.ReadAll(resp.Body)
 if err != nil {
  return []string{}, err
 }
 var mvsr map[string]interface{}
 err = json.Unmarshal(body, &mvsr)
 if err != nil {
  return []string{}, err
 }
 mvsb, err := json.Marshal(mvsr["movies"])
 if err != nil {
  return []string{}, err
 }
 var mvs []string
 err = json.Unmarshal(mvsb, &mvs)
 if err != nil {
  return []string{}, err
 }
 return mvs, nil
}

電影服務(wù)暴露一個(gè)路由 /movies，它返回電影列表和推薦列表。為了獲取推薦，它反過來(lái)調(diào)用上游的推薦服務(wù)。

通過此設(shè)置，讓我們以每秒 100 個(gè)請(qǐng)求的速率訪問電影服務(wù)，持續(xù) 3 秒鐘。在 99% 的毫秒范圍內(nèi)，我們可以獲得 100% 的成功。這是預(yù)期的，因?yàn)橹惶峁╈o態(tài)數(shù)據(jù)。

現(xiàn)在，假設(shè)推薦服務(wù)的響應(yīng)時(shí)間過長(zhǎng)，并在 recoHandler 添加20秒的等待時(shí)間，然后重新進(jìn)行測(cè)試。成功率會(huì)下降，而響應(yīng)時(shí)間也會(huì)開始受到影響。此外，在測(cè)試期間阻塞在推薦服務(wù)上的goroutine數(shù)量將急劇增加。

推薦服務(wù)的停工時(shí)間影響了終端用戶，因?yàn)楸緛?lái)可以提供給他的電影feed列表都沒有提供。這正是級(jí)聯(lián)故障對(duì)我們的系統(tǒng)造成的影響。

熔斷器救援

熔斷器是一個(gè)非常簡(jiǎn)單但相當(dāng)重要的概念，因?yàn)樗梢宰屛覀儽３址?wù)的高可用性。熔斷器有三種狀態(tài):

• Closed State 關(guān)閉狀態(tài)

關(guān)閉狀態(tài)是指數(shù)據(jù)通過的時(shí)候連接處關(guān)閉的狀態(tài)。這是我們的理想狀態(tài)，其中上游服務(wù)正如預(yù)期的那樣工作。

• Open State 開放狀態(tài)

打開狀態(tài)指的是由于上游服務(wù)未按預(yù)期響應(yīng)而導(dǎo)致電路短路的狀態(tài)。這種短路可以避免上游服務(wù)在已經(jīng)掙扎的情況下不堪重負(fù)。此外，下游服務(wù)的業(yè)務(wù)邏輯可以更快地獲得上游可用性狀態(tài)的反饋，而無(wú)需等待上游的響應(yīng)。

• Half Open State 半開狀態(tài)
  
  

  

如果熔斷器是打開狀態(tài)，我們希望它在上游服務(wù)再次可用時(shí)立即關(guān)閉它。雖然你可以通過手動(dòng)干預(yù)來(lái)實(shí)現(xiàn)，但首選的方法應(yīng)該是在電路最后一次打開，讓一些請(qǐng)求延遲之后通過電路，

如果這些請(qǐng)求請(qǐng)求上游服務(wù)成功，我們就可以安全地接通整個(gè)鏈路。

另一方面，如果這些請(qǐng)求失敗，熔斷器仍然處于打開狀態(tài)。

熔斷器的狀態(tài)圖如下:

1. 初始狀態(tài)下熔斷器是關(guān)閉的，當(dāng)故障超過配置的閾值，則會(huì)打開
2. 熔斷器是打開狀態(tài)，在經(jīng)過一段熔斷時(shí)間后，部分會(huì)打開
3. 如果熔斷器是半開的，它可以
• 再次打開，如果允許通過的請(qǐng)求也失敗了
• 關(guān)閉，如果允許通過的請(qǐng)求成功響應(yīng)

熔斷器在 Golang 的應(yīng)用

雖然有多個(gè)庫(kù)可供選擇，但最常用的是 hystrix^[1]。正如文檔建議的那樣，hystrix 是 Netflix 設(shè)計(jì)的一個(gè)延遲和容錯(cuò)庫(kù)，用于隔離遠(yuǎn)程系統(tǒng)、服務(wù)和第三方庫(kù)的訪問，阻止級(jí)聯(lián)故障，并在不可避免的故障發(fā)生的復(fù)雜分布式系統(tǒng)中實(shí)現(xiàn)恢復(fù)能力。

Hystrix 熔斷器的實(shí)現(xiàn)取決于以下配置:

1. 超時(shí) ー 上游服務(wù)響應(yīng)的等待時(shí)間
2. 最大并發(fā)請(qǐng)求 ー 上游服務(wù)允許調(diào)用的最大并發(fā)
3. 請(qǐng)求容量閾值 ー 在熔斷之前的請(qǐng)求數(shù)，斷路器在需要更改狀態(tài)時(shí)無(wú)法評(píng)估的請(qǐng)求數(shù)量
4. 睡眠窗口 ー 開放狀態(tài)與半開放狀態(tài)之間的延遲時(shí)間
5. 誤差百分比閾值ー熔斷器短路時(shí)的誤差百分比閾值

接下來(lái)讓我們?cè)陔娪昂屯扑]示例中使用它，并在獲取推薦時(shí)實(shí)現(xiàn)熔斷器模式。

var downstreamErrCount int
var circuitOpenErrCount int

func main() {
 downstreamErrCount = 0
 circuitOpenErrCount = 0
 hystrix.ConfigureCommand("recommendation", hystrix.CommandConfig{
  Timeout: 100,
  RequestVolumeThreshold: 25,
  ErrorPercentThreshold:  5,
  SleepWindow:            1000,
 })
 http.HandleFunc("/movies", fetchMoviesFeedHandlerWithCircuitBreaker)
 log.Fatal(http.ListenAndServe(":8080", nil))
}

func fetchMoviesFeedHandlerWithCircuitBreaker(w http.ResponseWriter, r *http.Request) {
 mr := MovieResponse{
  Feed: []string{"Transformers", "Fault in our stars", "The Old Boy"},
 }
 
 output := make(chan bool, 1)
 errors := hystrix.Go("recommendation", func() error {
  // talk to other services
  rms, err := fetchRecommendations()
  if err != nil {
   return err
  }
  mr.Recommendation = rms
  output <- true
  return nil
 }, func(err error) error {
     // 寫你的fallback(兜底)邏輯
  return nil
 })

 select {
 case err := <-errors:
  if err == hystrix.ErrCircuitOpen {
   circuitOpenErrCount = circuitOpenErrCount + 1
  } else {
   downstreamErrCount = downstreamErrCount + 1
  }

 case _ = <-output:

 }

 bytes, err := json.Marshal(mr)
 if err != nil {
  w.WriteHeader(500)
 }
 fmt.Printf("\ndownstreamErrCount=%d, circuitOpenErrCount=%d", downstreamErrCount, circuitOpenErrCount)
 w.Write(bytes)
}

使用 Hystrix，您還可以在熔斷器打開時(shí)實(shí)現(xiàn)兜底邏輯。這種邏輯可能因情況而異。如果熔斷器打開，則從緩存中獲取。

使用這個(gè)更新的邏輯，讓我們嘗試以每秒100個(gè)請(qǐng)求的速率重新攻擊 3 秒鐘。

哇! ！100% 的成功率，在打開的情況下，我們只提供 Feed 和返回 0個(gè)推薦。此外，由于每當(dāng)熔斷器熔斷，我們不再調(diào)用上游服務(wù)，因此推薦服務(wù)不會(huì)不堪重負(fù)，阻塞的 goroutine 數(shù)量不會(huì)像以前那么多。

擴(kuò)展閱讀

我的建議:

1. 關(guān)于 Netflix Hystrix^[2]
2. Hystrix 是怎樣工作的？^[3]
3. Hystrix bucketing^[4]

參考資料