Gérer les défaillances partielles

Dans les systèmes distribués comme les applications basées sur des microservices, il existe un risque de défaillance partielle. Par exemple, un seul microservice/conteneur peut échouer ou ne pas être disponible pour répondre pendant une courte période, ou une seule machine virtuelle ou un serveur peut se bloquer. Étant donné que les clients et les services sont des processus distincts, un service peut ne pas être en mesure de répondre en temps voulu à la demande d’un client. Le service peut être surchargé et répondre très lentement aux requêtes ou peut simplement ne pas être accessible pendant une courte période en raison de problèmes réseau.

Par exemple, considérez la page Détails de la commande à partir de l’exemple d’application eShopOnContainers. Si le microservice de commande ne répond pas lorsque l’utilisateur tente d’envoyer une commande, une implémentation incorrecte du processus client (l’application web MVC) (par exemple, si le code client devait utiliser des RPC synchrones sans délai d’attente) bloque indéfiniment les threads en attente d’une réponse. Outre la création d’une expérience utilisateur incorrecte, chaque attente sans réponse consomme ou bloque un thread, et les threads sont extrêmement utiles dans les applications hautement évolutives. S’il existe de nombreux threads bloqués, le runtime de l’application peut éventuellement manquer de threads. Dans ce cas, l’application peut devenir globalement non réactive, au lieu de l'être partiellement, comme illustré dans la figure 8-1.

Figure 8-1. Échecs partiels en raison de dépendances qui affectent la disponibilité des threads de service

Dans une application volumineuse basée sur des microservices, toute défaillance partielle peut être amplifiée, en particulier si la plupart des interactions de microservices internes sont basées sur des appels HTTP synchrones (qui est considéré comme un anti-modèle). Pensez à un système qui reçoit des millions d’appels entrants par jour. Si votre système a une conception incorrecte basée sur de longues chaînes d’appels HTTP synchrones, ces appels entrants peuvent entraîner de nombreux millions d’appels sortants (supposons un ratio de 1:4) à des dizaines de microservices internes en tant que dépendances synchrones. Cette situation est illustrée dans la figure 8-2, en particulier la dépendance #3, qui démarre une chaîne, appelant la dépendance #4, qui appelle ensuite #5.

Figure 8-2. L’impact d’une conception incorrecte avec de longues chaînes de requêtes HTTP

Une défaillance intermittente est garantie dans un système distribué et basé sur le cloud, même si chaque dépendance elle-même a une excellente disponibilité. C’est un fait que vous devez prendre en compte.

Si vous ne concevez pas et implémentez des techniques pour garantir la tolérance de panne, même les petits temps d’arrêt peuvent être amplifiés. Par exemple, l’existence de 50 dépendances avec 99,99 % de disponibilité se traduit par plusieurs heures d’arrêt chaque mois en raison de cet effet amplificateur. Lorsqu’une dépendance de microservice échoue lors de la gestion d’un volume élevé de requêtes, cette défaillance peut rapidement saturer tous les threads de requête disponibles dans chaque service et bloquer l’ensemble de l’application.

Figure 8-3. Défaillance partielle amplifiée par les microservices avec de longues chaînes d’appels HTTP synchrones

Pour réduire ce problème, dans la section Intégration asynchrone des microservices, appliquez l’autonomie du microservice, ce guide vous encourage à utiliser la communication asynchrone entre les microservices internes.

En outre, il est essentiel de concevoir vos microservices et applications clientes pour gérer les défaillances partielles, c’est-à-dire pour créer des microservices résilients et des applications clientes.