熔斷原理與實現Golang版

在微服務中服務間依賴很是常見，好比評論服務依賴審覈服務而審覈服務又依賴反垃圾服務，當評論服務調用審覈服務時，審覈服務又調用反垃圾服務，而這時反垃圾服務超時了，因爲審覈服務依賴反垃圾服務，反垃圾服務超時致使審覈服務邏輯一直等待，而這個時候評論服務又在一直調用審覈服務，審覈服務就有可能由於堆積了大量請求而致使服務宕機

因而可知，在整個調用鏈中，中間的某一個環節出現異常就會引發上游調用服務出現一些列的問題，甚至致使整個調用鏈的服務都宕機，這是很是可怕的。所以一個服務做爲調用方調用另外一個服務時，爲了防止被調用服務出現問題進而致使調用服務出現問題，因此調用服務須要進行自我保護，而保護的經常使用手段就是熔斷

熔斷器原理

熔斷機制實際上是參考了咱們平常生活中的保險絲的保護機制，當電路超負荷運行時，保險絲會自動的斷開，從而保證電路中的電器不受損害。而服務治理中的熔斷機制，指的是在發起服務調用的時候，若是被調用方返回的錯誤率超過必定的閾值，那麼後續的請求將不會真正發起請求，而是在調用方直接返回錯誤

在這種模式下，服務調用方爲每個調用服務(調用路徑)維護一個狀態機，在這個狀態機中有三個狀態：

• 關閉(Closed)：在這種狀態下，咱們須要一個計數器來記錄調用失敗的次數和總的請求次數，若是在某個時間窗口內，失敗的失敗率達到預設的閾值，則切換到斷開狀態，此時開啓一個超時時間，當到達該時間則切換到半關閉狀態，該超時時間是給了系統一次機會來修正致使調用失敗的錯誤，以回到正常的工做狀態。在關閉狀態下，調用錯誤是基於時間的，在特定的時間間隔內會重置，這可以防止偶然錯誤致使熔斷器進去斷開狀態
• 打開(Open)：在該狀態下，發起請求時會當即返回錯誤，通常會啓動一個超時計時器，當計時器超時後，狀態切換到半打開狀態，也能夠設置一個定時器，按期的探測服務是否恢復
• 半打開(Half-Open)：在該狀態下，容許應用程序必定數量的請求發往被調用服務，若是這些調用正常，那麼能夠認爲被調用服務已經恢復正常，此時熔斷器切換到關閉狀態，同時須要重置計數。若是這部分仍有調用失敗的狀況，則認爲被調用方仍然沒有恢復，熔斷器會切換到關閉狀態，而後重置計數器，半打開狀態可以有效防止正在恢復中的服務被忽然大量請求再次打垮

服務治理中引入熔斷機制，使得系統更加穩定和有彈性，在系統從錯誤中恢復的時候提供穩定性，而且減小了錯誤對系統性能的影響，能夠快速拒絕可能致使錯誤的服務調用，而不須要等待真正的錯誤返回

熔斷器引入

上面介紹了熔斷器的原理，在瞭解完原理後，你是否有思考咱們如何引入熔斷器呢？一種方案是在業務邏輯中能夠加入熔斷器，但顯然是不夠優雅也不夠通用的，所以咱們須要把熔斷器集成在框架內，在zRPC框架內就內置了熔斷器

咱們知道，熔斷器主要是用來保護調用端，調用端在發起請求的時候須要先通過熔斷器，而客戶端攔截器正好兼具了這個這個功能，因此在zRPC框架內熔斷器是實如今客戶端攔截器內，攔截器的原理以下圖：

對應的代碼爲：

func BreakerInterceptor(ctx context.Context, method string, req, reply interface{},
	cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
  // 基於請求方法進行熔斷
	breakerName := path.Join(cc.Target(), method)
	return breaker.DoWithAcceptable(breakerName, func() error {
    // 真正發起調用
		return invoker(ctx, method, req, reply, cc, opts...)
    // codes.Acceptable判斷哪一種錯誤須要加入熔斷錯誤計數
	}, codes.Acceptable)
}

熔斷器實現

zRPC中熔斷器的實現參考了Google Sre過載保護算法，該算法的原理以下：

• 請求數量(requests)：調用方發起請求的數量總和
• 請求接受數量(accepts)：被調用方正常處理的請求數量

在正常狀況下，這兩個值是相等的，隨着被調用方服務出現異常開始拒絕請求，請求接受數量(accepts)的值開始逐漸小於請求數量(requests)，這個時候調用方能夠繼續發送請求，直到requests = K * accepts，一旦超過這個限制，熔斷器就回打開，新的請求會在本地以必定的機率被拋棄直接返回錯誤，機率的計算公式以下：

經過修改算法中的K(倍值)，能夠調節熔斷器的敏感度，當下降該倍值會使自適應熔斷算法更敏感，當增長該倍值會使得自適應熔斷算法下降敏感度，舉例來講，假設將調用方的請求上限從 requests = 2 * acceptst 調整爲 requests = 1.1 * accepts 那麼就意味着調用方每十個請求之中就有一個請求會觸發熔斷

代碼路徑爲go-zero/core/breaker

type googleBreaker struct {
	k     float64  // 倍值 默認1.5
	stat  *collection.RollingWindow // 滑動時間窗口，用來對請求失敗和成功計數
	proba *mathx.Proba // 動態機率
}

自適應熔斷算法實現

func (b *googleBreaker) accept() error {
	accepts, total := b.history()  // 請求接受數量和請求總量
	weightedAccepts := b.k * float64(accepts)
  // 計算丟棄請求機率
	dropRatio := math.Max(0, (float64(total-protection)-weightedAccepts)/float64(total+1))
	if dropRatio <= 0 {
		return nil
	}
	// 動態判斷是否觸發熔斷
	if b.proba.TrueOnProba(dropRatio) {
		return ErrServiceUnavailable
	}

	return nil
}

每次發起請求會調用doReq方法，在這個方法中首先經過accept效驗是否觸發熔斷，acceptable用來判斷哪些error會計入失敗計數，定義以下：

func Acceptable(err error) bool {
	switch status.Code(err) {
	case codes.DeadlineExceeded, codes.Internal, codes.Unavailable, codes.DataLoss: // 異常請求錯誤
		return false
	default:
		return true
	}
}

若是請求正常則經過markSuccess把請求數量和請求接受數量都加一，若是請求不正常則只有請求數量會加一

func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error {
	// 判斷是否觸發熔斷
  if err := b.accept(); err != nil {
		if fallback != nil {
			return fallback(err)
		} else {
			return err
		}
	}

	defer func() {
		if e := recover(); e != nil {
			b.markFailure()
			panic(e)
		}
	}()
	
  // 執行真正的調用
	err := req()
  // 正常請求計數
	if acceptable(err) {
		b.markSuccess()
	} else {
    // 異常請求計數
		b.markFailure()
	}

	return err
}

總結

調用端能夠經過熔斷機制進行自我保護，防止調用下游服務出現異常，或者耗時過長影響調用端的業務邏輯，不少功能完整的微服務框架都會內置熔斷器。其實，不只微服務調用之間須要熔斷器，在調用依賴資源的時候，好比mysql、redis等也能夠引入熔斷器的機制。

項目地址：
https://github.com/tal-tech/go-zero