Technical Tutorials

Les systèmes de l'Internet des objets (IoT) sont intrinsèquement fragiles. Un simple capteur défaillant, une micro-coupure réseau ou un dépassement de délai d'une API en aval peuvent provoquer des pannes systémiques. Alors que les langages de programmation traditionnels gèrent ces exceptions avec des blocs `try-catch`, les outils de flux visuels comme Node-RED nécessitent une approche différente pour la tolérance aux pannes. Laisser simplement les messages échouer silencieusement n'est pas une option pour une infrastructure de production. Pour construire un système véritablement auto-réparateur, nous devons implémenter des disjoncteurs (Circuit Breakers) pour prévenir les pannes en cascade et des files de messages morts (DLQs) pour capturer et inspecter les messages non délivrables.

Pourquoi les flux visuels ont besoin d'une gestion explicite des erreurs

Dans un flux Node-RED, si un nœud échoue (par exemple, une requête HTTP dépasse le délai), le message est généralement abandonné ou envoyé vers un nœud d'erreur. Sans stratégie, un service en aval défaillant (comme une base de données cloud) provoquera une accumulation dans l'ensemble du flux, consommant de la mémoire et retardant les alertes critiques pour les appareils sains. L'objectif d'un système auto-réparateur est de détecter automatiquement ces pannes, d'arrêter l'envoi de trafic vers le composant défectueux (disjoncteur) et de stocker en toute sécurité les données échouées pour une récupération ultérieure (DLQ) sans interrompre le reste du pipeline.

Implémentation du motif Disjoncteur (Circuit Breaker)

Un disjoncteur surveille le taux de réussite des appels à un service dépendant. Si le taux d'échec dépasse un seuil, il "ouvre" le circuit, faisant immédiatement échouer les requêtes suivantes pendant une durée définie pour donner au service le temps de se rétablir.

Bien que Node-RED dispose d'une gestion des erreurs intégrée, nous pouvons implémenter cette logique en utilisant une combinaison de nœuds switch, function et change. Voici une implémentation conceptuelle utilisant un nœud function qui suit le nombre d'échecs dans le stockage de contexte.

// Nœud Function : Logique du Disjoncteur
// Ce nœud doit être placé avant le nœud de Requête HTTP instable.

let failures = context.get('failures') || 0;
let circuitState = context.get('circuitState') || 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
const FAILURE_THRESHOLD = 3;
const RESET_TIMEOUT = 30000; // 30 secondes

// Si le circuit est OUVERT, vérifier s'il est temps de réessayer (HALF_OPEN)
if (circuitState === 'OPEN') {
    const now = new Date().getTime();
    const lastOpenTime = context.get('lastOpenTime') || 0;
    
    if (now - lastOpenTime > RESET_TIMEOUT) {
        circuitState = 'HALF_OPEN';
        context.set('circuitState', circuitState);
        // Autoriser une requête à passer pour tester le service
        return msg;
    } else {
        // Le circuit est toujours ouvert, abandonner le message et déclencher une alerte
        msg.payload = { error: "Service indisponible", circuit: "OPEN" };
        msg.topic = "circuit_breaker_trip";
        return [msg, null]; // Routage vers DLQ/Alerte d'erreur
    }
}

// Passer le message au nœud de service
msg._circuitContext = { failures: failures };
return msg;

// **IMPORTANT :** Vous devez gérer la réponse.
// Attachez un nœud "Gestionnaire de Disjoncteur" après l'appel au service.
// Si l'appel au service échoue (nœud d'erreur), incrémentez les échecs.
// S'il réussit, réinitialisez les échecs.

Gestion de la réponse : Vous devez capturer à la fois les chemins de succès et d'échec. Connectez la sortie de votre nœud de service à un nœud function qui réinitialise le compteur d'échecs en cas de succès. Connectez la sortie erreur du nœud de service à un nœud function séparé qui incrémente le compteur d'échecs et, si le seuil est atteint, met à jour le circuitState en OPEN.

Implémentation d'une File de Messages Morts (DLQ)

Lorsqu'un disjoncteur se déclenche ou qu'un message échoue à la validation, nous ne jetons pas les données. Nous les envoyons vers une File de Messages Morts. Dans Node-RED, une DLQ est généralement implémentée comme un stockage persistant, tel qu'un nœud file, un sujet mqtt nommé dlq/alerts, ou une collection de database.

Voici comment structurer le nœud DLQ pour garantir l'intégrité des données :

// Nœud Function : Préparer le message pour la DLQ
// Ce nœud est placé sur la sortie d'erreur du Disjoncteur
// ou sur le nœud d'erreur principal du flux.

const dlqMessage = {
    originalPayload: msg.payload,
    originalTopic: msg.topic,
    deviceId: msg.deviceId,
    timestamp: new Date().toISOString(),
    errorReason: msg.error.message || "Erreur inconnue",
    retryCount: context.get('retryCount') || 0
};

// Optionnel : incrémenter un compteur de tentatives pour un re-traitement planifié
const currentRetries = dlqMessage.retryCount + 1;
dlqMessage.retryCount = currentRetries;

return {
    payload: dlqMessage,
    topic: "iot/dlq/alerts" // Utiliser un sujet MQTT dédié
};

Récupération et nouvelles tentatives automatisées

Un véritable système auto-réparateur ne se contente pas de stocker les messages échoués ; il tente de les récupérer. Ajoutez un nœud inject qui se déclenche toutes les 5 minutes. Ce nœud doit lire depuis votre stockage DLQ (par exemple, une abonnement MQTT à iot/dlq/alerts/# avec une politique de rétention, ou une requête de base de données).

Pour chaque message récupéré depuis la DLQ, vérifiez le circuitState. Si le circuit est CLOSED ou HALF_OPEN, republiez le payload original vers le flux de traitement principal. Si le circuit est OPEN, laissez-le dans la DLQ pour le prochain cycle. Cela crée un mécanisme naturel de contre-pression où les messages échoués ne sont retentés que lorsque le service en aval est sain.

Conclusion

En intégrant des disjoncteurs et des files de messages morts dans vos flux Node-RED, vous transformez un système IoT fragile en une architecture résiliente et auto-réparatrice. Le disjoncteur prévient la surcharge et permet aux services de se rétablir, tandis que la DLQ garantit qu'aucune donnée n'est perdue. Ce motif est essentiel pour tout déploiement IoT de production où l'intégrité des données et la disponibilité sont primordiales. Commencez petit : implémentez la logique du disjoncteur pour votre service en aval le plus instable et observez l'impact sur la stabilité du système.