golang hystrix 熔断器

golang hystrix 熔断器

熔断器是为了保护被调方健康的一种方式。通过错误率,超时,并发等机制来使第三方处于一个健康且提供性能最佳的方式。hystrix 是比较通用的熔断器库。以下为介绍该熔断器源码以及处理思想。

核心思想

先看看需要配置什么参数,都是从参数玩出的花。

  • Timeout: 执行command的超时时间。默认时间是1000毫秒
  • MaxConcurrentRequests:command的最大并发量 默认值是10
  • SleepWindow:当熔断器被打开后,SleepWindow的时间就是控制过多久后去尝试服务是否可用了。默认值是5000毫秒
  • RequestVolumeThreshold: 一个统计窗口10秒内请求数量。达到这个请求数量后才去判断是否要开启熔断。默认值是20
  • ErrorPercentThreshold:错误百分比,请求数量大于等于RequestVolumeThreshold并且错误率到达这个百分比后就会启动熔断 默认值是50
    当然如果不配置他们,会使用默认值

通过配置参数我们就可以了解到他大致提供了这些功能。

功能模块

配置模块

通过以下代码注册name 为mycommand 的熔断器配置。

hystrix.ConfigureCommand("mycommand", hystrix.CommandConfig{
		Timeout:                int(time.Second * 3),
		MaxConcurrentRequests:  100,
		SleepWindow:            int(time.Second * 5),
		RequestVolumeThreshold: 30,
		ErrorPercentThreshold: 50,
	})

统计模块

为了实现熔断判断就必须要统计一定时间内的成功失败请求,这次采用了10s 的桶形式进行统计。在每次更新时都会删除时间大于10s 的桶。时间戳就是key。这里不够灵活 桶的大小也应该提供可选和默认参数让调用方选择

type DefaultMetricCollector struct {
	mutex *sync.RWMutex

	numRequests *rolling.Number
	errors      *rolling.Number

	successes               *rolling.Number
	failures                *rolling.Number
	rejects                 *rolling.Number
	shortCircuits           *rolling.Number
	timeouts                *rolling.Number
	contextCanceled         *rolling.Number
	contextDeadlineExceeded *rolling.Number

	fallbackSuccesses *rolling.Number
	fallbackFailures  *rolling.Number
	totalDuration     *rolling.Timing
	runDuration       *rolling.Timing
}

上报模块

上报模块 非主流程,没有太关注。这里应该开放给客户端,如果客户端需要监控,或者有其他上报机制,提供接口更为合适。

流量控制

采用令牌算法,拿到令牌开始工作,执行完成返回令牌。等不到令牌时返回maxconcurent。

熔断开关控制

熔断器状态判断

当请求数量大于 统计桶内(10s 间隔)的 大于 RequestVolumeThreshold 并且错误率大于 ErrorPercentThreshold 时熔断器打开。

func (circuit *CircuitBreaker) IsOpen() bool {
	circuit.mutex.RLock()
	o := circuit.forceOpen || circuit.open
	circuit.mutex.RUnlock()

	if o {
		return true
	}

	if uint64(circuit.metrics.Requests().Sum(time.Now())) < getSettings(circuit.Name).RequestVolumeThreshold {
		return false
	}

	if !circuit.metrics.IsHealthy(time.Now()) {
		// too many failures, open the circuit
		circuit.setOpen()
		return true
	}

	return false
}

熔断器关闭

打开熔断器的判断比较明显,那么何时去关闭熔断器,什么去触发就比较关键了。

关键代码是set close。向上追溯,看到在统计的时候只要success 就会去打来熔断器。那么问题来了,多久才会去尝试调用呢?

func (circuit *CircuitBreaker) setClose() {
	circuit.mutex.Lock()
	defer circuit.mutex.Unlock()

	if !circuit.open {
		return
	}

	log.Printf("hystrix-go: closing circuit %v", circuit.Name)

	circuit.open = false
	circuit.metrics.Reset()
}

sleep window

判断是否能请求是这个函数,显然现在的情形是open 所以,allowSingleTest 为true 时就可以发送请求。

func (circuit *CircuitBreaker) AllowRequest() bool {
	return !circuit.IsOpen() || circuit.allowSingleTest()
}

可以看到当过了sleep window 时间窗口的时候就会有一次机会去调用。这里没看明白加了锁又用了CompareAndSwapInt64 是个什么骚操作。仔细一看这是个R Lock,额差点去提issue。

func (circuit *CircuitBreaker) allowSingleTest() bool {
	circuit.mutex.RLock()
	defer circuit.mutex.RUnlock()

	now := time.Now().UnixNano()
	openedOrLastTestedTime := atomic.LoadInt64(&circuit.openedOrLastTestedTime)
	if circuit.open && now > openedOrLastTestedTime+getSettings(circuit.Name).SleepWindow.Nanoseconds() {
		swapped := atomic.CompareAndSwapInt64(&circuit.openedOrLastTestedTime, openedOrLastTestedTime, now)
		if swapped {
			log.Printf("hystrix-go: allowing single test to possibly close circuit %v", circuit.Name)
		}
		return swapped
	}

	return false
}

如果是这样 在并发的情况没有严格的时间顺序,第一个可能成功,第二个还是可能失败。

热加载的坑

项目上对第三方调用较多,就需要使用代理模式来扩展以维持稳定性。当然针对第三方不稳定的状态,在运行时肯定是会去调整熔断等机制的。这时候就需要热加载了。在使用过程中发现修改了配置并没有使用新的配置,但是从GetCircuitSettings 函数返回的配置确实是最新的。源码之下无秘密。那就只能上源码看了。

原来源码中区分了 circuitSettings 和 circuitBreakers。这两个都是以全局变量的形式维护。但是 circuitBreakers 在初始化时会读取circuitSettings 的配置 new 一个实例出来。后面去更新只会更新到circuitSettings,读取配置也是从circuitSettings中读取,而circuitBreakers没有被改变,实际运行的正是circuitBreakers 导致最后没有生效。

最终看到这个函数可以刷掉数据,删除circuitBreakers 所有配置,再重新加载。在我看来这边应该在创建新的之后从settings new 一个对象更新的circuitBreakers更为合适。

发布了99 篇原创文章 · 获赞 28 · 访问量 7万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览