Detailed explanation of hystrix-go usage and principles

The following column golang tutorial will 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-go Made it happen, hence this article.

Hystrix

Hystrix is an open source component developed by Netflex, which provides basic fusing functions. Hystrix encapsulates the downgrade strategy in Command and provides two methods, run and fallback. The former represents normal logic, such as Calls between microservices... If a failure occurs, the fallback method 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 execute run, but directly execute fallback. More information about Hystrix can be found at https://github.com/NETFLIX/Hystrix, while
hystrix-go is used ## The hystrix version of the #go implementation, or more precisely, the simplified version. Is it just the last update or a pr in 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 on service C, service C in turn depends on Service E, the current microservices are communicating with rpc or http. It is assumed that service C fails 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-go provides 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-go is very simple to use, you can call its Go or Do Method, just Go method is asynchronous. The Do method 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
    })

Do The function requires three parameters. The first parameter is commmand name. You can treat each name as an independent service. The second parameter is Process normal logic, such as http calling the service, the return parameter is err. 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 <p>由于我们配置 <code>MaxConcurrentRequests</code> 为10，那么意味着还有个 g 请求会失败:<br><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-5.png?x-oss-process=image/resize,p_40" class="lazy" alt=""><br>和我们想的一样。</p><p>接着我们把网络断开，并发请求改成10次。再次运行程序并发请求 <code>8090</code> 端口，此时由于网络已关闭，导致请求百度失败：<br><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-6.png?x-oss-process=image/resize,p_40" class="lazy" alt=""><br>接着继续请求：<br><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-7.png?x-oss-process=image/resize,p_40" class="lazy" alt=""><br>熔断器已开启，上面我们配置的<code>RequestVolumeThreshold</code> 和 <code>ErrorPercentThreshold</code> 生效。</p><p>然后我们把网连上，五秒后 (<code>SleepWindow</code>的值)继续并发调用，当前熔断器处于半开的状态，此时请求允许调用依赖，如果成功则关闭，失败则继续开启熔断器。<br><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-8.png?x-oss-process=image/resize,p_40" class="lazy" alt=""><br>可以看到，有一个成功了，那么此时熔断器已关闭，接下来继续运行函数并发调用：<br><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/020/24be5795ca6d697af3d1d7ffdfdafc03-9.png?x-oss-process=image/resize,p_40" class="lazy" alt=""><br>可以看到，10个都已经是正常成功的状态了。</p><p>那么问题来了，为什么最上面的图只有一个是成功的？5秒已经过了，并且当前网络正常，应该是10个请求都成功，但是我们看到的只有一个是成功状态。通过源码我们可以找到答案:<br>具体逻辑在判断当前请求是否可以调用依赖</p><pre class="brush:php;toolbar:false">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!