Detaillierte Erläuterung der Verwendung und Prinzipien von hystrix-go

Die folgende Kolumne des Golang-Tutorials stellt Ihnen vor, wie Golang eine Bash-Funktion zum Ausführen der Bash-Befehlsanalyse kapselt. Ich hoffe, dass es für Freunde in Not hilfreich sein wird!

                                                        在 Zu Beginn dieser Woche wurde bei der Betrachtung eines Pakets mit interner Sicherungsbeschränkung diese Woche festgestellt, dass es auf einem Open-Source-Projekt Hystrix-GO basierte, daher enthält dieser Artikel diesen Artikel.

Hystrix

Hystrix wurde von Netflex entwickelt, einer Open Source Komponente, die grundlegende Leistungsschalterfunktionen bereitstellt. Hystrix kapselt die Downgrade-Strategie in Command und stellt zwei Methoden bereit: run und fallback. Ersteres gibt normale Logik an. B. Aufrufe zwischen Microservices ... Wenn ein Fehler auftritt, wird die Methode fallback ausgeführt, um das Ergebnis zurückzugeben. Wir können dies als garantierte Operation verstehen. Wenn die normale Logik innerhalb kurzer Zeit häufig ausfällt, kann ein Kurzschluss ausgelöst werden, d. h. nachfolgende Anforderungen führen run nicht mehr aus, sondern führen direkt fallback aus. Weitere Informationen zu Hystrix finden Sie unter https://github.com/NETFLIX/Hystrix, und hystrix-go wird verwendet code>go-Implementierung von hystrix, genauer gesagt, die vereinfachte Version. Ist es nur das letzte Update oder ein pr aus dem Jahr 2018, was bedeutet, dass Sie Ihren Abschluss gemacht haben?
Warum brauchen Sie diese Werkzeuge?

In einer Microservice-basierten Produktlinie konzentriert sich beispielsweise jeder Service auf sein eigenes Geschäft und stellt entsprechende Serviceschnittstellen zur Außenwelt bereit oder verlässt sich auf eine bestimmte logische Schnittstelle externer Services, wie unten gezeigt.

hystrix-go 实现了，因此有了这篇文章。

Hystrix

Hystrix 是由 Netflex 开发的一款开源组件，提供了基础的熔断功能。 Hystrix 将降级的策略封装在 Command 中，提供了 run 和 fallback 两个方法，前者表示正常的逻辑，比如微服务之间的调用……，如果发生了故障，再执行 fallback方法返回结果，我们可以把它理解成保底操作。如果正常逻辑在短时间内频繁发生故障，那么可能会触发短路，也就是之后的请求不再执行 run,而是直接执行  fallback。更多关于 Hystrix 的信息可以查看 https://github.com/Netflix/Hystrix，而
hystrix-go 则是用 go 实现的 hystrix 版，更确切的说，是简化版。只是上一次更新还是 2018年 的一次 pr,也就毕业了？

为什么需要这些工具？
比如一个微服务化的产品线上，每一个服务都专注于自己的业务，并对外提供相应的服务接口，或者依赖于外部服务的某个逻辑接口，就像下面这样。

假设我们当前是 服务A，有部分逻辑依赖于 服务C，服务C 又依赖于 服务E,当前微服务之间进行 rpc或者 http通信，假设此时 服务C 调用 服务E 失败,比如由于网络波动导致超时或者服务E由于过载，系统E 已经down掉了。

调用失败，一般会有失败重试等机制。但是再想想，假设服务E已然不可用的情况下，此时新的调用不断产生，同时伴随着调用等待和失败重试，会导致 服务C对服务E的调用而产生大量的积压，慢慢会耗尽服务C的资源，进而导致服务C也down掉，这样恶性循环下，会影响到整个微服务体系，产生雪崩效应。

虽然导致雪崩的发生不仅仅这一种，但是我们需要采取一定的措施，来保证不让这个噩梦发生。而 hystrix-go就很好的提供了 熔断和降级的措施。它的主要思想在于，设置一些阀值，比如最大并发数(当并发数大于设置的并发数，拦截)，错误率百分比(请求数量大于等于设置 的阀值，并且错误率达到设置的百分比时，触发熔断)以及熔断尝试恢复时间等 。

使用

hystrix-go 的使用非常简单，你可以调用它的 Go 或者 Do方法，只是 Go 方法是异步的方式。而 Do  方法是同步方式。我们从一个简单的例子开启。

_ = 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 函数需要三个参数，第一个参数 commmand 名称，你可以把每个名称当成一个独立当服务，第二个参数是处理正常的逻辑，比如 http 调用服务，返回参数是 err

Angenommen, wir sind derzeit Service A, einige Logik hängt von <code>Service C ab, Service C hängt wiederum von Service E ab und die aktuellen Microservices sind rpc - oder http-Kommunikation, vorausgesetzt, dass Dienst C zu diesem Zeitpunkt Dienst E nicht aufruft, z. B. aufgrund einer Zeitüberschreitung aufgrund von Netzwerkschwankungen oder Dienst E aufgrund einer Überlastung des Systems E ist ausgefallen.

Wenn der Anruf fehlschlägt, kommt es normalerweise zu einem fehlgeschlagener Wiederholungsversuch usw. Mechanismus. Denken Sie jedoch noch einmal darüber nach: Unter der Annahme, dass Dienst E bereits nicht verfügbar ist, werden zu diesem Zeitpunkt weiterhin neue Anrufe generiert, begleitet von wartenden Anrufen und fehlgeschlagenen Wiederholungsversuchen, was zu einem großen Rückstau an Anrufen von Dienst C zu Dienst E führt. Langsam wird die Ressourcen von Dienst C erschöpfen, was auch zum Ausfall von Dienst C führt. Dieser Teufelskreis wird sich auf das gesamte Microservice-System auswirken und einen Lawineneffekt erzeugen.

🎜🎜Obwohl dies nicht die einzige Ursache für Lawinen ist, Aber wir müssen bestimmte Maßnahmen ergreifen, um sicherzustellen, dass dieser Albtraum nicht passiert. Und hystrix-go bietet sehr gute Leistungsschalter- und Downgrade-Maßnahmen. Seine Hauptidee besteht darin, einige Schwellenwerte festzulegen, z. B. die maximale Anzahl von Parallelitäten (wenn die Anzahl der Parallelitäten größer als die festgelegte Anzahl von Parallelitäten ist, Abfangen), den Prozentsatz der Fehlerrate (wenn die Anzahl der Anforderungen größer oder gleich ist). eingestellter Schwellenwert, und die Fehlerrate erreicht den eingestellten Prozentsatz, Auslösen der Sicherung) und die Wiederherstellungszeit des Sicherungsversuchs usw. 🎜

Verwendung

🎜hystrix-go ist sehr einfach zu verwenden, Sie können seinen Go- oder Do-Methode, aber die Go-Methode ist asynchron. Die Methode Do ist synchron. Beginnen wir mit einem einfachen Beispiel. 🎜

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
    })

🎜Die Funktion Do erfordert den Namen command. Der zweite Parameter wird normal verarbeitet , wie zum Beispiel http, der den Dienst aufruft, ist der Rückgabeparameter err. Wenn der Verarbeitungsaufruf | fehlschlägt, wird die dritte Parameterlogik ausgeführt, die wir als garantierte Operation bezeichnen. Da die Dienstfehlerrate zu hoch ist und die Sicherung geöffnet ist, rufen nachfolgende Anforderungen diese Funktion auch direkt zurück. 🎜🎜Da die Sicherung gemäß den konfigurierten Regeln ein- oder ausgeschaltet wird, können wir natürlich den gewünschten Wert einstellen. 🎜

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{})}

🎜Eine kleine Erklärung zur Bedeutung der oben konfigurierten Werte:🎜

• 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="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-5.png" alt=""><br>和我们想的一样。</p><p>接着我们把网络断开，并发请求改成10次。再次运行程序并发请求 <code>8090</code> 端口，此时由于网络已关闭，导致请求百度失败：<br><img src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-6.png" alt=""><br>接着继续请求：<br><img src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-7.png" alt=""><br>熔断器已开启，上面我们配置的<code>RequestVolumeThreshold</code> 和 <code>ErrorPercentThreshold</code> 生效。</p><p>然后我们把网连上，五秒后 (<code>SleepWindow</code>的值)继续并发调用，当前熔断器处于半开的状态，此时请求允许调用依赖，如果成功则关闭，失败则继续开启熔断器。<br><img src="https://img.php.cn/upload/article/000/000/020/a47bae3dcfa1730bb3b1136eddb4f59b-8.png" alt=""><br>可以看到，有一个成功了，那么此时熔断器已关闭，接下来继续运行函数并发调用：<br><img src="https://img.php.cn/upload/article/000/000/020/24be5795ca6d697af3d1d7ffdfdafc03-9.png" 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语言教程栏目！                                                  

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Verwendung und Prinzipien von hystrix-go. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!