微服務的斷路器實現圖解Golang通用版

斷路器背景

微服務連鎖故障場景

在分佈式環境中，各個微服務相互調用，當某些狀況下，好比後端中間件服務故障、第三方服務中斷致使某個服務無限期不可用，短期沒法恢復，則可能會致使連鎖故障，最終影響壓垮整個業務集羣

斷路器與重試

斷路器模式不一樣於重試模式，重試模式是使應用程序能夠重試操做以指望它會成功，而斷路器模式是防止應用程序執行一個可能失敗的操做，減小執行可能失敗操做的CPU、內存、線程等資源的浪費，從而保證服務的總體可用

斷路器設計解析

基於代理模式的斷路器

斷路器至關於一個請求操做執行的代理，託管請求操做的執行

實現原理流程：

1. 攔截服務執行的請求，經過當前狀態決定是否直接返回，若是不然執行後續操做
2. 嘗試執行操做，並獲取返回結果
3. 根據返回結果和當前統計信息，決定當前斷路器的狀態，修改狀態
4. 返回執行結果

斷路器狀態機

斷路器狀態機實現上有三種狀態：Closed(斷路器關閉)、Open(開放)、HalfOpen(半開放)

狀態	說明	備註
Closed	關閉	斷路器關閉正常執行操做
Open	打開	斷路器開放,全部請求直接返回錯誤，不執行任何請求
HalfOpen	半開放	容許有限數量的請求經過,若是執行成功，恢復到關閉狀態，若是仍然失敗，則恢復到開放，而後從新啓動超時定時器

#斷路器實現

實現原理圖解

斷路器實現實現主要分爲三部分：狀態統計、狀態轉移、請求執行

狀態統計：統計已經執行的請求的成功失敗的數量，以肯定是否須要進行狀態轉移 狀態轉移：根據當前統計信息和當前狀態來進行目標狀態的肯定及轉移操做 請求執行：代理前端任務的執行，若是當前狀態不須要進行嘗試執行，就直接返回錯誤，避免資源浪費

Golang裏面已經有開源的實現，https://github.com/sony/gobreaker/blob/, 接下來救市剖析它的實現

狀態統計-計數器Counts

Counts就是一個計數器，記錄當前請求成功和失敗的數量

type Counts struct {
	Requests             uint32    // 請求數
	TotalSuccesses       uint32    // 成功
	TotalFailures        uint32    // 失敗
	ConsecutiveSuccesses uint32    // 連續成功
	ConsecutiveFailures  uint32 // 連續失敗
}

計數器完成對應請求狀態的次數，爲後續狀態轉移提供數據, Counts提供了onRequest、onSuccess、onFailure、clear幾個輔助接口用於實現對應請求狀態的操做，感興趣能夠看下

狀態機- CircuitBreaker

type CircuitBreaker struct {
	name          string
        // maxRequests限制half-open狀態下最大的請求數，避免海量請求將在恢復過程當中的服務再次失敗
	maxRequests   uint32
     // interval用於在closed狀態下，斷路器多久清除一次Counts信息，若是設置爲0則在closed狀態下不會清除Counts
	interval      time.Duration
        // timeout進入open狀態下，多長時間切換到half-open狀態，默認60s
	timeout       time.Duration
        // readyToTrip熔斷條件，當執行失敗後，會根據readyToTrip決定是否進入Open狀態
	readyToTrip   func(counts Counts) bool
        // onStateChange斷路器狀態變動回調函數
	onStateChange func(name string, from State, to State)

	mutex      sync.Mutex
        //. state 斷路器狀態
	state      State
        // generation 是一個遞增值，至關於當前斷路器狀態切換的次數， 爲了不狀態切換後，未完成請求對新狀態的統計的影響，若是發現一個請求的generation同當前的generation不一樣，則不會進行統計計數
	generation uint64
        //  Counts 統計
	counts     Counts
        // expiry 超時過時用於open狀態到half-open狀態的切換，當超時後，會從open狀態切換到half-open狀態
	expiry     time.Time
}

核心流程

CircuitBreaker.Execute

請求執行，對外開放的請求執行接口

func (cb *CircuitBreaker) Execute(req func() (interface{}, error)) (interface{}, error) {
        // 執行請求鉤子，會根據當前狀態，來返回當前的generation和err(若是位於open和half-open則不爲nil), 經過err來進行判斷是否直接返回
	generation, err := cb.beforeRequest()
	if err != nil {
		return nil, err
	}

        // 捕獲panic，避免應用函數錯誤形成斷路器panic
	defer func() {
		e := recover()
		if e != nil {
			cb.afterRequest(generation, false)
			panic(e)
		}
	}()

    // 執行請求
	result, err := req()
        // 根據結果來進行對應狀態的統計, 同時傳遞generation
	cb.afterRequest(generation, err == nil)
	return result, err
}

CircuitBreaker.beforeRequest

func (cb *CircuitBreaker) beforeRequest() (uint64, error) {
	cb.mutex.Lock()
	defer cb.mutex.Unlock()

        // 獲取當前的狀態
	now := time.Now()
	state, generation := cb.currentState(now)

    // open和half-open狀態則直接返回
	if state == StateOpen {
		return generation, ErrOpenState
	} else if state == StateHalfOpen && cb.counts.Requests >= cb.maxRequests {
            // 避免海量請求對處於恢復服務的影響，這裏有一個限流的操做，避免請求數超過最大請求數
		return generation, ErrTooManyRequests
	}
        // 統計狀態
	cb.counts.onRequest()
	return generation, nil
}

CircuitBreaker.afterRequest

func (cb *CircuitBreaker) afterRequest(before uint64, success bool) {
	cb.mutex.Lock()
	defer cb.mutex.Unlock()

    // 從新獲取狀態
	now := time.Now()
	state, generation := cb.currentState(now)
        // 若是先後狀態不一致，則不計數
	if generation != before {
		return
	}

        // 根據狀態計數
	if success {
		cb.onSuccess(state, now)
	} else {
		cb.onFailure(state, now)
	}
}

CircuitBreaker.currentState

func (cb *CircuitBreaker) currentState(now time.Time) (State, uint64) {
	switch cb.state {
	case StateClosed:
                // 若是當前當前是closed狀態，而且有設置expiry,則遞增Generation到新一輪統計計數
		if !cb.expiry.IsZero() && cb.expiry.Before(now) {
			cb.toNewGeneration(now)
		}
	case StateOpen:
                // 若是是Open狀態，而且超時，則嘗試到半打開狀態
		if cb.expiry.Before(now) {
			cb.setState(StateHalfOpen, now)
		}
	}
	return cb.state, cb.generation
}

CircuitBreaker.toNewgeneration

func (cb *CircuitBreaker) toNewGeneration(now time.Time) {
        // 遞增generation, 清除狀態
	cb.generation++
	cb.counts.clear()

        // 設置超時時間
	var zero time.Time
	switch cb.state {
	case StateClosed:
		if cb.interval == 0 {
			cb.expiry = zero
		} else {
			cb.expiry = now.Add(cb.interval)
		}
	case StateOpen:
		cb.expiry = now.Add(cb.timeout)
	default: // StateHalfOpen
		cb.expiry = zero
	}
}

總結

斷路器黃金鍊路

• beforeRequest ：完成當前請求是否能夠執行請求，狀態超時切換，同時返回當前的genenration
• req： 執行請求
• afterRequest: 完成請求狀態統計，決定狀態切換

斷路器的優缺點

斷路器比較適合針對遠程服務或者第三方服務的調用，若是該操做極有可能會失敗，則斷路器能夠儘量的減少失敗對應用的影響，避免資源浪費

但缺點也顯而易見，斷路器自己至關於一層代理，在應用程序執行進行統計和控制，自己就有必定的資源消耗，同時內部基於synx.Mutex鎖來實現，高併發下確定會有鎖爭用問題，可能須要根據業務來使用多個斷路器，來分散這種鎖爭用，同時應該避免在斷路器req函數內，去執行重試和過長時間的超時等待，由於斷路器核心是快速失敗

更多文章能夠訪問http://www.sreguide.com/