Explication détaillée de l'utilisation et des principes de Hystrix-Go

La colonne suivante du tutoriel golang vous présentera l'encapsulation par golang d'une fonction bash pour exécuter l'analyse des commandes bash. J'espère que cela sera utile aux amis dans le besoin !

                                                     

Ouverture

Lorsque j'ai examiné un package de limitation de courant de disjoncteur interne cette semaine, j'ai découvert qu'il était implémenté sur la base d'un projet open source hystrix-go, il y a donc cet article.

Hystrix

Hystrix est un composant open source développé par Netflex qui fournit une fonctionnalité de base de disjoncteur. Hystrix encapsule la stratégie de rétrogradation dans Command et fournit deux méthodes : run et fallback. La première représente la logique normale, comme les appels entre microservices... Si un échec se produit, exécutez la méthode fallback. renvoie un résultat, que nous pouvons comprendre comme une opération garantie. Si la logique normale échoue fréquemment sur une courte période de temps, un court-circuit peut être déclenché, c'est-à-dire que les requêtes suivantes ne s'exécuteront plus run, mais s'exécuteront directement fallback. Plus d'informations sur Hystrix peuvent être trouvées dans https://github.com/Netflix/Hystrix, et
hystrix-go est la version go implémentée à l'aide de hystrix, ou plus précisément, une version simplifiée. Est-ce juste que la dernière mise à jour date de 2018 pr, ça veut dire que tu as obtenu ton diplôme ?

Pourquoi avez-vous besoin de ces outils ?
Par exemple, dans une gamme de produits basée sur des microservices, chaque service se concentre sur sa propre activité et fournit les interfaces de service correspondantes avec le monde extérieur, ou s'appuie sur une certaine interface logique de services externes, comme indiqué ci-dessous.

Supposons que nous soyons actuellement 服务A, une certaine logique dépend de 服务C, 服务C dépend à son tour de 服务E, et les microservices actuels sont rpc ou http Communication, en supposant que 服务C ne parvient pas à appeler le service E à ce moment-là, comme un délai d'attente dû à des fluctuations du réseau ou un service E dû à une surcharge, le système E est en panne.

Si l'appel échoue, il y aura généralement des mécanismes tels qu'une nouvelle tentative d'échec. Mais réfléchissez-y à nouveau, en supposant que le service E soit déjà indisponible, de nouveaux appels continuent d'être générés à ce moment-là, accompagnés d'appels en attente et de tentatives infructueuses, ce qui entraînera un important retard d'appels du service C vers le service E. épuisera les ressources du service C, ce qui entraînera également une panne du service C. Ce cercle vicieux affectera l'ensemble du système de microservices et produira un effet d'avalanche.

Bien que ce ne soit pas la seule cause des avalanches, nous devons prendre certaines mesures pour garantir que ce cauchemar ne se produise pas. Et hystrix-go fournit de très bonnes mesures de disjoncteur et de déclassement. Son idée principale est de fixer certains seuils, tels que le nombre maximum de simultanéités (lorsque le nombre de simultanéités est supérieur au nombre défini de simultanéités, interception), le pourcentage de taux d'erreur (lorsque le nombre de requêtes est supérieur ou égal au définir le seuil et le taux d'erreur atteint le pourcentage défini, le déclenchement du fusible) et le temps de récupération de la tentative de fusible, etc.

L'utilisation de

hystrix-go est très simple. Vous pouvez appeler sa méthode Go ou Do, mais la méthode Go est asynchrone. La méthode Do est synchrone. Commençons par un exemple simple.

_ = 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 La fonction nécessite trois paramètres. Le premier paramètre est commmand name Vous pouvez traiter chaque nom comme un service indépendant. Le deuxième paramètre consiste à gérer la logique normale, telle que http Call. le service, le paramètre de retour est err. Si l'appel de traitement | échoue, alors la troisième logique de paramètre est exécutée, que nous appelons une opération garantie. Parce que le taux d'erreur de service est trop élevé et que le fusible est ouvert, les requêtes ultérieures rappelleront également directement cette fonction.

Puisque le fusible est activé ou désactivé selon les règles configurées, nous pouvons bien sûr définir la valeur que nous voulons.

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

Une petite explication sur la signification des valeurs configurées ci-dessus :

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!