De nos jours, il est assez courant que notre application dépende des autres, surtout si nous travaillons dans un environnement de microservices. Il est assez courant que notre application commence à signaler des erreurs, et lors de l'enquête, nous remarquons qu'une API d'une équipe partenaire ou d'un fournisseur est en panne.

Une bonne pratique pour augmenter la résilience de notre application consiste à couper la communication avec les applications qui sont dans un état obsolète. En observant d'autres domaines, nous absorbons le concept de disjoncteur du génie électrique. Un équipement, ou disjoncteur, y est placé, qui s'éteint automatiquement en cas de panne. C'est très courant dans nos maisons, qui disposent de disjoncteurs qui s'éteignent tout seuls si le réseau électrique commence à devenir instable.

En informatique, notre Disjoncteur est un peu plus complexe, puisque nous définissons également un état intermédiaire. Le dessin ci-dessous explique mieux le fonctionnement d'un disjoncteur :

Enfin, les états sont :

• ouvert : il n’y a pas de communication entre les applications. Une fois cet état atteint, une minuterie démarre pour accorder du temps au service de réinitialisation. À la fin du chronomètre, nous passons en semi-ouverture.
• fermé : il y a une communication entre les applications. Pour chaque requête ayant échoué, un compteur est mis à jour. Si la limite de défaillance est atteinte, nous passons le circuit à l'ouverture.
• semi-ouvert : état de récupération jusqu'à ce que la communication puisse s'écouler complètement. Dans celui-ci, un compteur de réussite est mis à jour à chaque demande. Si le nombre idéal de réussites est atteint, on passe le circuit en fermé. Si les demandes échouent, nous revenons à l'ouverture.

Plutôt cool, non ? Mais pour mieux illustrer le concept, que diriez-vous de le mettre en pratique ?

Tout d'abord, construisons notre service A. Il sera responsable de la réception des demandes, c'est-à-dire que ce sera le service dont dépend notre application, le service du fournisseur, etc. Pour faciliter les choses, nous exposerons deux points de terminaison, un /success qui renverra toujours 200 et un /failure qui renverra toujours 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))
}

Le service B se chargera d'appeler le service A. Il construira notre disjoncteur. Heureusement pour nous, la communauté Go possède déjà la bibliothèque gobreaker qui implémente le modèle ! Tout d'abord, nous définissons les propriétés de notre 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
}

Bien que la bibliothèque nous permette de personnaliser davantage de choses, nous nous concentrerons sur trois :

• Timeout : le temps pendant lequel le circuit restera à l'état ouvert. Dans notre cas, le temps a été fixé à 5 secondes.
• MaxRequests : nombre de demandes réussies avant d'être fermées. Dans notre exemple, nous le définissons comme 2 requêtes.
• ReadyToTrip : définit la condition de transition de fermé à ouvert. Pour simplifier les choses, disons qu'un seul échec suffit.

Ensuite, nous pouvons initialiser le disjoncteur et faire des 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!

Nous pouvons remarquer que gobreaker fonctionne comme un wrapper autour d'une fonction. Si la fonction renvoie une erreur, elle augmente le nombre d'erreurs, sinon, elle augmente le nombre de réussites. Définissons donc 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 nous avons notre service Go utilisant un disjoncteur ! En utilisant ce modèle, vous pouvez augmenter la résilience et la tolérance aux pannes de vos services. Nous pouvons remarquer que lors de l'utilisation de la bibliothèque, la complexité était complètement abstraite, ce qui rendait très simple le processus d'intégration dans notre vie quotidienne. Si vous souhaitez voir l'intégralité du code de la preuve de concept, allez simplement ici.

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

Dites-moi ce que vous pensez de ce post dans les commentaires et voici une question : avez-vous déjà utilisé des disjoncteurs auparavant ? Oh, vous pouvez aussi me retrouver sur mon blog personnel !