Disjoncteur dans les applications Go

Aujourd'hui, il est courant que nos applications aient quelques dépendances, en particulier lorsque nous travaillons dans un environnement de microservices. Il n'est pas rare que lorsque notre application signale des erreurs, nous découvrons qu'une dépendance est en panne.

Une bonne pratique pour améliorer notre résilience consiste à couper la communication avec les applications qui ne se comportent pas bien. En examinant d'autres domaines, nous avons appris le concept des disjoncteurs en génie électrique, où un interrupteur s'éteint en cas de panne. Au Brésil, toutes les maisons sont équipées de ces interrupteurs qui s'éteignent automatiquement si notre réseau électrique devient instable.

En informatique, notre disjoncteur est un peu plus complexe car il possède également un état intermédiaire. Le dessin ci-dessous explique plus en détail son fonctionnement :

En bref, les états possibles sont :

• ouvert : il n'y a pas de communication entre les applications. Lorsque cet état est atteint, un timer démarre, permettant à la dépendance de se rétablir. Lorsque le chronomètre se termine, nous passons en semi-ouverture.
• fermé : il y a une communication entre les applications. A chaque requête effectuée avec des échecs, un compteur est mis à jour. Si nous atteignons le seuil de défaillance, nous déplaçons le circuit en ouverture.
• à moitié ouvert : c'est un état de guérison jusqu'à ce que nous puissions travailler comme d'habitude. Pendant que nous y sommes, si nous atteignons le seuil de réussite, nous passons en mode fermé. Si les demandes continuent d'échouer, nous revenons à l'ouverture.

Plutôt cool, non ? Pour mieux expliquer le concept, pourquoi ne pas en créer un ?

Tout d'abord, construisons notre service A. Il sera chargé de recevoir toutes les demandes, en d'autres termes, ce sera le service dont dépend notre application principale. Pour simplifier, nous exposerons deux points finaux : un /success qui répondra toujours par 200 et le /failure qui répondra toujours par 500.

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/success", func(w http.ResponseWriter, r *http.Request) { 
    w.WriteHeader(http.StatusOK) })
    http.HandleFunc("/failure", func(w http.ResponseWriter, r *http.Request) { 
    w.WriteHeader(http.StatusInternalServerError) })

    fmt.Println("Server is running at http://localhost:8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Notre service B se chargera d'appeler le service A et construira notre disjoncteur. La communauté Go dispose déjà de la lib gobreaker qui implémente déjà le modèle. Tout d'abord, nous définissons nos propriétés de disjoncteur :

var st gobreaker.Settings
st.Name = "Circuit Breaker PoC"
st.Timeout = time.Second * 5
st.MaxRequests = 2
st.ReadyToTrip = func(counts gobreaker.Counts) bool {
    return counts.ConsecutiveFailures >= 1
}

Même si la lib nous permet de personnaliser plus de propriétés, nous nous concentrerons sur seulement trois :

• Timeout : combien de temps il restera à l'état ouvert. Dans cet exemple, nous choisissons cinq secondes.
• MaxRequests : combien de demandes réussies avant qu'elles ne soient fermées. Dans cet exemple, nous avons décidé de deux demandes.
• ReadyToTrip : définit la condition pour passer de fermé à ouvert. En simplifiant, un seul échec suffira.

Maintenant, nous lançons simplement le disjoncteur et envoyons les requêtes :

cb := gobreaker.NewCircuitBreaker[int](st)

url := "http://localhost:8080/success"
cb.Execute(func() (int, error) { return Get(url) })
fmt.Println("Circuit Breaker state:", cb.State()) // closed!

url = "http://localhost:8080/failure"
cb.Execute(func() (int, error) { return Get(url) })
fmt.Println("Circuit Breaker state:", cb.State()) // open!

time.Sleep(time.Second * 6)
url = "http://localhost:8080/success"
cb.Execute(func() (int, error) { return Get(url) })
fmt.Println("Circuit Breaker state:", cb.State()) // half-open!

url = "http://localhost:8080/success"
cb.Execute(func() (int, error) { return Get(url) })
fmt.Println("Circuit Breaker state:", cb.State()) // closed!

On peut remarquer que gobreaker fonctionne comme un wrapper autour d'une fonction. Si la fonction renvoie une erreur, elle augmentera le compteur d'échecs, et sinon, elle augmentera le compteur de réussite. Définissons cette fonction :

func Get(url string) (int, error) {
    r, _ := http.Get(url)

    if r.StatusCode != http.StatusOK {
        return r.StatusCode, fmt.Errorf("failed to get %s", url)
    }

    return r.StatusCode, nil
}

Et c'est comme ça qu'on peut avoir une application Go avec un disjoncteur ! Lorsque vous utilisez ce modèle, vous pouvez augmenter la résilience de votre application en la rendant plus tolérante aux échecs de vos dépendances. De plus, l'utilisation de cette bibliothèque a supprimé l'essentiel de la complexité, facilitant ainsi l'adoption du modèle dans nos applications quotidiennes. Si vous souhaitez voir le code de cette preuve de concept, vérifiez-le ici.

Si vous êtes toujours curieux de connaître d'autres modèles de résilience, Elton Minetto a également publié un excellent article de blog à ce sujet !

Vous pouvez également consulter ceci et d’autres articles sur mon blog personnel. Dites-moi ce que vous pensez de cet article de blog dans les commentaires et une question : avez-vous déjà utilisé des disjoncteurs auparavant ?

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!