Detailed explanation of hystrix-go usage and principles

The following columngolang tutorialwill introduce to you about golang encapsulating a bash function for executing bash command analysis. I hope it will be helpful to friends in need!

Opening

When I was looking at an internal circuit breaker current limiting package this week, I found that it was based on an open source projecthystrix-goMade it happen, hence this article.

Hystrix

Hystrixis an open source component developed byNetflex, which provides basic fusing functions.Hystrixencapsulates the downgrade strategy inCommandand provides two methods,runandfallback. The former represents normal logic, such as Calls between microservices... If a failure occurs, thefallbackmethod is executed to return the result. We can understand it as a guaranteed operation. If normal logic fails frequently in a short period of time, a short circuit may be triggered, that is, subsequent requests will no longer executerun, but directly executefallback. More information aboutHystrixcan be found athttps://github.com/NETFLIX/Hystrix, while
hystrix-gois used ## Thehystrixversion of the #goimplementation, or more precisely, the simplified version. Is it just the last update or aprin 2018, which means graduation?

Why are these tools needed?

For example, in a microservice-based product line, each service focuses on its own business and provides corresponding service interfaces to the outside world, or relies on a certain logical interface of external services, as shown below.

Suppose we are currently

service A, some logic depends onservice C,service Cin turn depends onService E, the current microservices are communicating withrpcorhttp. It is assumed thatservice Cfails to call service E at this time, such as timeout or due to network fluctuations. System E has been down due to overload of service E.

If the call fails, there will generally be mechanisms such as failure retry. But think about it again, assuming that service E is already unavailable, new calls continue to be generated at this time, accompanied by call waiting and failed retries, which will lead to a large backlog of calls from service C to service E. Slowly It will exhaust the resources of service C, which will also cause service C to go down. This vicious cycle will affect the entire microservice system and produce an avalanche effect.

Although this is not the only cause of avalanches, we need to take certain measures to ensure that this nightmare does not happen. And

hystrix-goprovides very good circuit breaker and downgrade measures. Its main idea is to set some thresholds, such as the maximum number of concurrencies (when the number of concurrencies is greater than the set number of concurrencies, intercept), error rate percentage (when the number of requests is greater than or equal to the set threshold, and the error rate reaches the set percentage, Triggering the fuse) and the fuse attempt recovery time, etc.

Usage

hystrix-gois very simple to use, you can call itsGoorDoMethod, justGomethod is asynchronous. TheDomethod is synchronous. Let's start with a simple example.

_ = hystrix.Do("wuqq", func() error { // talk to other services _, err := http.Get("https://www.baidu.com/") if err != nil { fmt.Println("get error:%v",err) return err } return nil }, func(err error) error { fmt.Printf("handle error:%v\n", err) return nil })

DoThe function requires three parameters. The first parameter iscommmandname. You can treat each name as an independent service. The second parameter is Process normal logic, such ashttpcalling the service, the return parameter iserr. If the processing | call fails, then the third parameter logic is executed, which we call a guaranteed operation. Because the service error rate is too high and the fuse is opened, subsequent requests will also directly call back this function.

Since the fuse is turned on or off according to the configured rules, of course we can set the value we want.

hystrix.ConfigureCommand("wuqq", hystrix.CommandConfig{ Timeout: int(3 * time.Second), MaxConcurrentRequests: 10, SleepWindow: 5000, RequestVolumeThreshold: 10, ErrorPercentThreshold: 30, }) _ = hystrix.Do("wuqq", func() error { // talk to other services _, err := http.Get("https://www.baidu.com/") if err != nil { fmt.Println("get error:%v",err) return err } return nil }, func(err error) error { fmt.Printf("handle error:%v\n", err) return nil })

Let’s briefly explain the meaning of the values configured above:

• Timeout: 执行command的超时时间。
• MaxConcurrentRequests：command的最大并发量 。
• SleepWindow：当熔断器被打开后，SleepWindow的时间就是控制过多久后去尝试服务是否可用了。
• RequestVolumeThreshold： 一个统计窗口10秒内请求数量。达到这个请求数量后才去判断是否要开启熔断
• ErrorPercentThreshold：错误百分比，请求数量大于等于RequestVolumeThreshold并且错误率到达这个百分比后就会启动熔断

当然你不设置的话，那么自动走的默认值。

我们再来看一个简单的例子:

package mainimport ( "fmt" "github.com/afex/hystrix-go/hystrix" "net/http" "time")type Handle struct{}func (h *Handle) ServeHTTP(r http.ResponseWriter, request *http.Request) { h.Common(r, request)}func (h *Handle) Common(r http.ResponseWriter, request *http.Request) { hystrix.ConfigureCommand("mycommand", hystrix.CommandConfig{ Timeout: int(3 * time.Second), MaxConcurrentRequests: 10, SleepWindow: 5000, RequestVolumeThreshold: 20, ErrorPercentThreshold: 30, }) msg := "success" _ = hystrix.Do("mycommand", func() error { _, err := http.Get("https://www.baidu.com") if err != nil { fmt.Printf("请求失败:%v", err) return err } return nil }, func(err error) error { fmt.Printf("handle error:%v\n", err) msg = "error" return nil }) r.Write([]byte(msg))}func main() { http.ListenAndServe(":8090", &Handle{})}

我们开启了一个http服务，监听端口号8090，所有请求的处理逻辑都在Common方法中，在这个方法中，我们主要是发起一次http请求，请求成功响应success,如果失败，响应失败原因。

我们再写另一个简单程序，并发11次的请求8090端口。

package mainimport ( "fmt" "io/ioutil" "net/http" "sync" "time")var client *http.Clientfunc init() { tr := &http.Transport{ MaxIdleConns: 100, IdleConnTimeout: 1 * time.Second, } client = &http.Client{Transport: tr}}type info struct { Data interface{} `json:"data"`}func main() { var wg sync.WaitGroup for i := 0; i 
由于我们配置 MaxConcurrentRequests 为10，那么意味着还有个 g 请求会失败:

和我们想的一样。
接着我们把网络断开，并发请求改成10次。再次运行程序并发请求 8090 端口，此时由于网络已关闭，导致请求百度失败：

接着继续请求：

熔断器已开启，上面我们配置的RequestVolumeThreshold 和 ErrorPercentThreshold 生效。
然后我们把网连上，五秒后 (SleepWindow的值)继续并发调用，当前熔断器处于半开的状态，此时请求允许调用依赖，如果成功则关闭，失败则继续开启熔断器。

可以看到，有一个成功了，那么此时熔断器已关闭，接下来继续运行函数并发调用：

可以看到，10个都已经是正常成功的状态了。
那么问题来了，为什么最上面的图只有一个是成功的？5秒已经过了，并且当前网络正常，应该是10个请求都成功，但是我们看到的只有一个是成功状态。通过源码我们可以找到答案:
具体逻辑在判断当前请求是否可以调用依赖
if !cmd.circuit.AllowRequest() { ...... return }
      
func (circuit *CircuitBreaker) AllowRequest() bool { return !circuit.IsOpen() || circuit.allowSingleTest()}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}
      
这段代码首先判断了熔断器是否开启，并且当前时间大于 上一次开启熔断器的时间+SleepWindow的时间，如果条件都符合的话，更新此熔断器最新的openedOrLastTestedTime,是通过CompareAndSwapInt64原子操作完成的，意外着必然只会有一个成功。
此时熔断器还是半开的状态，接着如果能拿到令牌，执行run函数（也就是Do传入的第二个简单封装后的函数），发起http请求，如果成功，上报成功状态，关闭熔断器。如果失败，那么熔断器依旧开启。

      

      
以上就是大体的流程讲解，下一篇文章将解读核心源码以及进一步当思考。
      
更多相关技术文章，请访问go语言教程栏目！
      
The above is the detailed content of Detailed explanation of hystrix-go usage and principles. For more information, please follow other related articles on the PHP Chinese website!