状态统计-计数器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状态下不会清除Countsinterval      time.Duration// timeout进入open状态下，多长时间切换到half-open状态，默认60stimeout       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，避免应用函数错误造成断路器panicdefer func() {e := recover()if e != nil {cb.afterRequest(generation, false)panic(e)}}()// 执行请求result, err := req()// 根据结果来进行对应状态的统计, 同时传递generationcb.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.Timeswitch 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: // StateHalfOpencb.expiry = zero}
}

总结

断路器黄金链路

• beforeRequest ：完成当前请求是否可以执行请求，状态超时切换，同时返回当前的genenration
• req： 执行请求
• afterRequest: 完成请求状态统计，决定状态切换

断路器的优缺点

断路器比较适合针对远程服务或者第三方服务的调用，如果该操作极有可能会失败，则断路器可以尽可能的减小失败对应用的影响，避免资源浪费

但缺点也显而易见，断路器本身相当于一层代理，在应用程序执行进行统计和控制，本身就有一定的资源消耗，同时内部基于synx.Mutex锁来实现，高并发下肯定会有锁争用问题，可能需要根据业务来使用多个断路器，来分散这种锁争用，同时应该避免在断路器req函数内，去执行重试和过长时间的超时等待，因为断路器核心是快速失败