微服務領域里有個詞叫服務熔斷，你知道這是啥不？
故事要從我讀大學那會說起。
因為功率問題，很多寢室都是不讓用吹風筒和熱水壺的。
但我那時候頭鐵，不僅用，而且還同時開了兩個熱水壺和一個吹風筒。直接給寢室電路來了個壓測。
不出意外的出了意外，寢室直接停電。
一時間，隔壁寢室燈火通明，我們寢室一片漆黑。
作為本科專業電氣工程的靚仔，我們意識到，這妥妥是電路過載導致斷路器跳閘了。
于是我們趁社管阿姨不注意，偷偷摸進配電房，手動將斷路器開關復位，寢室就來電了。

是真的有驚無險。
如果沒有這個斷路器，寢室總電路怕是得因為過載全部燒掉，我們幾個妥妥會提前進入社會大學。
我能畢業，全靠這個斷路器！
看到這里，我們知道了斷路器的作用，就是在電路出問題的時候及時斷開電路，避免過載，從而保護電路。
在微服務領域，我們也可以借鑒斷路器的思路，引入了服務熔斷的概念。

服務熔斷是什么

服務熔斷，也就是 Circuit Breaker，本質上是一種軟件設計模式，用于在分布式系統中處理服務調用失敗的情況。

假設有個 A 服務調用 B 服務的場景，如果 B 服務已經出現頻繁失敗的情況，A 繼續調用只會加劇 B 服務的負擔，嚴重的時候，有可能導致 B 服務崩潰，甚至出現 B 服務重啟后立馬被打崩的情況。因此，最好的做法是，在一段時間內先不要再頻繁調用 B 服務。

為了實現這個保護效果，我們可以在 A 和 B 之間加一個熔斷器。當 B 服務頻繁失敗時，熔斷器可以防止 A 繼續頻繁調用 B 服務，相當于阻斷服務間的請求，并且還能在 B 服務恢復正常之后，恢復 A 對 B 的調用。

熔斷器的作用

工作原理也和上文提到的宿舍電路里的斷路器類似。當服務調用失敗的次數超過某個閾值時，熔斷器會自動“打開”（Open），阻止進一步的服務調用，防止不斷報錯重試導致壓垮被調用服務。

然后在在一段時間之后，熔斷器開始嘗試允許少量的請求通過，以檢查服務是否已經恢復，也就是所謂的“半打開”（HalfOpen）。

如果這些請求成功，熔斷器會“關閉”(Close)，系統恢復正常的服務調用；但如果調用還是失敗，那熔斷器會繼續再次回到“打開”（Open）狀態。

上面提到的三個狀態Open，HalfOpen和Close是服務熔斷中非常重要的三個狀態。

•  Closed（關閉）：這是熔斷器的初始狀態。在這種狀態下，可以進行服務間調用，熔斷器會跟蹤服務調用的成功和失敗情況。如果失敗調用次數，到了某個配置的閾值，熔斷器就會切換到 Open（打開）狀態。

熔斷器關閉

• HalfOpen（半開）：保持 Open 狀態一段時間后，熔斷器會嘗試進入 HalfOpen 狀態。這個狀態下，熔斷器會嘗試放幾個請求通過，看下被調用服務是否已經恢復。如果這些請求成功，熔斷器就會回到 Closed 狀態；如果失敗，那它會退回到 Open 狀態。

熔斷器半打開

•  Open（打開）：當熔斷器檢測到服務調用連續失敗時，它會切換到 Open 狀態。在這種狀態下，熔斷器會阻止所有對服務的調用，直到超時時間過后，或者在 HalfOpen 狀態下的探測請求成功。
  

熔斷器打開

它們的狀態流轉關系就像下圖這樣。

熔斷狀態機

怎么使用熔斷器？

可以看出，熔斷器的邏輯其實很簡單，而且這么通用的功能，必然有現成的庫可以直接拿來用。
比如阿里開源的sentinel-golang。
使用也比較簡單。只需要三步。

1.引入 circuitbreaker 庫

"github.com/alibaba/sentinel-golang/core/circuitbreaker"

2.聲明熔斷規則

通過circuitbreaker.LoadRules加載對應的熔斷規則。

_, err = circuitbreaker.LoadRules([]*circuitbreaker.Rule{
        // Statistic time span=5s, recoveryTimeout=3s, maxErrorRatio=40%
        {
            Resource:                     "api_url",
            Strategy:                     circuitbreaker.ErrorRatio,
            RetryTimeoutMs:               3000,
            MinRequestAmount:             10,
            StatIntervalMs:               5000,
            StatSlidingWindowBucketCount: 10,
            Threshold:                    0.4,
        },
    })

這里面有幾個需要注意的地方：

•  Resource 是想要保護的資源名稱，也就是上面提到的 B 服務，這里可以直接使用被調用方的 url。
•  Strategy 是指熔斷策略，示例代碼里展示的是錯誤率，也就是說服務達到 xx 比例的錯誤率時就會觸發熔斷。同時這里還支持填其他策略，比如從錯誤率換成錯誤次數或者是慢調用的比例個數。
•  RetryTimeoutMs 是指熔斷器打開后經過多長時間后進行重試。在熔斷器 Open 期間，請求會被直接拒絕，不會發送到后端 Resource（B 服務）。在指定的超時時間之后，熔斷器將嘗試發送一個請求以檢查后端資源的可用性。
•  MinRequestAmount 表示在進行熔斷之前必須滿足的最小請求數量。只有當請求的數量達到或超過這個閾值時，熔斷器才會生效。這個參數可以用來避免在系統啟動時就觸發熔斷。
•  StatIntervalMs 表示統計信息的時間間隔，以毫秒為單位。在這個時間間隔內，熔斷器將收集請求的統計信息，用于計算錯誤率。
•  Threshold：表示錯誤率的閾值。當錯誤率超過這個閾值時，熔斷器將觸發熔斷，停止發送請求到后端資源。

3.加入熔斷保護

在需要進行熔斷保護的地方，加入下面的代碼：

e, b := sentinel.Entry("api_url")
        if b == nil {
            // 通過檢測，不需要熔斷，直接執行api調用
            err := api_call()
            if err != nil {
                sentinel.TraceError(e, err)
            }
            // 保證執行完之后退出資源
            e.Exit()
        }

上面的 sentinel.Entry()方法內部會自動檢測"api_url"這個資源是否需要打開熔斷器，如果 api 調用報錯了，可以通過 sentinel.TraceError 記錄下來，sentinel 內部會根據報錯去計算報錯率，自動判斷要不要熔斷。

到這里，就算使用上熔斷器的能力啦。

總結

• 服務熔斷是一種軟件設計模式，用于分布式系統中處理服務調用失敗的情況，可以防止被調用服務因為頻繁失敗被壓垮。它借鑒了電路中的斷路器原理，通過監控服務調用的失敗率等條件來決定是否阻止進一步的調用，以保護系統免受過載。
• 服務熔斷器有三個主要狀態：關閉（Closed）、半開（HalfOpen）和打開（Open），分別對應不同的保護策略。當服務調用失敗次數超過閾值時，熔斷器打開，阻止服務調用。在一定時間后，熔斷器嘗試半開狀態，允許少量請求通過以測試服務恢復情況。如果服務恢復，熔斷器關閉；如果失敗，熔斷器保持打開狀態。
• 在 go 語言里可以使用 sentinel-golang 庫實現熔斷功能。