Tutoriel Go

Arrêt propre serveur Go : Maîtriser le shut down des API

Dans le monde des microservices et des API Go modernes, garantir la fiabilité opérationnelle est fondamental. L’arrêt propre serveur Go n’est pas un simple luxe, c’est une nécessité pour prévenir la perte de données, assurer l’intégrité des transactions en cours et garantir une expérience utilisateur fluide lors d’un déploiement ou d’une maintenance. Cet article est conçu pour les développeurs Go intermédiaires à avancés qui souhaitent transformer leurs services Go en systèmes robustes, capables de gérer leur décommissionnement avec grâce et élégance.

Un serveur qui s’arrête brusquement, par un simple SIGKILL, laisse souvent des connexions ouvertes, des tâches en attente ou des états non synchronisés, menant à des comportements imprévus et des difficultés de débogage. Le concept d’arrêt propre serveur Go nous permet de capturer des signaux système (comme SIGINT ou SIGTERM) et d’exécuter une séquence de nettoyage contrôlée. C’est un passage de la simple fonctionnalité à la robustesse architecturale, pilier de tout système distribué moderne.

Pour réussir cette transition, nous allons explorer en profondeur les mécanismes sous-jacents de l’arrêt propre. Nous commencerons par les prérequis techniques pour mettre en place ce pattern, avant de plonger dans la théorie des contextes et des signaux en Go. Ensuite, nous verrons des exemples de code complets, allant du serveur HTTP basique au système de pool de travailleurs drainé. Enfin, nous couvrirons des cas d’usage avancés (gRPC, bases de données) et les meilleures pratiques pour que votre code ne gère pas seulement le lancement, mais aussi l’extinction de manière parfaitement maîtrisée. Préparez-vous à rendre vos services Go véritablement resilient !

🛠️ Prérequis

Maîtriser l’art de l’arrêt propre nécessite de solides fondations en Go. Voici les prérequis techniques pour commencer ce voyage :

Compétences linguistiques et conceptuelles

Go Basics: Bonne compréhension des goroutines, des channels et de la gestion des erreurs.
Networking: Connaissance des cycles de vie des connexions HTTP et des principes de fonctionnement des services RESTful.
Systèmes d’exploitation: Compréhension des signaux UNIX (SIGTERM, SIGINT) et du concept de signalisation au niveau du processus.

Il est recommandé d’utiliser la dernière version stable de Go (actuellement 1.22+). Pour l’installation, suivez ces étapes exactes :

Téléchargement: Assurez-vous d’avoir installé les dépendances de votre système (git, etc.).
Installation Go: Lancez « go install golang.org/x/net/context » et assurez-vous que votre GOPATH est correctement configuré dans votre environnement.
Librairies: Nous utiliserons principalement des packages standards comme « net/http », « os », « os/signal », et « context ». Aucune librairie tierce n’est strictement nécessaire pour la base, mais le package « golang.org/x/net/context » est essentiel pour la bonne gestion des contextes.

📚 Comprendre arrêt propre serveur Go

Comprendre l’arrêt propre serveur Go, ce n’est pas seulement exécuter un os.Exit(0). Il s’agit de gérer l’état du système en transition. Lorsque l’on parle de démantèlement d’un service, l’analogie la plus pertinente est celle d’un grand restaurant : si le restaurant reçoit le signal de fermeture (SIGTERM), il ne ferme pas immédiatement la porte. Il envoie d’abord un message à la cuisine (le pool de workers), lui disant de finir les plats en cours. Il met les serveurs en mode « dernière commande » (accepting no new requests), et ne relâche ses tables qu’une fois toutes les tâches terminées.

Le rôle des contextes dans l’arrêt propre serveur Go

En Go, le package context.Context est le mécanisme par excellence pour propager l’état d’annulation (cancellation) et les délais d’expiration (timeouts). C’est le cœur du mécanisme d’un arrêt propre serveur Go. Un context agit comme un fil d’Ariane qui indique à tous les goroutines enfants : « Attention, nous fermons, vous devez terminer ce que vous faites. »

Sans le contexte, un goroutine exécutant une tâche réseau ou un traitement intensif pourrait continuer indéfiniment après la réception du signal de fermeture, provoquant des fuites de ressources (goroutine leaks) et des comportements imprévisibles. Le contexte permet de « délimiter » ces tâches. On passe d’une gestion réactive des signaux à une gestion proactive de l’état interne du programme.

Comparons cela avec d’autres langages : en Java, cela pourrait nécessiter l’utilisation de l’API ExecutorService avec des mécanismes de shutdown() et awaitTermination(). En Python, on dépendrait souvent des signal handlers combinés à des mécanismes de threading.Event. Go, grâce à son modèle de concurrence et au contexte, offre un modèle particulièrement élégant et performant pour garantir un véritable arrêt propre serveur Go. Le mécanisme clé est de : 1) Écouter les signaux ; 2) Créer un contexte avec un délai d’annulation ; 3) Utiliser ce contexte pour annuler les requêtes entrantes et signaler l’arrêt aux travailleurs.

🐹 Le code — arrêt propre serveur Go

package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"
)

// handler simule une tâche qui doit réagir à l'annulation du contexte.
func handler(w http.ResponseWriter, r *http.Request) {
	// Utilisation du contexte de la requête pour la réactivité
	ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)
	defer cancel()

	select {
	case <-time.After(10 * time.Second): // Simule une opération longue
		fmt.Fprintf(w, "Opération terminée trop tard (exceeded timeout)")
	case <-ctx.Done(): // Réagit au timeout ou à l'annulation
		fmt.Fprintf(w, "Rejeté: Connexion coupée ou timeout détecté.")
	}
}

func main() {
	// 1. Configuration du serveur HTTP
	http.HandleFunc("/", handler)
	server := &http.Server{
		Addr: "localhost:8080",
		Handler: http.DefaultServeMux,
	}

	// 2. Création du canal pour les signaux OS (SIGINT, SIGTERM)
	stop := make(chan os.Signal(), 1)
	signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM)

	// 3. Lancement du serveur en tant que goroutine	go func() {
		log.Printf("🚀 Serveur démarré sur http://localhost:8080")
		err := server.ListenAndServe() // Bloque l'exécution
		if err != http.ErrServerClosed { // Gère les erreurs non liées à l'arrêt voulu		log.Fatalf("Erreur serveur: %v", err)
		}
	}()

	// 4. Blocage sur le canal des signaux
	<-stop
	log.Println("✅ Signal de fermeture reçu. Début de l'arrêt propre serveur Go...")

	// 5. Création d'un contexte de timeout pour l'arrêt lui-même
	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()

	// 6. Exécution de l'arrêt propre
	if err := server.Shutdown(ctx); err != nil {
		log.Fatalf("Erreur lors de l'arrêt propre serveur Go: %v", err)
	}
	log.Println("🚪 Serveur déconnecté avec succès. Shutdown terminé.")
}

📖 Explication détaillée

L’analyse de ce code de base est cruciale pour maîtriser l’arrêt propre serveur Go. Nous devons comprendre que l’objectif n’est pas de faire planter le programme, mais de le faire ralentir de manière contrôlée et ordonnée.

Analyse du cycle de vie du serveur et du signal handling

Le cœur du mécanisme repose sur trois éléments principaux : le serveur HTTP, le canal de signaux OS et le contexte de shutdown.

Setup (Variables globales et net/http): L’utilisation de http.HandleFunc et la création de l’objet http.Server permettent de centraliser la configuration du serveur. Ceci est une bonne pratique car cela nous donne accès à la méthode server.Shutdown(ctx), qui est le point d’entrée de notre arrêt propre serveur Go.
Gestion des Signaux OS: L’appel à signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM) écoute passivement les signaux de terminaison envoyés par l’OS (Ctrl+C ou kill). Lorsque le signal arrive, l’exécution continue le code après <-stop.
Le Contexte de Shutdown: L'utilisation de context.WithTimeout(context.Background(), 5*time.Second) est le mécanisme de sécurité. Il définit une fenêtre maximale (ici 5 secondes) pendant laquelle le serveur tentera de se déconnecter. Si, après ce délai, des connexions persistent, l'arrêt sera forcé (mais contrôlé) par le timeout du contexte.
Le Shutdown proprement dit: La fonction server.Shutdown(ctx) est magique. Elle ne coupe pas brutalement les connexions ; elle notifie le serveur qu'il doit arrêter d'accepter de nouvelles requêtes, tout en laissant le temps aux requêtes déjà entrantes de se terminer.

Pour le handler, nous utilisons context.WithTimeout(r.Context(), 5*time.Second). Ceci est une défense en profondeur : même si le shutdown du serveur est en cours, nous forçons la requête elle-même à ne pas traîner indéfiniment, assurant ainsi une meilleure réactivité de l'API. En somme, ce code illustre le pipeline idéal pour un arrêt propre serveur Go, combinant le signal OS, le timeout global et le contexte au niveau de la requête.

📖 Ressource officielle : Documentation Go — arrêt propre serveur Go

🔄 Second exemple — arrêt propre serveur Go

package main

import (
	"context"
	"fmt"
	"sync"
	"time"
)

// WorkerPool simule un pool de travailleurs qui doivent être drainés.
type WorkerPool struct {
	wg sync.WaitGroup
	activeWorkers chan struct{}
}

func NewWorkerPool(size int) *WorkerPool {
	return &WorkerPool{
		activeWorkers: make(chan struct{}, size),
	}
}

func (wp *WorkerPool) StartWorker(id int, ctx context.Context) {
	defer wp.wg.Done()
	
	fmt.Printf("Worker %d démarré.")
	
	// Simulation de travail qui doit s'arrêter proprement
	select {
	case <-time.After(5 * time.Second): 
		fmt.Printf(" Worker %d terminé son cycle de travail normal.\n", id)
	case <-ctx.Done(): 
		// Ce bloc est exécuté lorsque le contexte est annulé		fmt.Printf(" Worker %d interrompu proprement grâce au contexte. Motif: %v\n", id, ctx.Err())
	}
}

// GracefulShutdownWorkerPool tente de terminer toutes les tâches.
func (wp *WorkerPool) GracefulShutdownWorkerPool(ctx context.Context) error {
	fmt.Println("
--- Début du drain des travailleurs ---")
	// Dans un cas réel, on attendrait qu'un nombre prédéfini de tâches se terminent.
	// Ici, on attend simplement que le contexte expire, forçant les select blocks.
	select {
	case <-ctx.Done():
		fmt.Println("Toutes les ressources critiques ont été libérées. Pool de travail vidé avec succès.")
		return nil
	case <-time.After(3 * time.Second):
		// Simulate un timeout fatal si les workers traînent trop
		return fmt.Errorf("timeout lors du drain du pool de travailleurs")
	}
}

func main() {
	// Simulation d'un pool de 3 travailleurs
	pool := NewWorkerPool(3)
	ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
	defer cancel()

	for i := 1; i <= 3; i++ {
		pool.wg.Add(1)
		go pool.StartWorker(i, ctx)
	}

	// Simulation d'attente du signal d'arrêt
time.Sleep(2 * time.Second)
	fmt.Println("\n[SIGTERM reçu] Tentative d'arrêt propre serveur Go (Drainage)...")

	// On annule le contexte, signalant l'arrêt à tous les workers
	cancel()
	
	// On attend la fin du travail avec un mécanisme de timeout explicite
	err := pool.GracefulShutdownWorkerPool(context.Background())
	if err != nil {
		fmt.Printf("Erreur critique pendant le shutdown : %v\n", err)
	}
	fmt.Println("Shutdown du pool de travailleurs réussi.")
}

▶️ Exemple d'utilisation

Imaginons un scénario réel où nous avons un service d'API qui interroge une base de données pour traiter une commande. Notre objectif est que, même si le service reçoit un SIGTERM pour une mise à jour, il termine d'abord la requête en cours avant de s'arrêter. Le code de base que nous avons vu précédemment est adapté, mais ajoutons ici le mécanisme de *logging* d'état.

Le processus se déroule comme suit :

Le serveur est lancé et fonctionne normalement.
Après quelques secondes, un signal SIGTERM (simulant un kubectl delete pod ou un kill -SIGTERM) est envoyé au processus.
Notre mécanisme de signal capture ce signal et initie la séquence de shutdown.
server.Shutdown(ctx) est appelé, qui stoppe l'acceptation des nouvelles requêtes.
Toute requête active se termine grâce au timeout du contexte de la requête elle-même.

L'exécution de la fonction main> se termine proprement en débitant la sortie "Serveur déconnecté avec succès. Shutdown terminé.". Ceci garantit que le déploiement peut continuer sans ambiguïté sur l'état du système de fichiers ou des dépendances réseau.

2024/05/15 10:30:00 🚀 Serveur démarré sur http://localhost:8080
// --- 5 secondes plus tard, SIGTERM est envoyé ---
2024/05/15 10:30:05 ✅ Signal de fermeture reçu. Début de l'arrêt propre serveur Go...
// Le serveur envoie une réponse à toutes les requêtes en cours, mais arrête d'en accepter de nouvelles.
2024/05/15 10:30:06 🚪 Serveur déconnecté avec succès. Shutdown terminé.

🚀 Cas d'usage avancés

Le arrêt propre serveur Go ne se limite pas au simple server.Shutdown(). Dans un système complexe, il faut gérer la fermeture ordonnée de toutes les ressources dépendantes. Voici trois cas d'usage avancés qui nécessitent une approche structurée.

1. Drainage des Workers Pools (Queue Handling)

Si votre service utilise un pool de travailleurs (worker pool) qui traite des tâches asynchrones (ex: traitement d'images, envoi de mails), il est vital que ces tâches s'achèvent avant l'arrêt. Vous devez implémenter un mécanisme de "drainage".

Exemple : Vous utilisez un channel de tâches et un groupe de WaitGroup. Au signal de fermeture, vous arrêtez d'ajouter de nouvelles tâches au channel. Ensuite, vous attendez que le nombre de goroutines actives atteigne zéro, en utilisant un timeout pour garantir qu'aucune tâche ne bloque indéfiniment. Ceci garantit qu'aucune donnée n'est perdue en queue.

// Pseudo-code pour le drainage
func (wp *WorkerPool) Drain(ctx context.Context) error {
    // 1. Fermer le canal d'entrée pour signaler l'arrêt des tâches.
    close(wp.taskQueue)
    
    // 2. Attendre que tous les workers aient traité leur tâche actuelle.
    waitChan := make(chan struct{})
    go func() {
        wp.wg.Wait() // Bloque jusqu'à ce que tous les workers appellent Done()
        close(waitChan)
    }()

    select {
    case <-waitChan:
        // Succès: tous les workers ont terminé
        return nil
    case <-ctx.Done():
        // Échec: Timeout, forcer l'arrêt
        return fmt.Errorf("timeout de drain: certaines tâches traînent")
    }

2. Déconnexion Sécurisée de la Base de Données

Lors du shutdown, il faut fermer toutes les connexions BDD (database connections) pour libérer les ressources et éviter les problèmes de pool de connexions. La plupart des drivers modernes de bases de données Go (comme database/sql) fournissent une méthode Close().

Il faut s'assurer que cette fermeture est appelée à la fin du programme, et idéalement qu'elle est encapsulée dans le processus d'arrêt propre. Ne pas fermer la BDD laisse potentiellement des transactions en attente et des locks (verrous) sur les données.

// Dans la fonction main() ou une fonction Init():
    db, err := sql.Open("postgres", "user=... dbname=...")
    if err != nil { /* handle error */ }
    
    // ... Utilisation de la BDD ...

    // Au signal de fermeture:
    if err := db.Close(); err != nil {
        log.Printf("Avertissement: Échec de la fermeture de la BDD : %v", err)
    }

3. Gestion des Connexions gRPC

Si votre API utilise gRPC, l'arrêt propre est plus complexe car il implique la gestion des flux bidirectionnels (streaming). L'objectif est de signaler aux clients que vous êtes en train de fermer tout en laissant le temps aux requêtes en cours de se terminer. Le contexte est de nouveau le maître mot. Il est crucial de s'assurer que l'interface gRPC elle-même reçoit et respecte le contexte d'annulation lors de l'appel de shutdown.

En résumé, maîtriser l'arrêt propre serveur Go signifie toujours considérer l'état de toutes les ressources (BDD, files d'attente, connexions réseau) comme dépendant de la gestion d'un contexte de timeout.

⚠️ Erreurs courantes à éviter

Le piège du shutdown est qu'il est souvent considéré comme simple, alors qu'il est en réalité l'un des sujets les plus complexes de la programmation concurrente. Voici les erreurs les plus fréquentes lors de la mise en œuvre d'un arrêt propre serveur Go.

1. Ignorer le contexte dans les handlers

Erreur : Faire en sorte que les goroutines des handlers (ex: des appels de BDD) ne respectent pas le context.Context. Conséquence : Si l'utilisateur coupe le réseau ou si le serveur s'arrête, la requête traîne toujours, maintenant des ressources occupées.

2. Manquer le timeout de shutdown

Erreur : Appeler server.Shutdown(context.Background()) sans timeout explicite. Conséquence : Le shutdown peut bloquer indéfiniment si une connexion client est prise dans un état d'attente (hang).

3. Ne pas fermer les ressources (DB/Pools)

Erreur : Oublier d'appeler db.Close() ou de drainer les worker pools. Conséquence : Fuites de ressources (resource leaks), verrous sur les tables de la base de données, et incapacité à démarrer la prochaine instance de manière propre.

4. Utiliser `os.Exit()` en cas d'arrêt contrôlé

Erreur : Utiliser os.Exit() dans le gestionnaire de signaux. Conséquence : L'arrêt est immédiat, brutal, et ne permet aucune exécution de code de nettoyage (defer ou finally).

5. Non-gestion du signal de terminaison

Erreur : Ne pas écouter les signaux système (signal.Notify). Conséquence : Le programme ne réagit qu'aux erreurs de runtime, et pas aux commandes de déploiement standard (SIGTERM).

✔️ Bonnes pratiques

Pour garantir un système vraiment robuste, suivez ces conventions de codage et de design de haut niveau.

1. Propager le contexte à tout niveau

Chaque fonction qui réalise une I/O (lecture de fichier, appel BDD, requête HTTP) doit accepter et propager le contexte. C'est la garantie que le arrêt propre serveur Go fonctionnera en cascade.

2. Définir des timeouts explicites

Ne jamais se fier au comportement par défaut du système. Définissez des timeouts pour le serveur (Shutdown timeout) et pour chaque opération critique (Request timeout, DB query timeout). Ceci transforme l'incertitude en une variable de contrôle.

3. Isoler la logique de shutdown

Le code responsable du signal et du shutdown doit être isolé dans une fonction unique (ex: setupSignalHandler()). Ceci améliore la testabilité et la lisibilité. Ce code doit coordonner le shutdown de toutes les dépendances.

4. Utiliser les patterns de WaitGroup/Channel

Pour les tâches asynchrones, utilisez toujours une combinaison de sync.WaitGroup pour attendre la finalisation et de select{} avec context.Done() pour l'interruption.

5. Logging enrichi pendant le shutdown

Implémentez un niveau de logging spécial lors du shutdown. Cela vous permet de savoir si la phase de nettoyage est en cours, combien de workers ont été drainés, et si des avertissements de connexion ouverte ont eu lieu, facilitant grandement les post-mortem analyses.

📌 Points clés à retenir

Le contexte.Context est le mécanisme fondamental en Go pour propager l'état d'annulation et garantir un arrêt propre, obligeant les goroutines à réagir aux signaux de terminaison.
Différencier SIGTERM de SIGKILL : SIGTERM est un signal de politesse qui permet une fermeture contrôlée, tandis que SIGKILL est un arrêt brutal sans nettoyage.
L'utilisation de <code style="background-color: #eee;">http.Server.Shutdown(ctx)</code> doit toujours être enveloppée dans un mécanisme de gestion de timeout pour éviter le blocage permanent.
Le drainage (draining) des ressources (DB, queues) doit se faire avant le shutdown du serveur HTTP. Il faut s'assurer que toutes les tâches en cours sont finalisées.
Le pattern <code style="background-color: #eee;">select{}</code> avec <code style="background-color: #eee;">context.Done()</code> est essentiel pour que les workers et les handlers puissent réagir à l'annulation.
Dans un environnement réel, les tests d'intégration doivent spécifiquement simuler des signaux SIGTERM pour valider le <strong style="font-weight: bold;">arrêt propre serveur Go</strong>.
La gestion des dépendances est clé : la séquence de fermeture doit être ordonnée (ex: 1. Worker Pool -> 2. BDD -> 3. HTTP Server).
Considérer le `context.Background()` comme le contexte de haut niveau, et dériver des contextes à durée limitée pour les opérations spécifiques afin de garantir la réactivité.

📚 Articles liés

✅ Conclusion

En définitive, maîtriser l'arrêt propre serveur Go n'est pas un ajout optionnel, mais un marqueur de maturité dans la conception de systèmes distribués. Nous avons vu que ce processus complexe repose sur une synergie entre les signaux OS, le modèle de concurrence de Go (goroutines/channels) et, surtout, le mécanisme de propagation d'annulation du context.Context. L'intégration de la gestion des contextes dans chaque couche (handler, pool de workers, connexion BDD) transforme un risque potentiel de corruption de données en une séquence de déconnexion élégante et prévisible.

Nous avons parcouru des sujets variés, allant du simple appel à server.Shutdown(ctx) aux mécanismes avancés de drainage de pools de travailleurs et de fermeture ordonnée de bases de données. Pour aller plus loin, je vous recommande de simuler ce scénario dans votre environnement de staging : forcez un SIGTERM et observez quelles dépendances traînent. Les ressources comme le package github.com/go-kit/kit ou la documentation des drivers spécifiques BDD offrent d'excellents cas pratiques.

N'oubliez jamais que la résilience est une fonctionnalité, et la gestion du shutdown en est la preuve la plus tangible. Ne vous contentez pas de faire fonctionner votre API, faites-la savoir qu'elle peut s'arrêter en toute dignité. N'hésitez pas à lire la documentation officielle : documentation Go officielle. Maintenant, le challenge vous appartient : intégrez ce pattern dans votre prochaine refonte de service !

Arrêt propre serveur Go : Maîtriser le shut down des API

Arrêt propre serveur Go : Maîtriser le shut down des API

🛠️ Prérequis

Compétences linguistiques et conceptuelles

📚 Comprendre arrêt propre serveur Go

Le rôle des contextes dans l’arrêt propre serveur Go

🐹 Le code — arrêt propre serveur Go

📖 Explication détaillée

Analyse du cycle de vie du serveur et du signal handling

🔄 Second exemple — arrêt propre serveur Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Drainage des Workers Pools (Queue Handling)

2. Déconnexion Sécurisée de la Base de Données

3. Gestion des Connexions gRPC

⚠️ Erreurs courantes à éviter

1. Ignorer le contexte dans les handlers

2. Manquer le timeout de shutdown

3. Ne pas fermer les ressources (DB/Pools)

4. Utiliser `os.Exit()` en cas d'arrêt contrôlé

5. Non-gestion du signal de terminaison

✔️ Bonnes pratiques

1. Propager le contexte à tout niveau

2. Définir des timeouts explicites

3. Isoler la logique de shutdown

4. Utiliser les patterns de WaitGroup/Channel

5. Logging enrichi pendant le shutdown

✅ Conclusion

WebAssembly en Go : Compiler Go pour le Navigateur

Parseur de logs Nginx Go : Guide complet des logs avec Go

Créer REST API Go net/http : Le Guide Complet JSON

Mini-jeu snake Go : Maîtrisez le développement CLI

errgroup avec contexte Go : Annulation coordonnée avancée

sync.WaitGroup Go : Maîtriser la synchronisation

Un commentaire

Laisser un commentaire Annuler la réponse

Arrêt propre serveur Go : Maîtriser le shut down des API

🛠️ Prérequis

Compétences linguistiques et conceptuelles

📚 Comprendre arrêt propre serveur Go

Le rôle des contextes dans l’arrêt propre serveur Go

🐹 Le code — arrêt propre serveur Go

📖 Explication détaillée

Analyse du cycle de vie du serveur et du signal handling

🔄 Second exemple — arrêt propre serveur Go

▶️ Exemple d'utilisation

🚀 Cas d'usage avancés

1. Drainage des Workers Pools (Queue Handling)

2. Déconnexion Sécurisée de la Base de Données

3. Gestion des Connexions gRPC

⚠️ Erreurs courantes à éviter

1. Ignorer le contexte dans les handlers

2. Manquer le timeout de shutdown

3. Ne pas fermer les ressources (DB/Pools)

4. Utiliser os.Exit() en cas d'arrêt contrôlé

5. Non-gestion du signal de terminaison

✔️ Bonnes pratiques

1. Propager le contexte à tout niveau

2. Définir des timeouts explicites

3. Isoler la logique de shutdown

4. Utiliser les patterns de WaitGroup/Channel

5. Logging enrichi pendant le shutdown

✅ Conclusion

Publications similaires

Un commentaire

Laisser un commentaire Annuler la réponse

4. Utiliser `os.Exit()` en cas d'arrêt contrôlé