Réponses:
En général, le but du modèle de cloison est d'éviter les pannes dans une partie d'un système pour démonter tout le système. Le terme vient des navires où un navire est divisé en compartiments étanches séparés pour éviter qu'une seule rupture de coque n'inonde le navire entier; il n'inondera qu'une seule cloison.
Les implémentations du modèle de cloison peuvent prendre de nombreuses formes selon le type de pannes dont vous souhaitez protéger le système. Je ne discuterai que du type de défauts que Hystrix gère dans cette réponse.
Je pense que le modèle de cloison a été popularisé par le livre Release It! par Michael T. Nygard.
L'implémentation de cloison dans Hystrix limite le nombre d'appels simultanés à un composant . De cette façon, le nombre de ressources (généralement des threads) qui attend une réponse du composant est limité.
Supposons que vous avez une demande d'application, multithread (par exemple une application web typique) qui utilise trois composants différents, A , B et C . Si les demandes de composant C commence à se bloquer, par la suite toutes les demandes de manutention des fils se bloque sur l' attente d'une réponse de C . Cela rendrait la demande totalement irrecevable. Si les requêtes à C sont traitées lentement, nous avons un problème similaire si la charge est suffisamment élevée.
L'implémentation par Hystrix du modèle de cloison limite le nombre d'appels simultanés à un composant et aurait sauvé l'application dans ce cas. Supposons que nous avons 30 threads de traitement de la demande et il y a une limite de 10 appels simultanés à C . Puis , à la plupart des 10 demande des fils de manipulation peuvent se bloquer lors de l' appel C , les 20 autres threads peuvent toujours traiter les demandes et les composants d'utilisation A et B .
Hystrix 'a deux approches différentes de la cloison, de l'isolation des threads et de l'isolation des sémaphores.
L'approche standard consiste à transférer toutes les demandes au composant C à un pool de threads séparé avec un nombre fixe de threads et aucune (ou une petite) file d'attente de demandes.
L'autre approche est d'avoir tous les appelants acquièrent un permis (avec 0 délai d' attente) avant que les demandes à C . Si un permis ne peut pas être obtenu à partir du sémaphore, les appels à C ne sont pas transmis.
L'avantage de l'approche du pool de threads est que les requêtes passées à C peuvent être expirées, ce qui n'est pas possible lors de l'utilisation de sémaphores.
Voici un bon exemple avec une explication d'exécution pour la cloison dans Resilience4j qui est inspirée de Netflix Hystrix.
Les exemples de configuration ci-dessous pourraient clarifier l'utilisation.
Exemples de configurations: autorisez un maximum de 5 appels simultanés à tout moment. Attendez les autres appels jusqu'à ce que l'un des 5 simultanés en cours se termine ou jusqu'à 2 secondes maximum.
L'idée est de ne pas surcharger un système avec une charge supérieure à ce qu'il peut consommer. Si la charge entrante est supérieure à la consommation, attendez un temps raisonnable ou juste timeout et choisissez un autre chemin.